#DappCon22: Day 1 - Obol, How Distributed Validator Tech Will Scale Ethereum Staking Infrastructure?

Transcript

yeah okay how's it going guys yeah okay great um before we get started today a special shout out to the whole team that put this together um we've been coming to daphnode since the very beginning uh very exciting uh one of the best conferences and we're excited to be here so shout out to everyone who put it together um building on the great presentation given before us around stake decentralization and scaling the network today ocean and I are going to chat with you all about distributed validator technology or DVT how it can be helpful what is it who are the different user types and ultimately as post merge we're now transitioning

into this new scalability era one of which includes scaling consensus and and we'll break that down for you you all today and explain what that means um so to get started uh who is opal Labs uh today um mobile Labs you can best think of us as a research and development team we're primarily focused on infrastructure for ethereum today primarily staking infrastructure we have 14 members spread across eight countries quite Diversified um in our approach to technology and also in the way that we design our team and right now our Sole and main focus is we're focused on the adoption of DVT through a concept called the opal Network what is the oval Network it's best to think of the oval network is a

collection of Open Source tools that can help accelerate the adoption of trust and minimize staking the oval Network enables ethereum stakers to create tests run and coordinate distribute validators our North Star here as we think about ourselves as a project is we want to enable ethereum validators to be run by communities instead of individuals today when you think of a validator you think of a single entity or you think of a single person with this technology and we believe the future of staking is putting the hands of validation into communities rather than just individuals so how do you scale a blockchain today ethereum's roadmap primarily consists of

three main areas of scaling the first and most popular and most mature layer of this is the execution layer common Technologies used for scaling this piece of the equation is optimistic in ZK Roll-Ups common projects here arbitrum and starkware optimism today there's many many flavors of different types of ZK projects which is great to see the second area of scaling is known as the data layer data availability sampling is one of the primary methodologies used to help scale this problem and today we have Celestia we have polygon Avail and eigenlayer is some examples of projects for working in this space the third piece of the equation to scale is consensus which we believe is the

most important part distributed validator technology has been what the community of ethereum has chosen to work with Implement and mature as a primary means to scale the consensus layer what does it mean to scale consensus um there is no perfect definition of this we can provide some thoughts about how we look at scaling consensus as Opel is a team first and foremost your main goal in this is to increase the number of machines projects like dap node and all of these other projects are here to like help serve actual making it easy and accessible for the number of machines to increase in the network so increasing participants first and foremost is how

you scale secondarily to that it's very important that it becomes easier and safer to become a validator a distributed validator technology is something that is being formally verified therefore what it can enable is an increase in liveness and safety at the same time for all validator types which is very important for scaling accessibility and security is also extremely important today as an at-home validator it's a bit scary the security isn't low but it's not super robust and if you're on vacation and your power goes out you know your node will go offline so ultimately like increasing security and accessibility at the same

time is a large key to scaling the last two pieces that we'll talk about have to do with slashing and different types of protocol risks that are created from the design of the protocol so a major design element of how eth2 works is correlated slashing uh and how it essentially disincentivizes people to have different setups rather than everyone having the same thing building middlewares like what we're doing with opal will spend some more time on implementation later and building all these other Technologies need to be done in a manner where correlation risks are not increased in the network and if we're building Technologies and staking pools and products that increase correlation uh

well then we're not putting ourselves in a great place ultimately as well lastly no one likes to get slashed it's very important that a lot of the time that we spend on scaling the network has done so in a manner that decreases the risk of slashing to users to enable an easier experience and more of a peace of mind based experience so what is distributed validator technology um distributed validator technology is the software that allows the validator to run across multiple machines this is important because it protects you from software faults and you'll see later on that we run with quite a number of the clients so you know software fails often enough so you want to be protected from

that similarly Hardware most people will at some point if they're running a validator realize that their machine will die and right now there's no safe way to recover it or to like fail over without DBT um going a bit further when you have multiple groups of humans running a validator together that makes compromising the private key much more difficult because you have to compromise you know three people to get a validator private key and then lastly if you know you're running in a multi-operator situation and something goes wrong and one client goes completely like misbehaving um because these clusters are fall Talent fault tolerant and Byzantine fault tolerant at that and that is safe and you're the the honest nodes will just ignore the bad acting node

so why does this matter and you know where does DVT fit into kind of proof of stake in the journey we've been on so far um proof of stake most people know has been discussed since before even Genesis and the kind of first type of like proof of State chains we saw in production came about in about 2017 and most of them were delegated proof of stake and they range between 30 and 100 validators and the original Serenity design came out in 2018 and that used the ad25519 curve and thought it could go to one thousand to ten thousand validators which set the floor at 1 500 each which was still very prohibitive um fortunately with the adoption of the

