Ethereum 2.0 Trustless Staking Pools by Carl Beekhuizen & Dankrad Feist (Devcon5)

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