Single Slot Finality and the future of staking by Francesco | Devcon SEA

[Music] hi everyone uh I'm Francesco I'm a researcher at EF and I'm here to talk to you about uh making ethereum finalized faster and how this relates to the future of staking to potential staking changes to to come um so first of all let's let's recap what are we actually trying to achieve with single SL finality or generally faster finality um there's actually one goal is faster finality in itself so we we don't want to have a ux and security trade-off you're not supposed to need to uh choose between um waiting for finality or um and and getting higher security or accepting something confirmation faster but at lower security and uh this is also not just for regular users but but for uh rollups uh whose interrupt speed is essentially bottlenecked by the finality time on L1 but this is not the only motivation actually for a faster finality road map uh one reason is also just to improve the consensus protocol that we have and kind of fix some uh essentially security uh problems that that exist in it not really uh you know critical security problems were more um B basically going from uh the the current security proper that we have which are suboptimal to really like Optimal like provable security properties and uh yeah one question that should come to you is why don't we just do it immediately and the main reason why we can't uh in the in the short term is that we just have way too many validators we have 1 million plus valid validators I think it's almost like uh another 100,000 on top of that it's just way too many to just consistently aggregate in each slot uh and it's yeah this essentially is a lot of verification time for the signature and a lot of bandwidth to propagate them um the thing is we don't actually have 1 million validators we have maybe 10,000 nodes it's the exact number is not clear but something on that order magnitude and we we already know that we can handle more than that per slot uh so we already have Committees of around 30,000 validators per slot so that load we know we can deal with um oh sorry um yeah so one thing that that's coming up that's going to help us is Max CB the ability for validators to have up to 248 e uh and to allow for consolidation and but okay so we have Max CB in the in the next Fork what else do we need so first of all we need a a protocol that actually is like Fast finalizing and still has all of the properties that that we want which is are are many and we have like a quite unique uh sort of model that we operate in and then the other thing that we need is is uh validator set capping so we don't want to um let's say go from 1 million validators to 30,000 then we are comfortable that we can handle this load we turn on uh single s finality or faster finality and then we round trip all the way back to 1 million validators because you know more uh small uh stakers come in or deconsolidate or something like that and we're back to square one and the system actually breaks and um yeah the first part of of this just the consensus protocol part we actually have a lot of progress in already there's been a lot of work in the last two years and we essentially have protocols that we're quite happy with in in theory uh the second part it's it's a bit fresher area but I'll essentially talk to you uh about both parts in in the rest of the talk so with the the first part uh I'll focus on a specific protocol which uh We've call three slot finality so yeah single slot finality is a bit of a meme it doesn't necessarily mean single slot it really just means like we want to have faster finality and yeah so what is uh what does roughly this three slot finality protocol look like it's more or less much like the current protocol we really reusing a lot of the same at least like conceptual components so it still has a um what we call a dynamically available component which is essentially like a lmy ghost which is what we have today um and this is the part that's supposed to keep working even if we cannot finalize for essentially extra resilience and then we also have Casper 5G uh this finality Gadget that eventually gives us Economic Security as long as two3 of the de validator set is online and the other another component that's that's quite different from today is that um well first of all we we would be able to finalize fast but specifically we would be able to finalize in three slots with finality being pipelined so that uh you know you don't need you need multiple voting rounds for finality but these would be essentially pipeline over uh multiple slots and so that we can still have blocks coming in in between these rounds uh so yeah this this is what it would look like uh we have a first slot a block comes in just like today we have a first round of votes um at first uh you know votes just like today have three components a source a Target which are Casper 5G Concepts and a head which just says this is the thing that I uh beli to be the head of the chain um at first we would only care about the this head vote which would be for B in the ideal case then we would move on to the next slot new block comes in B Prime uh now the head the head vote would be for B Prime so we've moved on to to this next block the target vote would now be for the checkpoint BT so you know just like today we have this concept of check points that are essentially uh blocks and EPO for for Casper 5G and these are the objects that we essentially do finality over here we would have these like block slot checkpoints uh so a vote for BT as a Target would essentially be trying to say I think that b is ready to be finalized uh or to be to enter the finality pipeline essentially uh then we move on to the next slot uh we get a b double Prime again this gets a head vote uh now the the target is the one from the previous slot so B Prime t+1 and then the source is BT so now this Source vote is essentially saying I know that b Prime uh sorry that b is Justified and is ready to actually be finalized and we're kind of getting to the end of the finality pipeline for B but as you can see the there's three things kind of going on at once uh the the you know B is enters the finality pipeline at the beginning then B Prime enters in the in the middle slot and then b double Prime so all of them are in kind of different stages of the finality Pipeline and you can that's reflected by the kinds of votes that they receive uh and yeah essentially the the this pipeline for B would look like this in already after the first round of voting we could confirm it at this point we have no Economic Security but we already have very strong guarantee that it's not going to be reorg after the second round of voting once we've gotten these Target votes uh b b would be um Justified and after the third round of voting after we gotten all of the source votes it would be finalized and yeah actually we don't even need to think about the blocks you know B Prime and B Double Prime existing in the middle we could also just focus about the votes that are relevant to to be so the head vote the target vote and the source vote if you really just want to focus on uh the essentially the finality pipeline uh for B specifically and even you know if uh B Prime uh b double Prime like these other blocks in the subsequent slots were to be missed for example the proposer does not show up uh the protocol actually guarantees that B can still complete its pipeline essentially that like no matter what if the uh proposer of uh slot T is honest in in uh you know the way it creates B and sends it in a in a timely manner then B will successfully go through this whole Pipeline and be finalized and yeah I didn't you know go into more details of why this is the case but you you can check out the paper or blog post for that and uh now this is the um there's this other part to to this whole discussion which is uh the one that's a bit less uh understood like more kind of earlier research which is validator capping uh so the problem of making sure that uh we we um always maintain a kind of constant load that we know how to handle and we don't you know do this roundt tripping of reducing the validator set through consolidation and then going back up to like a unsustainable uh validator set essentially and in specifically I'll focus on a quite recent idea called orbit that's one way one point inter trate of space of how to handle this problem but I'll try to also introduce the the problem in general um so this is from balic uh lat one of vitalic many uh latest posts on the future of the protocol in particular the the one from the uh about the merge so um you can kind of see essentially this spectrum of possible ways to to handle this problem uh on the right all the way on the right you have this tender style kind of a small validator Set uh you know maybe a few hundreds or in the context of ethereum this could be a few thousands and these are really you know large validators with a lot of stake so there it's quite simple to do you know for example in ethereum we could say that there's 30,000 validators as we already said this is a number that we know we can handle uh and so we could just say okay we only have space for 30,000 validators that's that's the most that we can do if we want to have faster finality uh but this means that each validator would have to have like a very high balance not incredibly high but you know a couple thousand e or one 1,000 e um which is much much higher than the barrier to entry that we have today of 30 to e um so that's kind of one extreme that would significantly change um the the barrier to be a Staker uh then the other extreme is that all the way on the left um which is essentially we just do random sampling of a committee so we say there are no barriers to entry we could even say you can be a um Staker with one e or you know maybe we don't even have a minimum uh but then we sample we do like random sampling essentially of a committee and the issue with this is that um this committee size is fixed so if the total validator set is much much bigger than the committee size then the uh the committee will in inevitably have like a very uh small amount of stake like if only uh you know today we have 1 million validators only 30,000 can participate in each slot uh then about 13th of the only 13th of the stake will uh um exist within each committee so essentially very low economic finality so that's like kind of all the way on the other end of the of the trade-off space somewhere in the middle of the tradeoff space is a solution where we do sampling in a a somewhat different way that's still trying to ensure that we have a fixed size committee but it is trying to take advantage of existing heterogeneity in the the way that the stake distribution is so you know today we we have sure 1 million validators but many validators are actually um clustered in in staking pools even though the protocol does not actually know about that and so there is this uh you know natural concentration of steak that already does exist and it is you know a natural thing to to occur um and we can try to actually take advantage of that um to to find the point that's somewhere in between these two extremes and just to call it out this though there it says tender style in the context of ethereum most more likely what this would look like it's what has been uh called sometimes rainbow staking so where Maybe we essentially split up staking into two different classes of validators uh one which do uh are responsible for essentially finality or or a testing and are more restricted or like have this higher barrier to entry of having a higher um amount of e so that we can um essentially limit the the number of these entities whereas there could be like a lighter class of stakers that are still responsible for things like um making inclusion list or or even block proposing or essentially other parts of the uh of the stick in uh pipeline that don't really have this like technical limitation that a testing does but yeah so that's that's one possible um way to go about it but I'll discuss this kind of middle uh one that that we call orbit so um what is orbit um there's this um orbit essentially is a technique for sampling a committee in a particular way that tries to achieve these two things of having the committee being of a fixed uh predetermined size that we can handle and of having a lot of stake um so let's uh call T the maximum effective balance which is becoming 2048 eth as of the next Fork um once we select this committee we'll take a um so let's look at how how does a Staker with s stake so this could be you know 32e 364 etc etc how does it get into the committee uh it is selected with probability s overt so proportional to stake and uh it has uh it gets reward Ed when it is in the committee so if it is actually in the committee it is participating it's a testing it gets rewarded with some constant reward that does not depend on stake so this is sort of the opposite of what happens uh you know how you normally do this where the selection is random so you don't make the selection proportional to stake but the rewards are proportional to stake um but because you know we still have this proportionality in one of the two terms you still get that the expected rewards per validator are still proportional to stake as they of course should be and so what what does this look like in practice um on the top you see a representation of a validator set with different uh sizes of validators for example validator with the size T could be would be like 248 e and then there's uh you know the same amount of stake split up in different ways like t over2 t over2 or four validators of size T over4 and then you see this kind of projection uh down to the orbit committee this projection is essentially trying to tell you what is the expected outcome when you're sampling from the validator set on top and you're getting an orbit committee um expected here is really like in the probability sense of expectation so the let's start with the with the one on the left the Staker with um T stake 20048 e for example will be selected always with probability one it's always going to be in the committee because as we said the probability was s over T So T over t uh just always in the committee uh we move uh next to the T over2 and T over2 stakers there selected with probability one half so they'll only be in the committee half of the time and so um when you when we think about expectations essentially we expect that one of the two will be in the committee but only one of the two of course it can be that it's both or none but that's just the expected uh case let's say and two over four same thing they're all selectability 1/4 so that we expect one of them to be in the committee and this way of selecting as essentially this interes in property that um no matter how you split the stake so in very to the stake uh to the stake distribution the size of the orbit committee is always the same so you can see you know on the orbit committee line uh it doesn't matter if we split the stake as t or T over2 and T over2 or the other case the expected case is that we always get one validator per T stake essentially and so this is essentially what gives us validator set capping at least in expectation but then this is easy to turn into actual validator set capping in practice because the variance is low basically and we can we can just cap it and and and yeah it's not it's not a big deal then um so yeah more concretely with a bit more you know dramatic effect of uh looking at a much much um more out of proportion kind of way of splitting stake uh we have still this like 2048 e validator this like Max balance validator again it gets projected down to a single uh 2048 e validator itself so it's always selected when we uh take the uh look at the picture on the right it's the amount of stake but split up much more dramatically in uh however many it is I guess 64 validators of uh 32 with 32 each each so this could be you know Soul stakers just complete different entities and again when we project down we only get one validator so what does this mean that just on average each of those will participate only once every 64 slots essentially so that still the expected contribution to the orbit committee is just one and um again to to repeat like what does this get us first of all uh what I've tried to argue uh in the previous slides is it gets us validator set capping basically out of the box so if you say that D is the total deposit size so today this is just the total amount of stake which today would be 35 Millions uh this potentially means that the expected size of the orbit committee is D overt and this would be basically with this parameters around 177,000 so uh before I said today we handle exactly twice as much of that 34,000 each slot so we already know that this is something that we're perfectly able technically to to handle and then it gets us uh if we have enough consolidation like if we have you know um staking pools and so on consolidate enough it gets us uh the possibility of having high economic finality immediately like a single orbit committee might be small it might only be 17,000 validators but it should contain most of the stake essentially like most of the Consolidated stake will always be in it and then another aspect that I did not touch on is that in principle it could mean that it's more plausible to lower the minimum effective balance so this is the 32 e threshold for entering the set which is not being touched in the in the maxb upgrade this could in principle be be actually U easier to reduce with something like orbit just because the mechanism isn't really sensitive to the minimum effective balance if you notice I never actually brought it up in any of the arguments before and uh yeah one important question here is so this sounds like a big change you're s you're changing who's participating the way they're chosen to participate um what does actually you know what changes what does home staking in particular uh look like in this world so let's first start from actually from what stays the same which is uh the frequency of participating in Block construction so proposals and inclusion list proposals once we do have inclusion list which hopefully is soon this is not going to change at all like uh this does not depend at all on the way your sample to ATT test uh because essentially there's no technical limitations on you know there's only one person proposing each slot there's only maybe a few people making inclusion list uh this has nothing to do with um we we don't need to restrict this any further essentially and uh another point that I'm not going to be able to get into is that actually the influence of uh home stay carees or any stares for that matter on lmd ghost uh on the basically the regular fourth choice that comes before finality would completely stay the same but I'm just not going to be able to explain exactly why that is the casee um with the with the time that we have and uh now what changes so one important point is that you attest less often so if you go back to the picture that we had before with the 64 small validators with 32 e they're only chosen once every two EPO essentially like once every 64 slots uh and so you but you know it's less often than Consolidated validators um but it's it's more or less as often as today just half as often as to day with the parameters that I said you instead of once an Epoch you only attest once every two EPO but the rewards are changed in such a way that you're not earning less than than other Consolidated validators and another point that it's maybe more important is uh home sakers would generally have less influence over finality um because again if you think about that picture from before you have the 64 small validator validators they're kind of compressed to one so only one of them will actually end up in the set um um so even if uh home stakers have you know maybe 10% of the stake the amount of stake that they will have in the orbit committee might be compressed one point there is so this is probably I would say the most contentious uh part of of this proposal um but yeah one one point there is that it's already kind of the case there's already very little uh influence that they have or finality because there's only maybe 5 to 10% of stake that actually belongs to to home stakers and uh yeah I mean this was just bringing uh yeah just showing you why this compression happens again um and one last point is we would probably want to ensure that we do have enough consolidation since this is an important part of how we get better guarantees from this mechanism um how do we do so is probably to have consolidation incentives that uh essentially go down to zero once we reach a certain amount of consolidation that we're okay with so maybe you know 75% or some other amount that that we're happy with and uh yeah when we're outside of this uh regime you have basically this incentive if you're a saking pool or so on to consolidate and yeah what's left essentially for the consensus protocol part we have to spec it and prototype it for the rest a lot of it is really like having these hard discussions in the community around the future of staking and you know what of these trade-offs uh we're happy with um decide what the what what failure case we're happy with and then yeah we could introduce orbit sampling in the current protocol uh and then we could eventually uh move actually to to 3sf or you know to some faster finality protocol thank you okay okay I'm going to shuffle you along towards the center so everyone can look at your beautiful face um thank you guys again give another round for Franchesco perfect so let's dive into the question starting from the top Avalanche already has single block finality with subsec block times where every validator votes on every block does this proposed system have any Competitive Edge against Avalanche consensus yeah so to my knowledge and I mean it might be outdated but I don't think so um avalanch does not have any accountable safety so there's no way to actually say if there is a consensus failure for example let's say double finality there's no way to say which valers exactly were responsible for it because the way they reach consensus through this like subsampling mechanism that doesn't really uh get everyone to to express an opinion on a block okay cool next does 3sf work with lower slot times so 3sf is kind of built in a way that doesn't really change the the way the slot Works uh too much so it's it would be a slot that it looks quite similar to today there's some like minor things that that I didn't talk about that kind of deviate from this but generally speaking most of what we could do with today's slot we would also be able to do with 3sf I would say cool it seems three slot finality provides both constant time finality and liveness what hypo hypothesis do you make to guarantee both um so I'm not entirely sure um what exactly the yeah I'm not entirely sure but let's say like um the if by liveness you mean availability more specifically then this is something that relates to this lmd Ghost part of the protocol um and yeah it's it's possible to have both of them finality and availability because we have these two different uh kind of chains in a way we have like the available chain and then finality on top otherwise there would be an impossibility result maybe you mean something else in which case maybe we can chat about it later cool does Orbit changes um how aggregators are sampled from the beacon ATT tester sets um no most likely wouldn't I would say yeah we could just one way to do this is that we could just reuse all of the aggregation infrastructure that we have now including the way the specific way the aggregators are selected the majority of homes take reward actually from the attestation does this change would I'm not speaking English correctly does this change would this change would make home Saker suffer by a lot and just withdrawn being a home steaker and go to liquid staking or something s oh okay no it's not me it's question uh so no like the answer is like um the rewards would actually be um the expected rewards but when we talk about attestations expected rewards and rewards are kind of the same because your test so frequently like even with orbit you still be testing once every two Appo um yeah you you would not suffer because of that because the expected rewards are still proportional to stake so whether you stake 32 e whether you stake 64 e in one validator or you have two validators of 32 eth your expected rewards are the same you might have a little bit more variance but it's attestations that we're talking about you attest so often then the variance is essentially irrelevant cool okay uh would this change the staking AP PR uh as not all validators are testing anymore only the selected set um same kind of answer as before like it wouldn't like when you're not in the set you don't get paid but when you're in the set you get paid a constant amount so whether you are a 2,000 validator or a 32 E validator when you're in the set you get paid the same so you can think about it as like once you're in you get paid way more than you should like based on your stake like you're not paid proportionally to stake so overall the two things balance each other okay well I just got the sign so I think that's all the time we have today thank you so much Franchesco thanks everyone um we have another five minute break until it's actually 410 this time from Pure Das to full dasas