BLS signature scheme and we have more or less the design we have today which can scale to the millions of validators and I came to a threshold of 32 each and we see DVT as the next iteration of this and we've started this talk talking about how we can radically scale the consensus layer and we think if you split these blf validators into groups and into clusters you can get another order of magnitude growth and the big thing that we're trying to get across is that these don't have to be all run by one person you can have multiple humans or multiple entities running one validator together um so yeah to talk a little bit about how it's implemented you can Implement DVT with a custom validator client that

has total control over the private keys and can decide what to sign but that is quite brittle and that introduces quite a lot of correlation risk Instead at oball we have built Caron as a middleware and what that means is it sits between a normal validator client and a normal Beacon client and it intercepts the HTTP communication between them um Karen doesn't have any private keys and all it does is amongst its peers it decides what every validator will be asked to sign and then once the validators which are the like normal validator clients and you know check their flashing we will say this looks good to me and sign it and return a signature the Cara nodes aggregate them into a group signature and send that to the beacon node and from there you know the rest of the chain doesn't know that

this validator is a distributed validator or not what's nice about this design is it allows you to have lots of different clients you can have different El CLS and validator clients um so we're going to briefly talk a bit about the kind of benefits of DVT and what they are for different entities um each kind of customer protagon you might say have like different ones and different needs when it comes to distributed validators they're you know the liquid staking pools they're The Trusted validators they're the at-home validators and there's kind of the new group called kind of collective or Community validators I'm going to start by talking a little about the liquid staking pools um the liquid staking pools at the

moment their you know decentralizing by taking in many new operators and giving money The Operators like a small amount to their stake but they still have to put a huge amount of trust into these operators if you know one of them you know goes bust in the morning or someone kind of kicks their door in you know that that could be like a decent percentage of that pool stake at risk and if they adopt DVT they can have multiple clients or they could have multiple operators sharing in one validator and the risk in any one operator is much much reduced and this can also be used to scale the operator set because you can start to mix trusted operators with untrusted home stakers in for example a four node cluster if you had two Dow operators and two home stakers you can be sure that at least

three people took part in every signing um we think that DVT and all of this Tech Will Allow the liquid staking pools to kind of really become much more decentralized and grow their Operator Operator set and be you know much more distributed for like the coming years the other one I'm going to focus on are the trusted validators and this is the like for your your coinbase your figment your black demon and so on these people um why they need dvts may be slightly different um for the most part um they hope to reduce their operating costs by having a fault tolerant cluster that you know if it goes down at night no big deal the devops can sleep through the night they can fix it in the morning

and similarly with the robust fault tolerance system they can increase the amount of private Keys per node and reduce their Hardware costs and some of the more out there things are flashing Insurance a lot of um trusted operators you know fund fully flashing insurance this is very expensive when they have total control over a private key because if they get compromised you know the worst case outcome is total flashing if you're running validators with others and you get compromised the worst case is much life bad so the hope is that we can reduce underwriting costs and over the medium term um yeah I'll hand it over to Colin to talk about the other two cool I'll spend some time talking a bit about how this helps the at-home

validator um recently we've doing a lot of user research around this and peace of mind is probably the the best thing that we've seen here it not only has again its tangible benefits of like security and availability and and ease of use but ultimately it's peace of mind if you're committed to being an at-home validator and you go through the process of doing it yourself and providing your own eat then you have 32 weeks and you're able to do it you ultimately get to this process where your entire life becomes dedicated to making sure your machine stays online going on vacation is difficult uh going on long trips is difficult you need backup power sources in your home so ultimately today like

once you get through all the hurdles of being a validator it's still quite stressful because machines die computers die software fails that's ultimately how all things work so enabling people from at home to spread their validator across multiple locations is a huge advantage manage it enables people to withstand unreliable internet power outages and unforeseen issues a prime example of this is inside of our core team today we have we have a four node cluster running across Ireland Cape Town and India and it's like with machines running out of people's homes and we're able to really see what happens when you have not the best ISP connections or disruptions happen in local internet due to living

in second or third world countries and again it's very important that these people become at home validators as well um you can diversify your entire validator stack this is also the last piece here that's very important for at-home validators this enables them to as ocean explained earlier have have multiple different client choices and they're able to build this anti-fragile setup Community validators is is the last personality type that we'll touch on today this is a new category for us uh this is the category again that we believe uh if we are successful with our mission uh the majority of validators on mainnet will be run as collectives or communities instead of run by individual entities

