SSV: distributed and trustless staking infrastructure

Transcript

my name is alan i'm the ceo of a company called blocks and we develop ssv which stands for secret shared validator i wanted to share with you because i truly think it's one of the more interesting things i've got a chance to work on i kind of wanted to spread the word and see if it's relevant for any of you so secret shared validator um let's see if the clicker works okay perfect so secretary validator stands for uh ssv stands for secret shared validator um it's a technology we've been working on the past i would say more than 12 months and it has the the goal or at least the objective to really redefine

ethereum staking infrastructure and you'll see in a second why it will enable anyone who's running an ethereum validator to do so in a decentralized way and it seems counterintuitive because ethereum is decentralized but the infrastructure itself is pretty centralized or at least tends to be very very centralized and it's aimed for really anyone who's running a 32 eighth validator so stakers diy stakers uh staking pools uh institutional stakers and so on and so forth and it uses two um pretty well tested components which are threshold signatures and a bft uh protocol a consensus protocol so why it's really important there's a lot of things happening in ethereum too

why is this particular thing important and what are the ramifications if we don't do something about it so ethereum staking in particular was really conceit with uh with the scope of having one validator equal one vote and specifically that's coupled with the fact that the protocol itself tried to really hard to reduce economies of scale which are um really the the kind of the description of of the legacy proof of work consensus protocols where the more power you have the better performance you have in the network when if you're staking at least the the scope was to really reduce that as much as possible to avoid centralization and of course

incentive incentivized decentralization and that's really important because if the click works that's really important because if we kind of going forward and looking at the future landscape currently we have about six four point four million if at stake which is pretty significant but as we fast approaching the merge we'll see higher rewards and of course that will push more and more deposits into the into the staking protocol and of course it raises up a lot of innovation in terms of the staking services we'll see more and more staking services will come online and offer different quote-unquote flavors of staking and of course there's other concepts or other challenges which are

just starting to emerge like mev which has very particular challenges in in proof-of-stake ecosystems and all of that really creates a lot of challenges one of which which i think is really really important is in terms of the infrastructure the infrastructure that stakers using staking services are using and so on most of the infrastructure today is really defined or really influenced by the slashing conditions we can find on ethereum those conditions in which if you violate them you get pretty severely penalized and gets you get ejected from the protocol itself uh and of course when withdrawals are

not enabled those two things combined are pretty pretty important um and so the infrastructure today is very much influenced by those conditions which in a lot of cases creates uh centralization but also it creates single points of failure um and that's pretty that's pretty significant especially if we're talking about a protocol which try to be as decentralized as possible and so how it looks like on current infrastructure current infrastructure has in its heart a validator client which is basically just a piece of code which coordinates the execution of duties for for the validators it can hold many validator keys and of course that

validator client is connected to a beacon node which is the gateway to the to the actual beacon chain the validator client uh is very important because all of the responsibilities for actually getting rewards working correctly is up to that piece of software and because of slashing conditions that piece of software has to be run in a single instance no more than a single instance and that causes a lot of issues a lot of challenges it actually goes against a lot of what we've learned in software development the past 30 years where you know we try to create robustness we try to decentralize our different system components but with this because

of slashing conditions we can't really do that or else we're risking getting slashed there are ways to maybe improve it slightly but overall it's pretty it's pretty fixed and it creates a lot of do's and don'ts in terms of infrastructure development so of course don't run a validator in more than one instance or most probably you'll get slashed most of the slashing we saw in the past six to eight months were actually accidental slashing there weren't even malicious slashing uh there were simply errors somebody did mostly running two validators uh this two validator keys simultaneously or forgetting about their slashing data and so on and so

those are things are very very dangerous um the validator key must persist and back up all of the slashing data which is basically the only thing that protects you from getting slashed and of course the keys need to be online 24 7 all the time those are kind of of course it's a short list of do's and don'ts but in my opinion it really goes against everything we've learned in software development the past 30 years especially trying to build something more robust there's particular cases of slashing recent slashing which which were caused by somebody trying to build a more quote-unquote robust system by having maybe a redundancy validator client running in

