How to Design DVT While Ensuring Non-Correlation | Devcon Bogotá

foreign [Music] happy day three of Devcon six um before we get started today I just want to send a huge shout out to all the organizers all the people that came from all over the world and everyone who is at this talk today so appreciate it so today um I'm Colin Myers I'm co-founder of mobile Labs with ocean and today we are going to discuss designing DDT for non-correlation um so before we get started who is Obel labs uh best way to think of us is that we're an R D team we're focused on building a different ethereum infrastructure Technologies for staking uh today the core team consists of 16 members across eight countries so we're quite distributed um right now our main focus is delivering distributed validator technology for ethereum as a primary Network to begin with so before we dive a little bit deeper in today let's kind of talk about just ethereum as a whole and kind of the the road map of scalability so a lot of it we just had the merge and if anyone went to the opening ceremonies you know there's this ossification discussion happening which is essentially like hardening the things that we've put together the things that we've created and what we see here the three main areas that we've been focusing on um over the past few years to scale ethereum into its next chapter so on the left here the first area is the execution layer this is the most mature of all the different scalability Technologies and research studies that have been done over the years cryptographic Primitives that are used for this problem are optimistic in ZK Roll-Ups this comes through in the form of Layer Two um it's actually been quite interesting this week to see that layer two is taking over as they should and Layer Two honestly in my eyes seems to be the future of of what ethereum will build out of from a research perspective the second area ties to layer or two and as it matures more we are getting in front of the next problem which is the data layer so the data layer must also scale while execution scales common methodologies used for this is called Data availability sampling and and here are some examples of some few projects that are focusing on that the third piece which is kind of the most immature and not only like research and adoption and implementation is scaling the consensus layer like scaling consensus to date has basically been getting to Genesis and then getting to the merge and now that we're in this post merge World we're all kind of re-evaluating the consensus layer and saying how do we scale it more today what we're using is DVT as a cryptographic primitive and protocol to help scale the consensus layer now I'm going to take a million to describe what distributed validator technology is and a bit more words so at its most simple a distributed validator is an ethereum validator that runs across multiple machines um why you might want to do this is it protects you from a lot of Technical and social risks from validation and one of the first ones is software issues if you're running just one node and just one software client you know software generally doesn't like Run Forever without issue and similarly I'm running a distributed validator makes you more protected from Hardware risks as everyone kind of expects servers don't last forever and they die regularly enough um going one bit further if you take a distributed validator and you run it with other people so each person only has you know a subset of the private key that makes private key much more difficult privately compromised much more difficult because you have to compromise three or more different operators to get the full private key to you know flash or do whatever with it and the last one is a bit more abstract but it's the idea of if your validator goes Haywire they become a bad actor they've been hacked remote code execution whatever you'd like um generally you have no Safeguard if you just have all of your money with one validator it's just you're in trouble but if you have your money in a distributed validator and you have protection so long it's only a subset of validated you know become Byzantine or go away well or whatever you want to call it um another thing that's super important is to talk about who benefit from DVT and the great thing about it if we think more or less everyone involved in validation can benefit from it um the liquid sticking providers themselves they at the moment are trusting huge amounts of stake and to single operators and they're just kind of crossing their fingers and praying that nothing bad happens they would much prefer to be able to do to divide their stake across operator and then if you know anything bad happens to one there's you know no risk or no loss to the liquid staking protocol similarly the centralized providers can gain a lot from using distributed validator technology I had the pleasure of building block demons E2 staking platform um at Genesis and I know that you know you could reduce um devops risk of you know you have to wake them up in the middle of the night on a machine dive if you know you have a distributed validator similarly you can reduce your Hardware cost because most people put a very small amount of validators for any given machine because if it goes offline there's nothing you can do but if you have a fault tolerant validator you can start to safely increase the amount of keys per node and that can reduce your operating costs and then on the more extreme or like the further outer side of things a lot of centralized operators either ensure they're staking and slashing either on balance sheet or they go to a third-party provider for insurance and this is currently extremely expensive and not even every provider offers it because the thing to ensure in slashing is you know potentially you have to pay back everyone like all of that stake so if you have an operator with hundreds of millions of dollars and insurer has to potentially pay all of that stake you're going to have a really high premium but if you were instead running in a distributed validator and you know insurer says okay what's going to happen if they get compromised the um you know the worst case scenario was much lower and as a result the premium is hopefully going to be much lower the next thing I want to do is want to have Colin talk a bit about the market for distributed validators cool so how is stake accumulating um these were taken from uh Elias from raided uh his liquid staking dashboard on Dune um data in this area for for those of you watching and who were looking at data this is probably some of the best data on the status of pools and how they've accumulated over time and I would highly recommend it um so where are we at today this chart here starts on the left at Genesis which was December 2020 and it shows the the dramatic increase in pooled assets as a percentage of total staked assets over time so as we can see it's it's kind of quite frankly like you know exponentially growing today numbers where are we there's about six million each locked in pools that equates to around eight billion dollars today and it represents nearly 37 percent of stake in the network so the 37 have stake in the network is like probably the most important thing I want to touch on as it ties to like what our thesis is which ties to how we believe DVT should be designed um we believe that over the next 12 to 18 months that pooling will become dominant uh inside of most networks especially ethereum and we suspect that more than two-thirds of stake in the near future will be inside of pools DBT is uh today on the focal road map of pools to help decentralize and to help build themselves out therefore we believe that DVT saturation inside of these pools will also end up being 75 plus lastly this is important because DVT is ultimately a security protocol it comes in a middleware however it's based upon security so different than Mev boost right you use Mev boost to get more with DVT you use it to protect the largest reward which is consensus rewards we believe that DBT adoption will be kind of a winner take all Market due to its like security premises and the purpose of what it's used for so to kind of set the tone before we go into correlation here I just wanted to to give a size of the market our expectations of how DVT will sit inside of pools and then how large pools will be as a percentage of total stake therefore if if this thesis does play out it's incredibly important that DVT stay is helpful at scale instead of becoming more correlated and unhelpful so now we'll spend a little bit of time on slashing what it is and what it isn't so slashing the best way to think of slashing for for those of you as if it's a New Concept is slashing is like the defense mechanism or the immune system of proof of stake networks and what it's here to do it's it's punished it's here to punish you for not following the rules in an attempt to keep the network credible and to follow the rules of the protocol today there's two primary ways to get slashed the first one is a double sign back in proof of work this was called a double spend and this has been mostly predominantly um what the top slashing event in the network to date has been through and we'll get into like how how that's happened the second one is a bit more abstract um best way to think of it is walking back a slot height that you previously said was finalized now a more layman's term way of describing this is in the future you try to change something that you said was true in the past so therefore you're trying to like change State uh inside of the network and if you do that you'll be slashed for it inside of slashing there are different levels in degrees of slashing there is correlated slashing and uncorrelated slashing uncorrelated slashing today is predominantly that the most of what's taken place in the network we've been fortunate enough on mainnet to not see a large correlated event aside from maybe a couple small incidents and in an uncorrelated sense you can expect to lose up to a minimum of one eighth based on the state of what's happening in the network when it comes to correlated slashing I won't spend a whole lot of time digging into it but what everyone needs to know is is that in the event of like a a network-wide event correlated slashing can result in a validator losing all of their ether up to 32 which is much more of a catastrophic event so as we begin to like look at the future of slashing there's certain Technologies best practices that have kind of gotten over this uncorrelated slashing we'll definitely see a few in the network it's okay but now what we need to begin to prepare care for is as like stake scales and there's more products and more infrastructure providers how do we prevent correlated slashing because it's like what could take the whole network down or take all a validator stake okay so what is an activity penalty um this is super important because it's not slashing many people who are coming into the space now try to say that inactivity is a slashable defense by definition it's not and the way that we should think about inactivity is if your machine goes offline it's okay you can take the time to bring it back up online and you are you can expect to lose what you would have made so there is a penalty associated with it but it's not a slashing and it's not because you broke the rules it's just due to downtime um inactivity can also be more severe in scale um so if a large portion of the network is inactive um a big driving force in the E2 economics and design is this uh average percent uptime in the network so if that drops below 66 the inactivity penalty across the whole network will grow and grow and grow in an attempt to push ether out to rebalance it to get back to 66 percent so when it comes inactivity large inactivity events will result in sizable offenses for people still don't want to call them slashings but you can think of this mechanism as a way to rebalance the system to promote 66 percent of machines to turn their machines back on now we've discussed a bit what is the distributed validator technology what it's useful for and then we like you know had a bit of a refresher on slashing and inactivity now we'd like to discuss how we at Opel have made certain design decisions to minimize the correlation risk because as I said the tightly the slide is or this talk is how not to make things worse when we're trying to make them better so the first thing I wanted to talk about is the private keys because you know in a validator the private keys are more or less everything we've taken the decision to not allow any one entity to have the full private key that's not the customer that's not only one operator and instead all the operators come together and they do a distributed key generation which means they all take part in a bit of a protocol and they like contribute to entropy to it and at the end they all get their private keys and they get approved that everyone like took part and followed the rule fairly but there was never any moment where one person had the full private key for the validator this is super important because if somebody does you know they can run it in a validator and get you flashed um we don't put these private Keys you know more or less anywhere they're created on the machine where the validator will run we don't encrypt them and put them on chain or leave them anywhere anywhere where people could attack and compromise a large number of them um to follow through with that once we've helped create these validator private Keys we don't actually keep control over them um Chiron which is the name of the software opal has written is a non-custodial middleware which is a fancy way of saying it doesn't have the private Keys it just asks the validator to sign something for it um it sits in between the um it sits in between the beacon client and the like the beacon API and a validator client and it intercepts the traffic going between them um your current clients um all they really do is they play a consensus game and they say what are we going to ask the validators to sign and once they come to consensus on that they present that to each validator every validator says okay let me check my slashing rules have I already signed something at this height no okay that's good have I said financially with further than what I'm being asked to say no okay sweet I'm not going to get flashed I'll sign this message and I'll send it back to what I think is a beacon note we are actually sitting in the middleware there we intercept that signature we gossip them to the other different like nodes in the cluster and once any of them have enough of the partial signatures they can reconstruct they can reconstruct the aggregate signature and send it on to the network and the rest of the network says yep that's just a normal validator looks good to me what's nice about this middleware and not having the private Keys is you know if we are compromised the worst we can do is show something slashable to a validator client but we get to rely on the fact that the validator clients are independent have their own code probably don't have the same bugs and you know are not going to sign anything flashable um most likely however if you only have just one validator client there is a scenario where you know you find a zero day in that and you can convince them to to sign something flashable so one of the things we've been very focused on is being multi-client and what that means is you can run any of the validators that implement the spec and specifically we're still working on support for all of them but you can use Lighthouse and techu already and generally speaking in an Enterprise operator like distributed validator you want to have a mix of all the different Els all the different CLS all the different validator clients because if there is you know a burglar client you don't want it to have a majority of your distributed validator because then it will sign and you might get flashed and the only data point we have for a client bug like this was when prism had a timing bug back in the medasha test net and that was the most severe slashings across any test net or mainnet today yeah so the next thing I wanted to talk about is the networking side of things so over the last three design decisions we talked about we said how are we going to set up the private Keys you know how do we keep them maximally safe step one then step two is how do we keep our software you know out of the driver's seat we don't want to have total control over these private keys because if we can sign arbitrary data that's a threat you know you don't want you know something running more than 33 of the network if you know they can sign whatever without you know any oversight the third piece is obviously are multi-client implementation trying not to have exposure to any one piece of implementation makes you more like resilient to bugs and makes you less correlated and then the last one is more on the inactivity side so the three before have been all about preventing flashing preventing flashing preventing flashing but we also try and prevent downtime of course if you're running a highly available validator the pitch is that you're going to be up more often than if you're on a solo note and similarly if we had a distributed validator architecture where something goes wrong and we knocked off every distributed validator all at once the inactivity pattern could be rather severe and we would make things worse when we were trying to make them better so we have architected Karen's networking stack is they are totally independent from one another one group of people running a distributed validator over here has no common infrastructure with someone running it over in a separate place we think this is super important because it allows you to have non-correlation effectively if the alternative to this was if you kind of bound all of these together into a shared like networking layer like message boss or gossip Network the problem with that is well first start it's usually slower you have to go multiple hops around the internet and with the distributed validator time is money so you don't want to be doing that um but also if anything happens to this network you knock off all distributed validated simultaneously and that's something that we don't want to do so if you have a scenario where every distributive validator has their own independent networking and you know if anything does go wrong they go wrong separately and the nice piece about this is you know going through this like effort of making everyone set up new note like set up new networking is definitely a bit more hassle but the benefit of having independent clusters is you can also have independent versioning and what I mean by that is you know one of the scary things in software development is releasing an update because you're not really sure it's going to work and it's particularly scary if you're securing billions of dollars so the last thing we want to do is introduce a correlated outage by pushing a new version and it is you know pragmatic to assume that you know you'll push a broken version at some point we saw gets do it last month and you know they're probably the most experienced team in the space so it can more or less happen to anyone you shouldn't assume you're just not going to do it so instead you're like okay if we did push a bad version like how you know how can we minimize the issues and this is where having independent networking comes in if you have one cluster that's totally separate to another one you can update that one to version two and see what happens and if that's all healthy great you can update a second and a third and a fourth and you can gradually roll out this update across the network and if anything goes wrong you can kind of abort and you can kind of panic if you go the other way of we have shared messaging and you know everyone has to talk the same protocol you have to do what the kind of Els and CLS do which is you pick a slot number and you release a new version and you like add everyone on Discord and you pray to God that they have running the new version in time because if they're not running the new version they go offline and you also pray that the version is right because if there's anything wrong with it you knock everybody else off as well so yeah the inactivity side of things the like the penalties aren't as severe but it is also super important to us when designing distributed validators not to make things worse when we're trying to make them better and I'm going to hand it back to Colin for the last few closing thoughts cool yeah so to close it down um again appreciate everyone coming out um DBT is this I guess we've been working on it quite a long time but since uh East Denver at the beginning of this year it's really now begun to have its turn essentially of adoption um our North Star is a project today what we're most focused on is convincing everyone that validators are communities not individuals um today the way that the network topography sits is validators are a single key validators are a single person or validators are a single entity and with this technology we can migrate that Paradigm into validators being run predominantly by communities um so we have about five minutes left again since dbt's kind of been this new topic that's been introduced over the past few months we wanted to make sure we take time to answer anyone's questions and again thanks everyone for coming out pushing and incentivizing people to um have diversity in where the machines are is actually the real problem there right there's a variety of validators large ones that choose to run on Prem there's a variety that they choose to run in the cloud um we were at dinner last night and the menu was running on you know us Amazon East 2 and we just laughed because like everyone's running on us Amazon East too so there are like other types of correlated problems with internet usage that we necessarily can't fight but still susceptible to them I was wondering about the dkg itself recorded about the ceremony and how do you think about the risk that there is some problem with some data data centers or something and somehow like at one point two out of four Keys get lost like how probable do you think this is and what do you think about possible mitigations to to this problem yeah this is a very good question and this is um usually referred to as like verifiable secret sharing in like Academia and this is the thing of doing a tkg is one thing but how do you know it actually worked how do you know that you know everyone actually contributed everyone got a piece like they expected and usually there are two types of ways to prove a dkg is fair they're called verifiable secret sharing and publicly verifiable secret sharing But ultimately speaking at the end of a dkg everyone that's taking part they get a private key and they get a proof in a verifiable secret share you need to have one of the private keys to check the proof in a publicly verifiable Secret chair it's like a zero knowledge proof anime can just check that it's verified so yes it is actually super important to make sure that everyone took part and usually there's like challenge rounds built into dkg which says you know does everything look right does anyone want to hit the abortion is everyone going to like sign off on this and yeah at the end of a dkg normally there's a proof I think right now we have a VSS proof meaning only the peers no it was legit But ultimately we would like to add a zero knowledge proof so even like you know the Izzy alido can say yeah those four operators definitely do the dkg correctly because they wouldn't have been able to produce a VK proof otherwise for sure so the question because he's not miked up was you know what happens if people lose you know more than a subset of keys and honestly the answer is if you lose you know more than the threshold you're probably gonna you're probably out of luck to be perfectly on for generally speaking that's why you want four different operators and they should all make you know independent backups if you have two operators that didn't make backups and left them in the same Data Center and everything blew up uh yeah that's probably a big problem to be perfectly honest um and yeah that would be one of the ways where forced exits would be nice because then the person that the withdrawalikey could be like uh oh please send it back to me but what would realistically happen is right now you'd be offline and you'd be offline and should you hit 16 ether and get kicked out so yes if people don't back up their private Keys you know even in a distributed validator if you lose you know too many of the private Keys you're still screwed