Distributed Validators: Improving Staking No Matter Your ETH Balance - Carl Beekhuizen

everyone as mentioned uh i'm carl i'm a researcher with the ethereum foundation and uh today i'm going to be talking to you about distributed validators or as i like to call it staking with friends um but yeah we'll get into that in a moment so as i'm sure many of you are aware staking on ethereum right now can be painfully expensive uh when i got into the space actually what got me into the space was a hackathon where i try to build what i'm going to talk about now many years ago because i didn't have enough cash to just to stake and i think this is true for many people so if there was infrastructure that allowed people to be able to stake and install a decentralized and trustless manner without having to fork out crazy amounts of eth that would be uh that'd be really cool to see another thing is we see many people are very scared of going offline um and uh what they do to do this is they try to set up some redundant uh some some redundant staking set up for themselves maybe they set up uh two validators or uh that they have some software which tries to detect if one goes offline and spin up a new one if it does the problem with this is uh one of the safety mechanisms we have within ethereum proof of stake is that you can never vote twice with different opinions and so if you spin up two validators you stand a high chance of shooting yourself on the foot where you end up voting twice with the different validators in different ways and uh the majority these are the the slashings we've seen on beacon chain the majority of them are from people trying to do this be it institutional or small individuals and uh yeah that's a a pretty bad pain point the other thing is we have this mechanism called correlated slashings so in order to in order not to penalize people too heavily if if you on your own make make make some mistake we don't penalize you that much you lose one eth that much is relative but still but if you are a larger institution and you're staking a large portion of eth then the penalties quickly scale with the amount of faults you make at the same time and uh yeah this is th this can lead to some pretty detrimental runaway effects where uh your risks as an institution or as a whale start to add up very quickly the other thing we've been seeing is there there's a lot of demand for more liquid style staking where you can stake and unstake very quickly or to be able to use staked ether as an internet internet bond quote unquote and this is people trying to enable more out of their stake and we see services such as this is lido but there are a few others trying to spin up and um they're basically just trying to offer this platform for for for staked eve the issue being is that there's no way for them to do this in a proper trustless manner they have a few people under the hood that they delegate the stake eath to and just quote unquote trust us another issue is that lots of these institutions that are being trusted are the same people that the exchanges trust so there's all these correlated issues as i mentioned in the previous slide that start adding up quite quickly so yeah there are several things which are starting to uh uh add up which can lead to rather unpleasant experience um in in certain scenarios and we'd like to have this tech called distributed validators as an attempt to to to mitigate lots of these these issues uh the idea being that several people slash buffer coins um institutions servers whatever you want you can distribute your your risk uh and and your up time amongst multiple people and together you act as one validator for the network and as you'll see in a few moments this gives us some really cool upsides in terms of what can be achieved for home stakers i'm sure everyone is familiar with this lovely email that makes you go have i done something wrong uh was it just that one fluke where something something happened probably can be ignored if you get a few more of these you know you've got an issue and the idea is here again that you can have a setup which is more resilient so if if if this is your particular node at home that's going down maybe you could run different pieces of software to try to help mitigate this and then use this distributed validators on top of it such that if one of one of your clients goes down it doesn't really matter um institutions this is the rough distribution of stake at the moment minus a big one which is coinbase who've obfuscated some stuff which makes a bit harder to track but as you can see they start adding up to that that magic 30 33 threshold i was mentioning earlier which is the where the correlated slashing is at its full effect so if you start to get close to those numbers that's that that could have really negative effects for you so again hopefully distributed validators can can come in here and and eliminate some of these risks another one is pooling with friends um personally this is the sort of solved my initial issue where i didn't have enough eats to stake but maybe you and your your homies can get together and uh and stay together to try to try to put up 32 eth you you and three other friends eighteenth each that i mean it's a lot of money but maybe it's a lot more achievable for for for many people and like as a part of democratizing this uh and decentralizing this this thing we have which is is staking it would be really nice to be able to do this without having to trust a major a major exchange or institution another cool thing we've been seeing starting up lately are these decentralized pools these are the two major players in in in in the space at the moment with varying levels of tech but they're implementing uh they're implementing this to try to help people out at all levels of this tech stack so like what i'm presenting now sort of the the pure idealized version of this technology but we need people to actually implement it and make it feasible um and have nice interfaces for onboarding to be able to plug into these many legos and uh that's what these these these services are hoping to provide um so going to dig a little bit into how this works um so four four buffer coins get together they want to set up a decentralized validator what they do is uh together they generate one key which is going to be their their staking key their eth2 validation key and they break it up into parts and they give themselves each apart such that no one on their own can act as the validator right no one has enough of the key to to generate signatures to to to misbehave or to to to try coerce their friends um and yeah we continue with this then what we can do is gonna have nice different setups so everyone could use a different client for example um and again they're distributing risk amongst if you have issues in your particular client how do we handle that what what um and yeah by each having a different key this this this helps eliminate it um then what we need to do okay there's missing a piece of my slide there but let's pretend uh basically everyone needs to get together and agree what they're gonna do so someone proposes hey let's build a new block or let's attest to to to to this particular fork of the chain and everyone gets together and before they do anything before they sign any messages uh they reach agreement and uh this this is like sort of the key that allows us to to um do this in ways where we can account for people being malicious or being offline um and that's that and once they've all agreed then they sign the message they come together with their keys and to collectively sign this message in a way that no single one of them could do it on their own um but only with a sufficient uh quorum of them could could they do so uh this is enabled by some sort of fun fun tech under the hood uh secret sharing a very common concept in cryptography but basically you have this is how you you split up the keys and this will be the key generation phase and the the point here is you can set up threshold schemes so maybe you need three out of four people to sign the message right you can have one person be offline or missing um or disagreeing and that's okay we can handle that um this what i was getting into there but is is threshold signatures the sliders just don't don't bother trying to go into it too deeply it's just supposed to look complicated and make it look like my slides aren't just filled with pepes and buffer corns i do do real work at some point but uh yeah the the same math that allows ethereum to improve the stake to scale to so many thousands of validators um is is sort of the the the function the functionality we have in the underlying cryptography and this uh this threshold the signature scheme bls is also allows us to do these threshold signatures where everyone sort of signs the if we agree on a block in the distributed validator everyone signs the block individually and together we can reconstruct it with some threshold uh say three out of the four people um the agreement under the hood looks again something another try make me look serious slide the agreement looks like this it looks very chaotic but this is actually what most safety first consensus algorithms end up looking like when i say safety first this is an important property basically we always in a distributed validator setting we always need to vote in a way that can't get us slashed and we would rather miss an attestation or miss a block than get slashed so we prepared to in the worst case multiple people go offline or many people are malicious we'd rather like halt and have that fail then then continue and so this is what these kinds of algorithms look like i mean at some level ethereum proof of stake looks like this too for the finality so what would this look like i mean in in cases where you have one one note dropping offline it doesn't matter because in a setup like this we could have three or four threshold signatures and uh bft consensus and we would just basically annoy the offline party and whenever they get back online they're welcome to sync up and join and join again but it's no issue and this will prevent some of the issues people you get with people trying to set up redundant redundant systems uh evil or malicious um what what one of your friends could uh could have something like a good tribe curse you or or vote weirdly and this allows us to ignore that setup which is an important property i think where this comes more into play is if you have an institutional setup maybe and you have multiple keys in multiple places you could distribute the number of people who have access to certain keys so there you'd have maybe two people bob and alice and some of them have access to some of the threshold keys and some have access to others or we distribute the keys amounts multiple institutions and this means that even if we have a rogue party within an institution they can't take everyone down we just completely ignore them from then on outwards making them malicious votes and we can we can deal with that outside of the protocol but it's not going to cause anyone to get slashed a third class is sorry yeah i mean if it's really pertinent i can happily happily take it now otherwise i'll get to it in a few slides up to you uh so we're not so the question was with malicious and evil validators what's the message we used to identify them is that correct yeah so we're not voting on hey this person is malicious what we're voting on is hey we ignore this person so [Music] if if you try propose malicious blocks or malicious attestations everyone else is just going to ignore you because what you're saying is not valid from the perspective of the chain and from everyone else's perspective the messages to identify people would have to happen out of protocol so in my bob and alice example if bob was trying to steal the keys or something like that then it would be up to whatever institution to try handle that and to look into where they like what what their own opsec is doing why that went wrong and try to tackle it from there bugs this is a class of thing we've seen sort of minor bugs appear on chain but there's there's quite a scope for for for larger bugs and when i got into the correlated uh slashing things this this could really be bad um so uh as as as per a few previous talks i've given um prism currently holds a two-thirds majority or somewhere right there abouts of the validators on on ethereum proof of stake and so if there was a bug in in prism at the moment this would cause massive correlated slashings would be atrocious for the network um it doesn't matter where you are at private individual institutions it's it's really bad and um so hopefully this improves over time but one of the ways you can avoid this is you might just not care if one of your clients has a bug because the rest of them should all be agreeing and even if multiple of them like if everyone disagrees with their bugs and it all goes terribly you know at least you're not going to get slashed because no one can agree on which message to sign you're not going to be able to produce that threshold signature and that gets you out of a lot of these issues as of earlier this week we opened up the specifications we've been writing for distributed validators so the idea is just like we have the ethereum consensus specifications where the multiple clients implementing the code the idea is to do the same thing here where we write sort of a minimalist specification and that that people can can read and implement and write their own clients for it and then hopefully we will have a diversity of clients in many languages by different teams with different security assumptions and targeting different players and this should allow us to again scale out and improve the safety of even this level of infrastructure in particular the construction we've been looking at here is to try and minimally impact the setup we have at the moment with four or four and institutions um and therefore like your trust assumptions you currently have we can hopefully carry forward or minimally impact as we carry forward um in terms of like allowing you to to to be able to stake with these distributed setups so with you you'd break take your current keys if you if you want to do this you could take your current keys split them up don't know why this died it's all good here um tech hello can do we know why this is dead yeah okay anyway it wasn't super important or the same slide but um anyways but yeah you could take your keys and your current setup split them up amongst a couple of uh parties and then run with your existing beacon nodes as as as they are and lots of your same key management or how you handle that we can hopefully uh keep that relatively similar to what it looks like um my uh kokon spirit dt i gave a talk uh 20 minutes ago on the other stage sitting here in the front row uh which is a little bit more technical slightly less memey so if you'd like to actually look into sort of what these these setups look like and uh what what this looks like under the hood i highly encourage you to check out his talk which i assume will be online sorry it's not enough time for me to put in a qr code to uh wherever that will be um yeah thank you uh for coming to to my presentation and listening to this chat and yeah with any questions [Applause]