um the sooner we can kind of get this meme across to everyone that you know validators are RTP communities and not individuals the the more successful we can become personality types here are Dows co-ops Partnerships uh the Dow use case is very interesting um this week at eath Berlin well actually as part of our hackathon we'll try to put together the world's largest distributed validator uh with 20 plus participants uh we'll see how that goes but that's ultimately a a first example of like how communities can get involved uh and share validation rights instead of giving their tokens to a centralized person to stake on their behalf and today we'll close it down um with you know validators are run by

groups not individuals uh this is what we'd like to get across this is what we'd like to instill mentally for everyone and we think it's very important that the ethereum validation Community begins to move in this direction of uh abstracting away from the individual uh and looking at validators is run by communities and with that thank you everyone for the time today and happy to take a few questions [Applause] are there any question oh yeah there we go thank you very much um I hope this

question is fairs what is um the differences between you and for instance SSV or rocketpool um I'll take the rocket pool example um and then you can you take the other one um rocket pool so Our intention is to like not come up the stack uh we have no intention to provide smart contract infrastructure to create synthetic assets our whole main goal and our primary objective is to be an infrastructure coordination layer it's a large enough job that a specific team needs to focus on it and we prefer more of like the legal profile of a project is is solely only building an

infrastructure protocol so you can think of Rocket Pool leveraging Care on as middleware for their users to build more resilient setups so not in like direct competitive to liquid staking pools but here to help them migrate their products into the next Evolution and chapter yeah and then on the ffv front um the main difference there is the SSV client is like a full validator client with custody over your private key and can decide what to sign so we think that you know if that client goes past 33 or 50 it can pose like quite a big risk to the network whereas we've designed oval it doesn't have your private Keys uh the closer it comes if it facilitates you

doing a key generation a distributed key Generation Um but after that it fits the middleware to the existing validator clients and like God forbid both of these were compromised um if you're a validator client you know you have the private key you can find whatever if oval was compromised it can be like sign this please and the validator client to be like that's flashable I'm not going to find that so we think it's you know a much more non-correlated architecture and one that can kind of more safely be used by the majority of people because we are of the opinion that highly available validators are the kind of future and most people will be moving to this so uh designing them to you know not increase correlation with them a big thing of ours and would be dropping an article

that goes into a bit of this more next week hey um so we we're seeing that there's some talk about limiting the number of validators that are active at any given point because there's basically a networking problem that we just cannot have all the computers in the world talking to all the computers in the world at the same time um how do you see Solutions like oboe which I think they're absolutely the way to go um they're adding to these to this network traffic to this problematic traffic very good question and it's actually why we think um distribute like distributed validators and middleware they're the kind of best way to solve this problem

um a distributed validator you know comes to consensus and what to sign outside of the main network if not using you know the gossip Network or anything like it it's um direct TCP connections to one another so you can run your distributed validator and it looks like a normal validator to the network so we kind of talk about it as a second layer or um a second layer of kind of particularly scaling and like mixing people in group um but yeah we've designed it such that you know we're not like in the core protocol and similarly I I kind of agree that you know the same way we had the roll-up Centric scaling roadmap for ethereum I think we'll have a you know a DVT based scaling for the consensus layer it's like okay you know take this

off chain you know the the layer one will stay at probably 32 week and you know it'll stay at like you know a million or so validators and the you know the the next 10x will come at the DVT layer instead of like in the core protocol so what does this mean for people who stay ethereum and also you mentioned the significant scaling of the entire staking infrastructure so how and why that will happen so for people who's taken an ethereum and how the growth will happen yeah it depends on where adoption of the technology takes place first uh this is probably what we're learning the most interesting information about now from users um everybody's Keen to use it everybody

has different ways to use it but really it comes into like where do we first see adoption and in the crypto industry we certainly don't see adoption first with the institutions we always see adoption first with your at-home validators and or your D5 projects so today for us we're primarily focused on adoption where the most risk exists in the network today the most risks exists in the network through the concentration of liquid staking pools so when it comes to like adoption and getting these things standardized for the community we're spending most of our and allocating most of our time today with the liquid staking pools to help them scale and also de-risk the network we think that that will be social cause enough to get

everyone else to get on board and that's how we're looking at adoption and getting it across the whole Unity well we finished right on time that was nice cool okay thank you everyone