welcome to our presentation on trustless
validator pools and eath 2.0 I'm Dan
Carfi stand this is my colleague Carl
Beck who isn't we are both researchers
and is 2.0 research team and we'd like
to talk a bit about our efforts to make
trust less staking possible in its 2.0
why we're doing this what we how we
design the protocol to make as possible
and then in the end like Kyle will talk
about the actual implementation of this
how it would work so yeah this is the
outline of the talk so like motivation
why why do we need to trust less staking
pools by why we want this as a primary
goal and it's 2.0 then like how do you
design a protocol so like the technology
basically that is needed to have trust
the staking pool as secure multi-party
computations and then they are basically
less and more advanced ways to have
these truster staking pools you can have
a basic algorithm that enables you to
have a sort of transverse taking or you
can actually if you want extend this to
also a fault attribution so that if
you're honest two-thirds majority
assumption fails you can still yeah with
very high likelihood not lose your money
if you're in such a fool okay so what's
so cool why why do we need trust less
taking pools so like the first thing you
have to know about proof stake like a
nice 2.0 we need to fix the the amount
that a stake by every validator to
roughly the same amount and why is that
it's very difficult to design a protocol
that works with fair in a fair way but
with vastly different stakes so for
example when you sample people for
committees you don't make any
adjustments for their stake because it
would
be too complex and so like the protocol
is designed so that it only really works
if what everyone has staked is roughly
similar it can vary slightly but if it
varies too much then like the
assumptions will fail and so like the
the amount that we agreed on as xxxii
eath which is like in today's price is
about five thousand five hundred US
dollars but say like one-eighth goes to
ten thousand US dollars
which is very well possible from what we
know then once one validate I would have
to stake thirty two thousand two three
and twenty two three hundred twenty
thousand eighth yeah sorry US dollars
which is great for security because then
suddenly we would have like our security
assumption and proof of stake of course
depend on how much money is staked by
the validators of all but it would
increase the barrier of entry to such a
high amount that like very few people
could actually afford becoming a
validator from the capital cost point of
view and so that would not be what we're
aiming for to just make validating
another easy income stream for the rich
that's not accessible for everyone else
and since as I mentioned before it's not
really an option to just make staking
possible with any staking amount the
alternative is that we create staking
pools where several people can come
together and say like we want to run
when one valid data together and we'll
put everyone puts in part of the
required capital and so and the nice
thing about when you have Trust are
staking pools as we're going to talk
about in this presentation then they can
still be decentralized so like having a
pool doesn't mean oh I know like Jeff is
like a trust where the guy will just
everyone give him their money and he'll
run it but no we can actually do this so
that everyone runs that validator
together in a multi-party computation
and you don't need to fully trust that
any of the guys is like completely
trustworthy right and there's actually
also a second very good reason to do
this
and which is that even if even if you
are a single guy putting up the deposit
you might not actually want to run your
valid data on just one machine because
the thing is to run the validator you
need to have the validator secret on
that machine and that's of course a huge
potential security risk because someone
hacking that machine could just do
whatever they want with that key and
potentially get you slashed so a nice
thing is if you have the technology to
enable multi-party computation for
validators then that also means you can
increase your security by distributing
your key across say just three machines
and say you don't you want to run it and
the cloud you don't fully trust your
cloud provider you can have one on Azure
or one on s3 and one on the Google cloud
so you avoid having a single point of
failure cool
so let's come to the technology that
that makes this possible so one thing is
that we chose to in order to sign
anything on is to and we choose this
signature scheme that's called pls
signatures and basically the way it
works is that it uses an elliptic group
by the pairing so what that means is
that you have this pairing function this
okay so e that pairs two elements from
elliptic groups with this linearity
relation so like you can move this
factor n from the from the first
argument to the second argument and you
can also move it out of the out of the
pairing here and so like a secret key is
just an integer and a public key is you
MA you multiply your generator which is
g1 by your secret key and in order to
sign a man
search you multiply that message so
that's a point you we map the message to
a point in the elliptic group to your
secret we times M and in order to check
out to use the pairing equation so you
check that the pairing of your public
key and the message is the same as to
generate and generator in the signature
and the amazing thing about the
signature scheme is that if you look at
the signature checking equation here and
it's linear in the public key and the
signature and this means that you can
you can do something like you can you
can add two public keys and two
signatures and and that will still be a
valid signature for the sum of these two
public keys and that message so
basically like you can you can just add
signatures in order to create a new
aggregated signatures and this is
amazing and basically it also enables
kind of many things that we do an is-2
in the first place or in a way it
enables charting in the first place
because it means that thousands of
signatures can just be aggregated into
one single signatures that that can be
checked once using this pairing and you
know that everyone has signed this
correctly so this saves a huge amount of
data and computation but also at the
same time since it is linear this
enables something called a Shamir secret
sharing so the idea behind
Shami a secret sharing is like set let's
say we have 10 parties who want to share
a secret what we do is we make we make
the secret a number and we encode it by
creating a polynomial that at zero has
evaluates to that number and we give
every one of those 10 parties one two
three four five six seven eight nine ten
one point on that Pauline
and then and now the degree of that
polynomial determines how many of the
parties you need in order to reconstruct
the secret so for example here I've
chosen a polynomial of degree three and
we know that any polynomial of degree
three can be can be reconstructed using
four values and so that means this
automatically gives you gives us a four
out of ten signature scheme that means
you need four of the people and any four
no matter which four could recreate that
point at zero and and basically due to
the linearity of the BLS signature
scheme that means we automatically have
the signature the threshold signature
scheme and that means that we can design
this amout of n scheme and yeah yeah so
basically that gives us three for pls
signature which is like the me the most
important agreeing because most of the
work that you do as a validator
is signing things like a testing block
saying this was a correct block this is
the state of that chart at that block
and now we can do that in in a
decentralized way right and now coming
to one point that was kind of difficult
in this as we have we have one element
of the protocol and that inherently
needs a more yeah a computation that
involves your secret that cannot be
solved using this aggregate signatures
and that's the so called proof of
custody what's the proof of cassadee and
the idea behind the proof custody is
that you want to prove ownership of data
so what what we want to do is that when
you sign that you have seen a certain
amount of shard data that you also prove
that you have seen that data because
otherwise you have this so-called lazy
validator problem that means that oh
like I've seen some signature
for the status so probably it's fine
I'll just sign it without doing the work
and that's probably okay in 99% of the
time but in the 1% of the time where you
do have an attacker and that who does
something really evil and they kid could
use those validator those lazy
validators to massively amplify the
attack because they only need a small
number of signatures of some data for
example that's not available at all and
and then all those lazy validators would
sign it and suddenly you have like
there's non available data that sign-off
which is a massive problem for the chain
so the way we avoid this is by having
every validator whenever they sign that
chart data generate one extra bit the
so-called Cassidy bit or Cassidy root
and and that's basically a mix of a
secret it's the secret here and the data
at every data block and then you
basically so this is the original
construction this is good for like
understanding how it works you computer
kind of hashed for you would have this
whole thing and then you take the first
bit of the route okay and basically only
if you have that secret you can compute
it if you don't have it you can't
compute it someone else can't easily
compute it for you with unless they have
that secret and if you give away that
secret then we can slash you so and that
gives you a very strong incentive for
actually getting the data because if you
don't have it it's very likely that your
Cassidy butt is going to be wrong now
the problem with this is how do you do
that
if you are in in a valid data pool if
you don't actually want anyone to have
the secret that can get everyone slashed
like it would be a massive problem if
someone needs to have this whole secret
and the way you yeah okay so there's a
summary yeah the way we solve that
problem is we found this new
pseudo-random function and that
basically is very friendly to compute in
multi-party computation so that you can
compute with many participants in a very
efficient way as defined as using the so
called Legendre symbol which is that
which is defined by so this is like it's
the notation as a over P it's one if a
is a quadratic residue modulo P so if
there's a number that squares to a
modulo P minus one if it's not and then
there's a special case that it's zero
if P divides a but in a way you could
say that never happens because the prey
prime we're using is so crazy big that
this is like yeah this is like a zero
hash or something it just doesn't happen
we normalize this to a bit because one
one and minus one are not really like a
nice thing to work when within a
protocol and then the PRF is defined by
just computing this Legendre bit of the
sum of the secret and the data and the
nice thing is that this is super easy to
compute in a multi-party computation
I'll not go over that in detail right
now because the time for that is a bit
short but basically there's a nice way
to just blind the whole thing and be
when it's blinded like you can you can
do the extra computation in the open and
then it's very easy to reconstruct the
original result from that yeah and then
basically we replace can replace the
proof of custody using this
pseudo-random function and that gives us
an MPC friendly proof of caste protocol
yes like I've been working on this
Legendre function for a while now
because we really want to use it the
only problem with it at the moment is
that it hasn't had a terrible amount of
crypt analysis and so we're currently
working on improving that so one thing I
wanted to mention here is like we set
those bounties on like improving the
state so like we have both
like asymptotic bounties for finding any
better algorithms and some concrete ones
there will soon be a smart contract for
resolving this so stay tuned but you can
already on the Ronda POF dot orc stash
bounties can already get those
challenges if you find a solution just
email me and then you can also already
claim them yeah so basically you can win
between one and sixteen eighth for
finding basically is yeah keys for later
on in different instances the smallest
ones are designed so that like with a
few months or so of compute time you can
actually solve them so I'm expecting
them to be solved but would be really
interested in how long it actually takes
the most difficult ones hopefully no one
can ever solve but yeah we want to know
if there are any algorithmic
improvements that might change this cool
yeah
with this I'll hand over to cow cool so
moving on as to how we actually apply
this this can be a bit faster due to
time constraints but here we go so
there's a distinction to make here
quickly between two ways of constructing
pools one is where you try use you use
economic incentives and custodial
relationships to to manage a pool which
is more like the case of rocket pool
whereas this is more designed to be run
in an NPC where you want to be involved
in the pooling structure so you don't
want to hand your ether over to a pool
even if they are incentivized so these
are what you are required to do as a
validator within e 2.0 these are the
primary responsibilities with their
frequencies and all of this is
relatively cheap in terms of a port and
it needs to be done and as you can see
things like the ABC calculated legendre
shows up once an epoch and so these
kinds of things are enabled by the bank
represented skip over that so the
obvious way to do this would be
something like pbft consensus for a pool
because we need a system that is
safe but not live because if you ever
commit something that is not not a super
majority of your nodes agree with then
you've run into the scenario where you
can get your poor slashed a relatively
easy way of achieving this is actually
just using the ELS signatures so you set
your threshold as 2/3 of your pool size
and based on this if you have to propose
one of the pool members proposes but
otherwise you see what your attestation
duties are this is available if you have
a view of the chain you compute the
appropriate custody bit and you sign an
attestation only if the center station
you think is valid in your local view
and this is with basically the overhead
have only barely signatures press the
custody butts that dunk rod presented
earlier allows you to have pooling which
is very cool unfortunately that doesn't
guarantee consistency because it's not a
full consensus protocol people can
disagree as to the state of what the
chain is at any given time so basically
you can have some structure that runs
pbft if you run into some unhappy case
where the pool gets out of sync and you
can also make the slightly more
interesting which is where you have some
kind of meta pool which exists between
the pools so as a pool member you don't
only participate in your pool but you
participate in this larger meta pool and
this allows you to use the meta pool to
have false attribution where you prove
to the rest of the pool that there's
metal pool that someone did something
bad in your pool and then if one of your
pool members got you slashed got got
your pool slashed you can because the
slash is not burning all of the ether
it's only burning a portion you can
basically take all of that so that the
negative penalty and put it on that one
person who is bad and give the other
people their money back and in fact it
may it may turn out that you can get
more money out so you may make a profit
if one of your pool members get slashed
which is pretty cool depends on exactly
how you construct it so yeah that's
the basic construction and how something
like this would work within each 2.0
[Applause]
you