Distributed Validator Technology_Aditya Asgaonkar

from the ethereum foundation and i'm going to talk about distributed validator technology this is something we have been working on for one and a half years and i'm pretty excited to announce some stuff about this so let's get into it right all right so i'm gonna go over the motivation behind this technology how we implement this and who are the key players in this in this effort so the basics of staking on ethereum are that validators put lock up a stake inside the protocol and they are expected to perform some duties these duties are basically producing blocks and attestations at specific times and the reason we want them to lock up a stake is so that we can penalize them if they do something bad so there are different types of penalties here if you are inactive if your node is offline and you fail to produce a duty you will be given a small penalty if you do something that's explicitly malicious uh like sign on two different chains at once then you will be given a larger slashing so penalties are going to come from offline behavior uh so for example if you fail to produce a block when you were supposed to or an attestation then um you would be given a small penalty slashing comes from explicit misbehavior so if you vote for two different chains at the same time this is basically accountable uh bad behavior and we have evidence of it because you made those votes and we can use those to slash your stake there are some inherent risks involved with staking so the biggest risk is probably key theft and key theft encapsulates a bit more than just the theft it's more about who has control and ownership of your key so an example is if you're an institutional staker running thousands of validators and you trust one employee with the keys of them all then you're trusting them not to do you know configure your software incorrectly or practice good security practices right if you're an individual staker and you're using a staking provider you are trusting them with your staking key so if they they do something bad it's your validator and your stake that that gets slashed so um this is the first risk the second risk is node failure this is more about uh the software itself failing because of a software bug maybe it's a network failure maybe it's a disk failure any of those things and we want to prevent against both of these risks so how do you protect against it key theft the problem is that your staking key is in a centralized location like one machine or one individual or one staking provider and you want to decentralize this to remove this centralized point of failure and the way you do this is using a magic technology called secret shared keys and threshold signatures so the analogy i like to use is horcruxes from harry potter where you take your key and you break it into multiple pieces and if you want to control or steal the key you have to control multiple pieces of this key rather than just one place where it exists so um in this diagram at the bottom here um [Music] n is your basically your staking key and you break it into three pieces n1 n2 and n3 and the proper the good property that we have is if each of these three smaller pieces sign over the same data and so the green blocks on the right are the signatures from those smaller keys um so signature n1 signature n2 signature n3 you can combine those signatures to form a signature from your original key so this is sort of magic technology because a person who tries to verify the signature at the end does not know that your staking key was split into pieces so it works perfectly with the ethereum protocol today that's uh how you prevent against key theft how you prevent against node failure is good old redundancy right so you have multiple ethereum clients that run your validator and if some of them go offline you have a failover protocol for the others the problem with this is if your redundant nodes are not in the same state they might inadvertently vote for two different chains right without any malicious intent it might just so happen that your nodes aren't synced properly and they vote for different chains in this case this is a malicious action that the protocol can detect and get your stake slashed so you want not just redundant instances but consensus among these redundant instances so this is not consensus in the ethereum protocol this is consensus among your redundant ethereum software instances so that all your you know split validators are voting for the same chain they are in the same state so we use a combination of these three techniques which is threshold signatures and recombination of those redundancy in nodes and consensus among these redundant nodes in a distributed validator architecture so you have multiple client instances for the same validator each of these instances has a small piece of the staking key it does not none of the instances have the entire staking key so if one of them gets compromised an attacker gets into your machine they don't they don't get the entire staking key they would have to kind of violate security at multiple places and the third technique we use is consensus among these redundant instances so that um you always vote all your instances vote in the same manner so what's the latest and greatest in validator architecture today you have two pieces of the puzzle one is the beacon node the other is the validator client the beacon node is the outward facing component it interacts with the ethereum p2p layer so it will produce blocks it will gossip blocks download new blocks keep track of what the chain is and it's generally exposed to the outside world the validator client is a more private instance it communicates only with your beacon node and the most important point to note here is your validator client has direct access to your staking key so you really don't want to expose it anywhere else except your beacon node so this is the architecture today and clearly you can see that you know there's only one place where the key exists if your validated client breaks down or something happens to it your entire node your entire ethereum validator is going to fail so one way to decentralize this is take your staking key break it up into pieces using secret sharing and you say you break it up into four pieces and you connect it to the same beacon node so you have the security property that you have the attacker has to violate security at multiple of these um validator clients to get your staking key but you still have a single point of failure in the beacon node and this is why we need a more complex architecture to orchestrate the distributed validator protocol and the the technique we've gone with is putting a middleware in between your beacon node and the piece that holds your validator keys so one nuance here is it looks like you won't be able to use normal validator clients for this because they don't accept incoming connections so you can't instruct a validated client to for example sign a message so you'll have to use something called a remote signer to do this but the architecture remains exactly the same you have your beacon node and your remote signer and the middle is this distributed validator middleware um what does this software do so we are going to call the piece of software that orchestrates all this the distributed validator client so the beacon node communicates with the distributed validator client as if it's a usual ethereum validator client and the dvc is going to kind of make sure that everything that you ask your remote signer to sign goes through a layer of consensus so all your instances are signing the same thing and the beauty of this is once you reconstruct signatures from these smaller you know pieces of the puzzle to the entire ethereum network the signatures look exactly the same as if you have a single validator so this has no disruption other than your own staking infrastructure so you can decentralize your own staking infrastructure without any changes required to the protocol which is great so some decisions to be made here are which consensus protocol you use and the properties you want are optimal resilience so it is it can tolerate basically the maximum number of safety and lightness faults and rather more importantly you want a fast leader change so the way this works is you have let's say your duty to produce a block uh when your trigger goes off you start a process of consensus among your nodes and if something goes wrong in this process of consensus you want to recover from that really quickly so that you can make your duty on time if your duty is not on time the ethereum protocol may just ignore the block that you produced and you don't get rewarded for it you would rather get penalized for an action so you want fast leader change and one candidate we have is istanbul bft uh there's a newer version of this called qbft that some of our collaborators have been working on and looks like we'll be using that so here's the announcement we have a specifications for how to implement the software which we have made public quite recently um that's the qr code if you want to scan it i'll leave it up for just a second all right and the key persons involved here are myself my co-workers karl and dankarat from the ethereum foundation from obol we have colin and osin who's sitting right there we have elon from ssv.network and one of our key collaborators is roberto from consensus who has uh you know been helping out with creation of the specs and we are going to get it formally verified so yeah also my co-worker carl stock is at 12 40 at the main stage and he's going to give a meme driven talk so it'll be much more exciting than what i have shared with you today right that's all from my side you can find me if you have any questions i won't stay on the stage any longer