# 'Secret Shared Validators - The Next Chapter for Validator Resiliency on ETH2' - Mara Schmiedt - Channel: [ETHGlobal](https://streameth.org/ethglobal) - Date: 2021-10-09 - Duration: 21:31 - Topics: mara schmiedt, coinbase, ethereum, ethglobal, secret shared validators, eth2, bison trails - Watch: https://streameth.org/watch/yt-tRczUIIrz5k - YouTube: https://www.youtube.com/watch?v=tRczUIIrz5k ## Description Join Mara of Bison Trails Coinbase for a run-through of Secret Shared Validators, a method of improving network resiliency coming in ETH2. ---------------------------------------------------- Follow us: https://twitter.com/ETHGlobal https://ethglobal.co Email: hello@ethglobal.co ## Transcript next up we have mara from coinbase who will be chatting about secret shared validators the next chapter for valley data resiliency on east 2 which is an exciting effort in collaboration with the ethereum foundation that just rolled into the test set mara welcome hello everyone let me know if this works and if you guys can hear me all right awesome cool let's get it kicked off um incredibly happy that superfiz actually preceded this conversation because it said a lot sets a lot of the context around what we're actually going to be talking about um as part of this presentation um so secret chart validators um as just discussed is an effort that's kind of been underway for almost a year now um to address certain parts of validator resiliency improvements um for eth2 um so without further ado let's just jump in awesome so you guys have probably heard a little bit about this throughout the summit today um but just like a quick recap um on what the duties of a validator are on eth2 so validators and short are responsible for participating in consensus activities on the network so producing blocks and attestations in order to participate each validator has to put up a 32 east security deposit and much serves as like a form of collateral to ensure that participants are incentivized to behave honestly and truthfully in the network for doing that validators receive rewards the current annual reward rate is around 7.8 percent for fulfilling those duties um but a failure to perform in line with those duties uh result result in punitive measures so there's two types superfiz just kind of run through them with you but penalties are incurred when you're offline so when your validator is requested to attest or propose a block and you're offline basically you're missing out on rewards that your validator would have earned if you would have been online the second mechanism is slashing and flashing is really there to disincentivize malicious behavior so in the later phases of ethio there's going to be different types of punitive measures but for today and as part of phase zero the two major ways in which a validator can get slashed is either through double voting or surround voting and then in later phases of eth2 there will be an introduction of other types of punitive measures around validators um not storing available chart data or not making that available um so that's really to present um to prevent and disincentivize the withholding of information and making sure that validators are behaving as they're supposed to so there are a few possible scenarios in which a slashing event can be incurred and not all of them are necessarily a malicious attack even though the network doesn't really make that distinction so a really good example of that and we talked about it in the previous talk is there can be misconfigurations that happen at the topology level in which validators are operated and in many cases that actually happens because multiple validators are run on identical instances with where the where keys are the identical key um for the validators are operated on multiple instances so to date there's been a few major slashing events where um these types of issues have actually occurred and i think the community is in agreement that this is definitely something that needs to be avoided um but it's not uncommon for for early rollouts and infrastructure configurations so um that's definitely one of the areas that we've observed and taken learnings from over the last few months so just to summarize a little bit around really what what validator duties look like on e3 so in order to really provide a resilient public good uh for the ethereum mainnet and also to make sure that your validators are actually performant and rewarded for what they're doing there's really two categories that are important to keep in mind so the first one is liveliness so making sure that you're online don't be offline the second one is safety and safety can really be bucketed into two things so ensuring you're not producing any slashable offenses and making sure that you don't run multiple instances with the exact same validator key the other one really is like protect your keys so your validator keys they need to be safe make sure that there's no compromise that can occur to avoid malicious attacks or behavior on your validator so preventing validator failures this is really where you know we get into the nitty-gritties like how do you actually make sure that those failure modes are addressed so let's talk about the first one so liveliness failures they can occur both at your beacon node or the validator client level so they can result as misconfigurations or issues with your hardware the software you know network level or if you're leveraging a cloud provider potential cloud provider outages or general or localized power outages so really the main form of mitigation for this type of validator failure mode is redundancy so making sure that you're running your node across different instances that have diversification across different components so validator clients uh different cloud providers on-prem versus off on cloud and making sure that that redundancy is built into your node topology to prevent against single points of failure for your node operation so the second one is uh safety failures so byzantine faults and byzantine falls really occur when operating nodes in a distributed network have a conflicting like view on what reality looks like and this can happen as a result of a software book or a network attack that happens at a broader level so this really can be mitigated through fault tolerant consensus mechanisms where the consensus um on what is the truth is achieved across a number of different node instances so really byzantine fault tolerance is a feature that is part of eth2 at the network level but it's not something that's been implemented necessarily at the individual node level to ensure that there's fall tolerance and some type of consensus mechanism at the validator level to make sure that there's no byzantine failure that relates to that and then last but not least uh safety failures relating to key compromise so um you know this happens when he gets compromised when it's not safely and securely stored but in many ways also when you're key you know is in its compromised form um and susceptible to attack so mitigation measures for that including protecting uh for key compromise through something that is called threshold signatures so validator keys can actually be split and a threshold signing mechanism can be introduced to ensure that signatures can be combined to produce a complete signature so bls signatures on ether are additive which make them really friendly to aggregation and there's different ways in which uh e3 validator keys can be split so either through a distributed key generation mechanism or show me a secret sharing amongst a group of network operators with a corresponding threshold and then making sure that different share signatures and that threshold is required to command a validator so if you split an initial validator key into four individual shares setting a threshold and byzantine fault tolerant threshold at around three validator signatures required to command the validator then that would be um a good failure mode to protect to protect against keep compromise from that perspective so really to um sum up what optimally resistant used to infrastructure looks like really can be comprised of just three components that are key to that so to protect against various node failure modes that can exist the three key things are having and leveraging threshold threshold signatures ensuring that there is redundancy and a consensus layer to coordinate your validator and that really introduces sacred shared validators so um we kind of ran through it secretary validators are really comprised of all of these key elements um you can think of it as a open source middleware for improving validator configurations or in a more simple term it really acts like a large multisig for distributed consensus finding duties on the ethereum blockchain for individual validators so the first step in an ssv setup is to split an existing key again as mentioned there's two ways to do that you can use xiaomi's secret sharing for an existing key or you can jointly generate a secret key amongst different parties leveraging distributed key generation schemes so the second part of this is a coordination mechanism so ssv requires a coordination mechanism with a consensus algorithm that is used to coordinate the beacon nodes that utilize uh the special signatures that are set so the consensus algorithm that is utilized to achieve fault tolerance as we mentioned earlier in this example and the way that it's been constructed today is leveraging istanbul bft so this is a deterministic leader based consensus algorithm so you can tolerate up to one third of the nodes failing in the setup so really key splitting and ibft so the consensus layer that coordinate different ssvs are the foundation of every single ssv node so first nodes decide on what to sign and then after that sign the data and then reconstruct in in line with the threshold signature scheme what is to be broadcasted so what you can see here is full redundancy components across your beacon notes your validator clients and then a consensus layer that basically coordinates a threshold signing scheme between these different components of the validator instance so this doesn't only provide superior safety configurations but it eliminates single points of failures and it enables a variety of redundancy capabilities at all different types and layers across the topology of your validator so what can this really be used for and really that's like kind of the brunt of what i want to focus on for this conversation because ssvs are really a middleware that almost serve as a primitive they enable a lot of use cases and all of those use cases are really intended to drive better infrastructure resiliency for the entire eastern network so let's talk about three main components i'm expecting there to be a variety of applications and we're already seeing some of these developed today so let's talk about what this means for infrastructure providers so as an infrastructure provider and this is you know offering infrastructure services to other stakers one of the main benefits of an ssb configuration is the fact that that you can achieve active active cluster redundancy across all the sub components that your clusters comprise so you can have different validator clients within the same instance talking to each other through the ssv api you can deploy them across different cloud providers different regions and your validator still acts in unison through that consensus mechanism to ensure that you really have minimal service disruptions and really enhance the resiliency to protect against node failure so there are also interestingly and potential dynamic dynamic deployments that can be leveraged through this for this particular use case so for example you can imagine a world in which you know different providers are making up an ssv node and offering those services to the market you could also imagine you know a customer having an in-house setup and leveraging a provider as part of the ssv configuration to stake their eat in a distributed voting power type of manner so the second one is at home validators that operate their own infrastructure in many cases um at-home validators don't necessarily have access to or the technical capabilities to implement this like multi-level redundancy into their existing infrastructure and introducing additional security measures to their existing configurations so ssb middleware for at home validators really serves to support the validator and distributing distributing their signing power to dramatically decrease the risk of failures and downtime penalties and what i would envision and really hope for is that you know one day this can really just be deployed through something like that mode it's like a package that helps you simplify the setup and the deployment process if you're an at-home validator in a way that you can like opt-in to choosing um an infrastructure setup that is significantly more secure and brazilian the last one is staking pools so today the most prominent decentralized taking pools are operated through single validator architectures so what that means is usually what happens is there's a pooling of stakers eth that basically gets bundled up into 32 each chunks and then the 32 eth gets assigned to a you know robin hood type selected validator within the pool so again that validator serves as a potential single source of failure and in many ways there can exist scenarios in which if different validators inside of the pool are operating with similar infrastructure component and so call that all of them using the prism client or you know some of them and the majority of them being deployed on the same cloud provider then you really run into the risk of you know introducing more severe risk measures into the decentralized taking pool so as a result of leveraging this type of configuration you introduce fall tolerance which fall tolerance on the pool level and single validator pool setups doesn't really exist yet so that really significantly improves network up time um and security and we're already seeing blocks who's one of the partners on this program with us leveraging this implementation to build trustless staking pools um for their stakers so super excited to already see that part coming into fruition um and on to the next one so give everyone like a little bit of context on um how we got here so the research group group for this effort was actually formed back in july 2020 which is crazy to think um and um throughout the process um incredible efforts and help has been provided from the ef um on the research front so john kratt aditya and carl have been doing tremendous work um on pushing forward a lot of the components that you know today have actually turned into a functioning test net so we've been supported by ground from the ef uh back in february and really with the core purpose of bringing something to the community that is an open source ssb middleware solution that can be leveraged and implemented across different um use cases that that is applicable to so uh we rolled out the ssb test net um on april 20th so actually just a few days ago and we have a group of 12 experienced node operators both at-home validators client teams and staking providers currently testing the implementation we're very likely to roll out a second test net to a broader group of participants later in the quarter and this really serves to like ensure that we've conducted sufficient testing before getting the initial implementation um out for an audit and then making sure that it gets released to the community for further work so there's always ways to get involved we'd love for you to get involved so um you can connect on the discord we're in the in the official um ether r d channel if you scroll down secret validators has a little thread you can also scan the qr code um and that's where most of the conversation is happening at the moment you can also check out the github loads of information on there including information about the test net so if you want to participate in that as it comes up again we'd love to have you and if you want to just ping some questions you want to connect feel free to hit me up on twitter um just under my name and yeah we'd love to have you there so much for introducing uh secret chat validators we have lots of questions for you so i'm just gonna go ahead and relay them to you um first up um during secret sharing we need full consensus and during signature generation ibft is used so ibft is used as the consensus layer so this is more to ensure that there is um like a threshold signature mechanism at the consensus layer that coordinates the different ssb nodes so for the current test net implementation we're leveraging xiaomi secret sharing we're not leveraging a dkg although it's currently in research mode and in the future we're really trying to like add more advanced functions that currently some of the teams that have been uh supported through the ef are working on so like as we look into like future phases of the rollouts um we have a team called platon working on multi-party computation um for a proof of custody scheme there could be leverage for this as well the parameters for the ibft the same as the threshold for signing sorry could you repeat that for the ibft the same as the threshold for signing yeah so basically the way that um the threshold the recommended threshold signature scheme would be set up is ensuring that you use a three out of four scheme um it can be changed and altered for example if you were optimizing for things that were not necessarily designed to be fault tolerant if you are for example an individual validator but in the reference implementation that is the recommended specification then the next question for home validators i guess mara what are the risk factors if we have set up our validator keys on a separate offline throwaway machine if you've set up your validator keys on a separate flying throwaway machine so i can't answer that in terms of like as it relates to the comparison of this configuration if you're an at-home validator and you have adequate like validator private key protection mechanisms um as you know like came up in the last talk like we haven't observed like a massive amount of like punitive measures on at-home validators really oftentimes that we've observed slashings on mainnet has really been a consequence of misconfigurations on like validator pools and staking providers um so i would say like just in terms of configurations obviously you would continue being able to operate that but with this mechanism you'd be able to operate a node that just you know has some degree of fault tolerance on being able to coordinate across redundant components and we have a question connected to our talk that we listened to earlier today um is there a plan to integrate this with vouch i'm not sure if you're familiar with march i am not probably i should be but um whoever's involved please let me know um would love to take a look uh we we had this talk uh just three talks ago um it's an open source across many data it's a test in teams jim is working on it right yeah yeah i loved him their team's great okay are there any more questions that i can relate to mara let's check the chat um does not look like it keep them coming guys we have a few more minutes and if there are no further questions um i'd say let's move on to the next speaker thank you so much bara hey everyone happy friday