the background or maybe dormant in the background but accidentally got online and so on and so forth and so that's really really tricky uh and if that's coupled with you know what we're seeing in the future of staking more staking more services and so on um in my opinion there's a lot we need to do and think about for this ecosystem to actually be secure and actually be decentralized at its core and so what is ssv how it looks like compared to this right so this is ssv on the left side hand side we still have those validator clients validated keys but now they're actually getting generated into shares secure shares and those

shares are assigned to independent trustless operators those operators can be completely different entities completely different geolocations controlled by completely different people and uh the way they work is they coordinate between themselves with a consensus layer and they use threshold signatures to to achieve a valid signature and broadcast to the bitcoin node and of course get rewards in instead and the cool thing is actually they're fault tolerant um fault tolerant means that if one of those operators gets um for example gets offline gets hacked and so on the rest can continue their work

continue operating the validator in a secure way and so again this is a short list of the benefits of ssv and it's pretty pretty significant first of all the value the actual validator key doesn't have to be online anymore it can be in cold storage that's a big big uh improvement the shares themselves need to be online but they are distributed between again independent operators trust us operators and so on and so forth in order to actually make a malicious attack you'll have to compromise not one but at least the majority of them which is pretty significant threshold signatures are used for security of course there's no more single point to failure if you go back to the scheme there's no single point where if you

attack it you cause the system to get slashed or even go offline which is pretty significant um we use fault because they're coordinated between themselves using a consensus layer it's fault tolerant which is a very robust way of saying the infrastructure can maintain itself even if it's under attack and of course because ssb is built as a network it's actually ready to go infrastructure so for future services trying to build staking flavors quote-unquote they can simply use ssv they don't need to rebuild and re-invent the wheel and they can use a good infrastructure robust infrastructure to do so and of course current services can fairly quickly integrate and even switch over to ssv because it really focuses on

the validator level on the lowest infrastructural level and so the rest of the staking service can maintain its own operations and only the infrastructure really changes and that's pretty pretty cool and um and so that's ssv the tech but how it actually works in real life it's is even cooler so if you are a staker and you have 32 eth and you want to use ssv instead of running something on your own or maybe use some third party you can do so by simply going to a web app selecting your favorite operators and it can be a bunch of them we actually in order to be fault tolerant you can select three f plus one operators so if f

equals one you select four operators if f equals two you can select seven and so on and so forth the bigger the number of operators of course the more robust it is and you simply distribute the secure shares which can be generated offline in any computer you want and from that moment on the operators coordinate between themselves and actually start a testing start executing duties for that particular validator you don't have to run anything on your own but you still have the confidence that they are decentralized the keys the actual validator keys are offline and uh because we're using fault tolerance because we're distributing the infrastructure performance is expected to actually be

better and so in private testing we did we actually got to a point where uh we ran in 100 of the station rate 100 effectiveness um and of course that's still in testing but in general the the objective is to actually have a better performance because of the redundancy built into the into the ssv protocol which is pretty awesome this whole thing is tied up with with a dow um oh sorry before that so that was the the actual staker the one who's holding the 32 validator the operators on the one on the other hand are the ones running in ssv node which is actually pretty lightweight it's maybe a bit more resource intensive

than a validator client they get themselves expo exposure to a much larger audience of stakers because whenever they get online and register as an operator anyone can choose them and so the bigger ssv network becomes the more people there are to choose that particular operator and of course every single validator has multiple operators which work for it and so that's pretty cool and i think the most important thing is the operational cost and risk for each of the operators the biggest factor by far for any operator by far more than development time and resources more than cloud

cost and so on is the reputation and as a derivative if they get slashed what happens that's the biggest the most intensive operational cost they have and we saw that unfortunately in the past few months if they work in an ssv environment they get they work as a community as a committee and of course the operational risk grids reduce significantly because if they make by mistake some issue for example they're running two instances of the same ssv and so on and so forth then nothing really happens because they work as a committee they need to threshold signature they need to coordinate between themselves via consensus protocol and so the level of guarantee they have is much higher

