# 'Secret-shared validator infrastructure for Eth2.0' - Aditya Asgaonkar

- Channel: [ETHGlobal](https://streameth.org/ethglobal)
- Date: 2021-10-09
- Duration: 22:06
- Topics: Aditya Asgaonkar, Ethereum, ETHOnline, Eth2
- Watch: https://streameth.org/watch/yt-awBX1SrXOhk
- YouTube: https://www.youtube.com/watch?v=awBX1SrXOhk

## Description

"Achieving resilience against node failures and securing against key theft as an Eth2 staker.

## Transcript

speaker is aditya he is a researcher at the ethereum foundation he specializes in consensus research and spends a lot of his time focused on eth2 he's going to give us a talk today about um secret shared validator infrastructure for eth2 it's about achieving resilience against node failures and securing against key theft as an eth2 staker so without further ado i'm gonna go over hand it over to aditya hey there thanks for the introduction emily let me share my skin real quick all right hello everyone i guess we have uh two more minutes until we start so yeah you just wait till then you are you are fully good to go if you just want to learn okay cool yeah sure yep hello everyone i'm aditya uh i work on consensus things at the ef mostly focused on casper and eth2 today i'm going to be sharing a presentation on secret shared validator infrastructure so let's dive right into it uh sticking on eth2 uh ethereum two is a proof of stake network which means that validators put up a security deposit uh in order to enter as a validator and the deposit is insurance so that they perform their duties correctly and the duties consist of producing blocks and attestations at the time specified by the eth2 protocol and the main reason for the existence of the security deposit is having strong disincentives for validators uh doing bad things so a couple of bad things exist so inaction on the part of the validator leads to penalties and malicious actions on the part of the validator lead to slashings both of these are reductions in the security deposit that the validator put up so more specifically penalties result from offline behavior such as failing to produce a block or an attestation when required and slashings result from misbehavior which is provable malicious actions such as making to conflicting blocks or conflicting attestations in the same slot or violating some of the casper ffg consensus rules so i'm sure a lot of our listeners here are very interested in becoming eth2 stakers and there's a couple of risks involved with them some of them are very serious the two most serious risks are key theft and note failure so key theft is when the validated key that you're using on the eth2 network is is stolen and there are a couple of keys that are involved in the process the staking key with which you sign blocks and messages and the withdrawal key which you use to withdraw your security deposit at the end of your term and the other major failure is uh node failure where your e2 node that is running your validator just goes offline or it produces some unexpected behavior and of course our goal uh with the resilient validator infrastructure is preventing against both of these types of uh failures and or theft so how do we go about that exactly um let's look at key theft first so obviously key theft as i said before is when your validator key has been stolen so maybe the machine that you're using to run your validator it it obviously contains your uh entire private key uh if your machine is compromised then your key can be stolen uh if if you're not running your machine yourself you're running it in the cloud uh if your cloud architecture is compromised uh that can happen easily if you're using a staking provider that holds your keys uh that can lead to uh like that can lead to situations like this uh but there are standard ways to prevent against key theft uh the most usual way to do this is using threshold signatures uh what this means is you take the existing singular private key which is your entire private key and you break it into multiple smaller parts and you break it up such that signatures from any of the smaller parts can be combined into producing a signature for the complete key so as you can see in the figures at the bottom the key n is split into three parts n one n two and n three and signatures on the same data from n one n two and n three can be combined to produce a signature as if it has come from the entire private key in so if we split our keys in such a way and kind of you know provide it's it's something it's sort of like horcruxes in uh harry potter where you just uh put one each in different places and then you're secured against uh key theft unless someone goes ahead and attacks all of them at once the second failure was note failure and there's two major subparts in this the first one is crash faults which is your node going offline and this can be caused by a number of factors most of which are out of her control such as power outages network outages hardware failures or software clashes and the usual way to prevent against this is using redundancy so instead of running a single e2 validator uh with for so for a single e2 validator instead of running just one instance of the each two client we run multiple instances multiple redundant instances so that if some of them fail you still have the others as a backup uh the other kind of fault is byzantine faults where your node isn't exactly going offline but it is producing unexpected uh behavior uh which can cause slashable events so this can be caused by software bugs in the ethereum client it can be caused by network attacks where an attacker has taken control of the network around your node and the attacker is sending messages uh in such a way that you are influenced to produce uh bad bad messages and you we can prevent against this by having uh having a consensus instance running among uh the multiple redundant eth2 validators that you are running or rather the multiple redundant eth2 nodes that you are running for the same validator uh this is so that no node is making unilateral decisions only if a majority of the nodes sign off on something only then do all of the nodes produce a certain message or a block so the the most resilient eth2 staking architecture is going to be a combination of all of the things that we discussed uh so namely threshold signatures uh redundancy among nodes and consensus among these redundant node instances so uh what does this mean exactly it means that we are going to run multiple each two nodes uh for the same validator each of these redundant nodes uh is only going to have custody of a part of the private key but not the entire private key for the each two validator and the third one is that there is a consensus instance running among all of these redundant nodes and nodes only sign messages if the consensus running among these nodes instructs them to do so essentially the last point here creates uh makes these redundant instances replicated so that all of them always have the same state and uh transition in the same way so if this is the current eth2 architecture where you we have a single validated v and the entire private key is uh existing at this validator instance uh what i'm suggesting or rather what the resident architecture would be is something like this where we split up the the key in multiple places uh so here we split it up four ways and uh we put we put the parts of this key in redundant e2 nodes so v1 through v4 are the redundant nodes and we have a consensus instance running among these nodes so that none of them is unilaterally taking decisions right but it's in practice it's a bit more complicated than than that and in order to understand that we should discuss a little bit more about the ease to client architecture so an e2 e2 node right now consists of two major parts uh the first one is the beacon node and this is the part that takes care of peer-to-peer networking chain tracking for choice management etc this is the part that is directly exposed to the network so the beacon node is responsible for gossiping messages uh verifying that the messages it has received is valid and so on uh and this the beacon node can be run by users who are not stakers so just like get today you don't have to be a miner to run get just like that you don't have to be a staker to run the beacon node you can just run it in order to get information about the beacon chain so that's the beacon node the second part is the validator client this is a rather uh lighter piece of software uh the main responsibilities of the validator client is handling the validator private keys and signing blocks and attestations when it is the correct time and the validated client is only connected to the stakers uh beacon node in order to get information about the network that is uh unsigned attestations and blocks that the validated client will then sign and publish to the network so the validator client is in no way connected to the e2 network directly so this is what the current architecture looks like we have a beacon node and a validator client connected to it and the validator client has the entire key so a resilient architecture would be splitting up the validator key into multiple pieces so key one through key four and also uh assigning them to redundant uh validator client instances so again uh v12 through v4 other uh validator client instances and all of these are put into a consensus group so that uh if there is a bug at say v3 uh that causes it to sign something bad uh that that basically won't go through because all of the other all of the other validator client instances have to come to consensus about what to sign before any of the any of the clients uh actually sign anything so this results in a replication of these redundant instances uh which which is a really important part so this is better than the previous architecture but this is still not the best we can achieve because obviously there is a single point of failure which is the the beacon node itself so the beacon node is how all of these validated clients are uh getting information about the eth2 network they have no way of connecting to the e2 network otherwise so if the beacon node fails the validated clients will not know what's going on on the e3 network they have no information about the chain uh they don't know how to produce blocks uh without a beacon node so this even though this is better than the current architecture it's not the best we can achieve so in practice the best architecture that gives us the the highest resilience looks something like this uh so we have multiple beacon nodes we have multiple validated clients and we have some secret shared validated middleware that is running uh in between interfacing the beacon nodes to the validated lines so this middleware consists of these ssv clients uh this these secret shared validator instances uh which are responsible for uh basically managing the timing uh managing instantiating uh consensus proto instantiation the consensus instances uh for each block or each slot and so on um and anything that goes uh from the secret shared validator middleware to the validated client should be put through consensus instance so that all of these validated clients are in the same replicated state they sign off exactly the same things there's no situation where some of them sign on one fork and the other sign on another fork and then we have a deadlock that should not happen and hence this consensus filter basically so there's a few more parts that are required to make this work uh the most notable is this uh signature signature combination component so each of these validated clients since they only have a part of the key they produce threshold signatures and all of these threshold signatures have to be combined in order to make something that is tangible to the eth2 network and this entire architecture is going to be a single eth2 validator and specifically for these numbers right here where we have a three out of four signature combination and we have four uh redundant instances uh we can tolerate one failure so one node can go completely offline and we can still uh have all the good properties about our network about our validator so there are a few design choices that were made on the way the most notable is the consensus algorithm in itself the requirements for this were that it has optimal resilience that is it tolerates the maximum number of faults that are possible which is one-third we want this because in order to achieve the same fault tolerance we want to run the minimum number of nodes possible and reduce our staking costs that way the second requirement is fast leader change so the consensus algorithms have a leader which proposes what the consensus value should be and if the leader fails we have to change the leader in order to achieve consensus and we want to do this in a really fast daily responsive way because the eth2 network expects validators to produce messages at a certain time and obviously we'll run the consensus algorithm at some time before uh the expected time to produce blocks or at the stations but if the leader fails we want to be able to conduct the failover and have the new leader propose a block or an attestation as soon as possible so that we can still produce a block or an attestation before our expected time and the perfect the almost perfect candidate for this is istanbul bfd uh which has all the good properties that we want and you can find more information about that on this link in this paper so some additional information there is a proof of concept uh made by uh dankerad and alan and you can find the proof of concept at this uh on this github repo uh we had a validator running using this poc on medasha testnet for a while i don't think it's active right now but you can go ahead and explore that if you're interested some more additional information the key people involved in the secret shared validator effort are from the ethereum foundation tank rad and myself from consensus uh mara and colin and from blocks taking uh block slot io alon who's been really helpful with the proof of concept thank you that was all from my side and my contact information is on your screen hit me up if you are interested in secret shared validators have any questions or want to get involved all right thank you so much if you don't mind sticking around we do have a couple questions that came up in the chat and also a reminder to everyone once again uh if you have questions for aditya or for any of our speakers go to live.ethonline.org for starters great talk i really enjoyed the harry potter reference there's like not enough of those in the ethereum world but the first question we have is uh you know this sounds like a really good step forward for validation security uh are there any trade-offs to it uh like additional bandwidth more complex complexity for like node operators right so i think the most important one is the complexity in operating this node it the eth2 clients are already a complex piece of software and even even the technically competent users have have issues running each two clients so running this kind of a complicated setup across multiple machines is going to be a challenge and unless there is tooling to make this easier i definitely don't recommend normal users to do this but this is a giant leap forward in terms of uh resilience at the validator level um i hope that the major staking providers or exchanges who are doing staking use this kind of an architecture so that they don't experience uh some of the issues that we have seen in the test nets um yep but this is definitely a complex piece of engineering and it will take time to define this cool next question uh so what are other improvements what are other improvements that are left before this can be used at scale for mainnet validators like besides launching mainnet right so i think all of the research problems are taken care of basically what i described they're not redundancy and replication those are the two main pillars on which this entire architecture is built the research is all done it's basically uh time to implement this for a production ready set up so i guess my final question really is how can get people get involved i know you sort of touched out on their slides but if you want to reiterate that would be great and more importantly like what are some of the things that you would like help with right so as i said before uh there's a few key people involved in this effort uh the contact information is on the screen right now you can reach out to dankrad or myself through our emails and we'll certainly be able to figure out the best way for people to help us uh depending on their skills right now we are looking for people to maybe get involved in uh implementing a production ready uh software uh in order to run this that would be a great great help for us uh sticking providers are encouraged to maybe contribute resources or time in into making this uh because this this will definitely be helpful for them but obviously anyone else who's interested in uh making this work uh should hit us up yeah that's good to hear um actually we have another question that came up in the chat if you're down okay the question is do you expect this to be used more so by individuals or entities for heightened security or do you think it'll be more used to enable trustless pools so solely this is not enough for trustless pools uh there is an entire set of other things that are required for tesla schools uh this addresses some of the issues uh in implementing trustless pools but those issues are i would say not fundamental um that said i do expect uh some solutions to appear uh using this i know alan from blocks blocks dot io is uh working to make uh convert this into a trustless staking setup um as far as individual validators go i think uh that the main trade-off is that in order to achieve the fault tolerance associated with one node failure uh now instead of running one node you have to run four nodes so four is the minimum number that you have to run just running two is not going to get any fault tolerance so because of the height and costs of uh of this taking setup i don't think uh single validators or individuals are really the target users here maybe whales who are sticking on this or staking providers who have huge stakes and a lot to lose it makes sense for them to bear these costs all right makes sense uh looks like that's it for questions um thank you so much for joining us great talk it was good seeing you i feel like i really miss seeing people in person these days um for sure yeah thanks for joining all right thanks everyone bye-bye