and of course that results in lower cost and i'll even go as far as to say that stuff like downtime for maintenance is actually possible so imagine if you have 10 operators on a validator one of those operators can say tomorrow at 3 p.m i'm going down for 30 minutes to for maintenance and nothing happens the world continues the validator continues to get rewards and so on and our approach is really a free market approach or each one of those operators can set their own fees and so the best operators with the higher up times and so on can charge more um and so i think from a operator's point of view that's a pretty sweet deal specifically on the

operational risk and this whole thing is tied out tied down with with a dell that was really responsible on a few things one is actually maintaining a curated list of operators so the idea here is to have the best operators the verified operators gets bunched about based into a list and that list is used by users to actually select which operators they want to work with and so you can imagine the best operators getting on that list getting through a thorough framework of reference and and review and that's actually worked pretty well in in protocols like av and so on uh lido and so you'll get the best the best operators and you can choose

from them the protocol of course is controlling the protocol and network governance and the last thing which is probably one of the most challenging things is how do you continue momentum in terms of development and uh and guarantee the advancements of the protocol and so the dao is also responsible for grants and so on um and one of the things i'm most proud of is all of those things sounds amazing but is it actually here to work and operate it so i'm very happy to say that the first public testament for ssv which is actually the second test for ssv is actually

really really close so in a few weeks we'll have everything i've just described fully operational working for both operators and validators you can go on a web app and select operators and see your validator just run operators can on the one hand get selected but also run validators and it will all be functional the printer chain and that's pretty a pretty major milestone [Music] and so hopefully you guys will get a chance to check it out and thank you i think we have a few minutes for questions if we have any [Applause]

yeah wait wait wait wait we'll be here yeah hey you mentioned in the beginning of the presentation that the current setup is where multiple validating keys run on one client um does that mean that they're running on one instance like there's like 10 people who have their own key and they use like one instance of a process that's running yeah so depending on your setup if you're a private person you'll have a valid for at least a validator client running and then the number of validators you have run on top of it if you're a very big service you might batch them up but still you have you have a unique validator uh key set attached to a single validator client you cannot run them in parallel for example and so the

single point of failure is always that validator client because it has to have a very defined unique set of validator keys um okay and then uh could you could you guys go into detail like why um it's like kind of this like batching like why don't why don't individual keys just run their own validating nodes as well why are why we have to run one valid a unique validator key on a validator why don't people just like why why is it batched oh the batching is just because the validator clients have some capacity so you know they can't run a hundred thousand validators so let's say your validator client runs a thousand and you have two thousand validators then you'll simply run two of them

um that's mostly the case okay yeah thanks i think we had a question though how does proposing work like how do they coordinate for proposing a block when needed so there's the the short answer the long answer so the short answer is it's pretty simple you simply have one of the committees suggesting what the next block is each one of the committee members uh the operators in the committee uh validated locally so it's not slashable it's a valid block and so on and so forth and uh they if they all agree they simply sign it so that's the the short answer the longer answer is with mev in place it actually becomes much much

more complicated well it's not much much more complicated only depends if you want to really reduce the ability for a single operator to you know have a back channel for payments on the mev or for for extracting md um that's still in research it's actually not as this specific issue it's a staking issue i think that one of the most let's say interesting approaches is actually separating block builders and proposers in such a way that the committee the operators will choose uh some block content but that block content can be produced on by somebody else and they simply have the the objective of maximizing the amount of fees they get from that

block proposed from the content proposer um and so so that's that's one approach there are a few others uh it's still actually under research mav in general for staking is a bit tricky yeah yeah oh okay sorry is time a problem here so when multiple nodes need to agree about their response first this takes longer than when a single validator can immediately craft his response yeah so um the protocol currently for staking is at least for the stations for example is to wait until the third of the slot time which is four seconds and then

the aggregator takes whatever it gets uh up until the two thirds of the slot which is eight seconds and then broadcast into the network uh that's pretty uh that's well over what the ssv protocol needs so i'll give you an example um cosmos for example is a bft protocol it has around 100 operators or validators in it and they get to a consensus within two seconds and here we're talking about much lower numbers because you don't really need a hundred uh so i don't see that as a problem we ran a test net of course it's a small scale test net but we didn't have a problem with that um yeah i mean four seconds is a long time thanks anybody for our last question here oh it's the same question

thank you everyone you