Single Slot Finality, Layer 1 R&D - Day 2

[Music] okay perfect uh so today i will be talking about a single swat finale so this is a longer term proposal for where ethereum proof of stake could go so longer term than virgo tree is a longer term than uh dank sharding longer term than any of the stuff that's uh under um active development um and the core idea here is a single slot finality right so basically make it so that instead of blocks finalizing after like two epochs after some period of time that is currently around 13 minutes finalize blocks after one single slot um and we'll talk about like why this might this might be better um why this might be simpler why this might lead to a protocol that has less bugs in it and why it could actually be yeah like computationally viable when i think i historically we haven't really thought of it as being uh computationally viable um so to start off just a bit of background about like where we are today and why we are where we are today so in uh 2017 i published this article uh parameterizing casper the decentralization finality time overhead trade-off where i basically talked about these three different axes that are good properties for a consensus algorithm in a blockchain to have so one of them is a load time to finality the other is a large validator set um and the third is a low node overhead so load time to finality um lots of uh reasons uh why it's good it's a good ux uh but also on top of that like we've recently been worrying more about like mev related reorg attacks all kinds of other attacks um and having a chain that just finalizes instantly basically makes an entire class of issues go away um large validator set needed to make it possible for any regular people to be able to stake uh so it's a kind of decentralization and a low note over overhead also another kind of decentralization and the argument was that well there's actually a pretty simple mathematical reason why you can't have all three at the same time and the argument is basically that like well finalizing actually requires every validator to be uh to send a message once right like all of these bft algorithms they require two rounds of messaging and in each of these rounds every single validator needs to send one message right um so you know if you're familiar with how tendermint works or how like traditional bft algorithms work um you know round one um everyone someone proposes everyone makes a pre-commit round two everyone makes a commit um and and then if you look at how casper works it's basically the same thing except spread out over 64 slots um and if you look at algorithms that don't have this kind of high overhead of a lot of messages they yeah they generally don't finalize right so if you look at chain-based proof-of-stake so like you know purecoin next testosterone like that whole family they just basically don't have the same concept of economic finality they just have either one or a few messages per swat um and so they can have a large validator set they can have over at low time to overhead but time to finality basically shoots up toward infinity um and like they don't even bother to code economic finality of any kind um the most bft again like bft based non-ethereum chains that exist today they tend to sacrifice on this so no overhead tends to be either low or medium i mean realistically a lot of these chains don't even care about decentralization at all um so like you know if you're processing like 400 tps and you know your node is a data center already like you know who cares if you're also processing an extra 10 000 ecdsa signatures every second uh but uh they can end up like basically sacrificing on more than a small very small number of people being able to validate right so older chain sacrifice on this current kind of high capacity chains uh sacrifice on this and then some i don't think there is many chains that like really that um only sacrifice on this because like if you can support me what's the point of supporting a million people being able to be validators if being a validator requires a data center that you you can't find a million people who can afford um but this is kind of the trade-off space where we have today right but well and ethereum like i made this interesting choice where basically instead of being extreme we kind of tried to be somewhere in the middle and like be not too bad on any of the dimensions right so like we have finality but it's not instant finality we know we have a large validator set but like you know you still need 32 eth which is a pretty expensive these days and we have you know fairly low overhead but you know it would be nice if it was a lower and i mean no validating could fit on a phone but we're not really quite there um so we're kind of in the middle on all three right since 2017 we've i think discovered a few things uh so one of them you know big credit to justin here for like really pushing this one forward uh basically with bls signatures uh you can have like aggregate signature verification so you can compress a huge number of signatures together um into an object that is 32 bytes constant size plus one bit per participant right you just have a bit field of like who participated and so even if you have a million validators well the bid field is just 128 kilobytes right which is like basically you know a bit more than the size that ethereum blocks are today um and verifying bls signature um aggregated signatures per validator is much much uh faster than verifying say a bunch of vcdsa signatures or a bunch of store signatures or a bunch of whatever regular signatures together right yes to verify a bls aggregate you basically have your signature then you figure out which public keys participated you add up those public keys and you verify once and so per public key that participated instead of needing to do elliptic curve multiplications you just need one elliptic curve addition right so that's uh i believe half a micro second so very fast huge savings on computation about as long as much savings on data so bls aggregation actually allows us to decrease node overhead by quite a bit without actually sacrificing on the other dimensions right like uh so instead of just like picking a different spot on the frontier we can actually kind of like advance the entire frontier right this is uh you know what what better technology does so that's one discovery another discovery that i think we've had since 2017 is like a more kind of philosophical discovery which is that medium finality time i think is like less valuable than we think and specifically having like very low like like minimum possible finality time uh turned out to be more valuable than we think right so there's a couple of different reasons for this look one of them is that today ethereum does not provide finality and exchanges are actually still okay recognizing deposits after like a few minutes right um so exchanges today lots of them recognize deposits after five to ten minutes okay fine we have finality after 13 to 15 minutes but like the non-finality security that we have is probably already good enough right and so lots of exchanges are probably just gonna like accept that after like maybe one to five minutes and lots of lots of services are just not even going to bother with waiting for a finality like okay we have this thing transactions can't be reverted but like it's still it takes just a little bit longer than lots of people are comfortable waiting and so like how many people is it actually going to benefit another argument for why single swot finality is like a really significant leap over medium time finality is the issues around any v and reorgs right basically the issue is that if a reorg is possible um then there might be situations where like um let's say there's like a big liquid a big liquidation event like you know justin's son does something stupid on the blockchain prices go down a bit uh and um you know there's like one opportunity to kind of snipe at him and grab half a billion dollars right this almost happened if anyone remembers the history this was you know i think a good old uh coronavirus black cats used day back in 2020 uh but uh basically the problem is like okay you know justin sun gets sniped someone lucky wins you know 100 million dollars or whatever but then you've created a really huge incentive for people to reorg the chain right and basically try to like re-snipe and grand grab that opportunity for themselves and the problem is that like there isn't a huge in disincentive against doing this there's like informal disincentives like oh if you do this then people might trust aetherium lesson if you're a validator you hold ethan blah blah blah um but like there isn't this kind of iron-clad incentive that we have for like say yeah you know swashing against econom if you break finality and the thing that single swat finality gives you is it gives you this property that even after a single slot like basically as soon as block n is confirmed like even before the contents of blockchain plus one um i actually even need to get committed to basically you're already finalized um and so there's no way to actually like for the validator set to then decide to take the uh to take that back in reorg right which is uh really nice um so now i mean it's not perfect because well technically if the validator set wants to really be me and you know liquid just decides to you know not fun take half their nodes off line and like make a non-finalizing chain for a bit but like the cost of it to them of doing that still becomes quite a bit higher all right so me basically low finality time has these like extra really nice benefits and so there just really are nice gains in uh going all the way another discovery since 2017 is that well this kind of awkward middle ground that we've invented like it's awkward and there's lots of places in there that could have bugs right so there's this um bug from ryoga nakamura back from 2019 the decoy flip-flop that really took advantage of kind of misalignment between lmd ghost and ffg there's also been some recent bugs that we've resolved over the last few months that have to do with the lmd ghost mechanism by itself um so you know lots of kind of potential skeletons in the closet of this stuff and if we like basically just move away from this sort of thing entirely then like that entire class of bugs just disappears right so the question is can we make ethereum finalized in one swot now we can do the math right so let's suppose that we have one million validators so suppose we have 32 million stake teeth now every node has to vote twice per finality round let's say we increase the slot time to 16 seconds you know finally half powers of two everywhere um then every node has to vote twice per finality around so every node has to vote once per eight seconds um so that's uh 125 000 signatures per second with a bls aggregation just if you just want a node that can that's verifying the chain um the the marginal cost of verifying one signature so if in an aggregate is a one elliptic curve addition half a micro second and so validating a block that contains a size 125 aggregate is going to be half a microsecond times 125k which is 62 milliseconds which is like well within the bounds of tolerance right so if you just kind of look at the naive math it seems like you know we can do this um now if we want to uh like push the overhead down even further there's this interesting trade-off opportunity which is this idea of super committees right so um i did this uh informal poll of like basically like how much actual kind of minimum cost of attacking ethereum like how much money being slashed from ethereum being attacked do we really need to be comfortable with and like you know the kind of median of people's wishes seems to be somewhere between one and two million eth so what if we say okay fine like that's like we don't try to provide you know 10 million each of anti-swashing security because that's overhead because that's overkill and let's say you know even if the validator set is really big keeps washing security to like one to two million eth a committee of size four million is uh or so 125k validators is would achieve a cost of attack of 1.3 million if right and so you do is you basically say no matter how big the validator set eth how big the validator set is take a super committee of size 125k choose it randomly adjust it by a few percent every time there's finality um and you only use that to finalize right and if we do that then you know we can cut the overhead down even more this is this is if we want right so if we want to have um verification be uh faster than 62 microseconds or if we're okay with these numbers and we want to decrease the deposit size from 32 to 4 then like this is also an option now so far i only talked about verifying a block while that block already has all of the aggregates inside of it right the main bottleneck so far from what we know so far is not actually verifying these bls signatures once they're already safely inside of a block it's aggregation right so verifying huge bls aggregates is that easy actually doing the aggregating is uh is hard right and so far we have like less good ways of doing that so if today we actually had uh you know a million validators and we yeah made a hard fork reduce the epoch length from 32 to one then the place where things would break first and like you know break the most terribly is the aggregation layer um so can we improve the aggregation layer right um so there's a couple of possible strategies for this um one of them is that we can take the existing approach to aggregation that we have today and we can kind of improve it incrementally right we could have more subnets so we could have you know hundreds of different subnets and aggregation for small pieces happen on the subnets and then on the main subnet you just like do a little bit more work you could have multi-layer aggregation so instead of two steps we go up to having three steps um and um we could also use like basically borrow from the kind of pbs idea and we can use use specialized aggregators so we can say well okay fine we're going to rely on this idea that there are some uh special nodes that have a global view and only a few people run them but really there's like a one of end trust model like basically whoever provides the best aggregate wins um and as long as there is one honest node providing super aggregates we just rely on that and uh you know could even have it in protocol reward for this um or potentially we could even like just not bother with rewards right so there's a there's like this big design space for ways to improve aggregation but like there is no theoretical reason why um aggregation of even size one one million aggregates needs to be that hard right like there's like there's definitely a kind of structures you know tree structures whatever other structures that can do it in principle we just have to like solve the hard engineering problem um so that's kind of the technical side of like how to make it scalable the next prop question is uh well what would single swot finality look like from a theoretical standpoint right so today we have um a casper ffg and we have lmd ghost and we roughly know the way that those two interact with each other the really nice property of single swot finality is that in the normal case so in the case where latency is good you actually have more than two-thirds online um then basically the fork choice rule does not even need to run right the fortress rule only runs during exceptions when you have more than one third off on um offline or when network latency is crazy um so in the normal case you could basically only the bft algorithm would run and so in the normal case you can just remove an entire class of attacks that we have to worry about today right um so for the fork choice you know you could use any fork choice you could use lmd ghost um you could use like some other like committee longest chain thing you can use something fancy we don't really have to care about what it is um and the bft algorithm that we choose could be more conventional right so if we want we could you know quote just use tendermint now not tendermint the software because like would you want all this bls aggregation stuff um but you know we can use this like if in principle we could use the exact same algorithm um so this probably the one challenge of figuring this out is the bft fork choice interaction layer which is i think a bit simpler here than it is in today because today you know we the they kind of interact on a very deep level with each other but here the interaction is simpler and most of the time only one of them is like actually contributing and the other is kind of on the sidelines but the basic idea here is that the fork choice makes suggestions about what the bft layers should finalize right so the way the bft layer works is usually someone proposes two-thirds pre-commit and then two-thirds commit right but then you basically if you have a fork-choice mechanism then you have this fork choice and someone proposes according to the fork choice and then the pre-committer only pre-commit if they if that matches their fork choice and then they also commit only if that matches their fortunes so the basic kind of idea behind how the interaction would work there is like fairly easy options now there are some subtleties right so one of the subtleties is the inactivity leak so the way that this sort of thing actually like manages to survive the case where you have more than one third offline is that you have this weak mechanism and so the balances of the validators adjust until eventually like whatever happens at the beginning at the end two-thirds actually are online right you just leak the offline ones until the percent online goes up to two-thirds but the problem is that uh that that introduces a bit of subtlety because we don't just have to finalize a block but we also have to finalize how long it took to finalize the block because we want to finalize what these balance changes are um and we also want to finalize the growing non-finalized chain right um so the way that these bft algorithms work generally is like sometimes they kind of lock on to a particular value and then they take much longer to finalize it but then like we don't just want to finalize the thing that we walked on to because the thing that we walked onto could be a thing from like a week ago we also wants to finalize like well everything that happened since then um and that might have to happen during the next round of finality that like this is uh one of and then one of the things that we just have to kind of think through right so there are easy options like like the easy options are just you know take the status quo and uh replace the epoch length with one but uh i think uh given that you know this is a five year project and this in my opinion like you know we should only do crazy things like this once the high priority crazy things that we need for um you know scalability and proof of stake and like and all of that stuff are um done and people kind of want you know breathe a little easier like we do have time during which we can kind of research this properly and figure out like really what the best uh what the best approach is um so the other goodies um so these are like things that are in my opinion nice to have for like an ideal proof-of-stake algorithm one is like like one thing i want to like ideally have is like better theory for kind of like better formalized theory for responding to 51 censorship attacks right so responding to 51 reversion attacks is easy like people get squashed and you're fine responding to censorship attacks like what's the best we can do the best we can do is probably that like validators make sure that validators who are censored automatically coordinate on a chain that ignores everyone who's censoring them right so like in principle this is the sort of the this something like this should be possible to do right it should be possible to create a system where if a validator notices that they're being censored um by a particular chain then they basically just stop even trying to build on that particular chain and they start trying to kind of build on um whatever the chain whatever the best chain is that actually is being uh being honest toward them and so try to like automatically create a situation where if there is a censorship attack then there's like a queer bad guy chain and then there's also a a queer good guy chain as much as possible as well so like figure out to what extent that is possible try to like figure out like what that actually looks like um is a one problem and ideally you know users should be able to like get alerts and see this sort of thing as well right like ideally response to censorship attacks should be kind of as close to just like users uh seeing you know a warning and having to decide like whether or not to press to press a button as possible um then other things so better treatment of entry and exit queues can we have entry and executes that happen faster partial deposits partial withdrawals lots of people want this variable balances like one of the nice things about um dank sharding actually is that i think is being kind of a bit understated is that with dank sharding we basically almost don't need committees anymore right because originally the committees were there because we had 64 shards with the ink sharding we don't really have a concept of shards in this uh to the same extent um like we have sharding but you know it's kind of like more fluid and like everyone verifies a little bit of everything um and the only reason we have uh committees for today is beca or post uh ding sharding is because we have to split the validator set into 32 pieces and assign like um 130 tooth of the validator swat uh to each uh evaluator set to each slot right but if we go to single swat we don't even need that um so we can basically get rid of like committee shuffling and you know get rid of the whole swap or not stuff and if we do that then we could even have variable balances um much more easily and so better variable balances would be nice um also try to reduce incentives to join large pools as much as possible like these things could make it more viable to be a solo staker and they could like could also make it more viable to have staking pools that are small instead of snaking bowls that are large right like one thing that would be nice is um you know if you have a staking pool you could make it possible for even a small pool to allow people to withdraw um at any time if like you actually have partial deposits and withdrawals and so the staking pool can also withdraw um so there are like and potentially there's other things that we can do right there's a list of things that we could do um and aside from this also keep it simple like i do seriously think that this could be a significant simplification from the way proof of stake works today right because uh you know no more like end of epoch stuff no more like intra epoch um you know saving a list of like saving these bit fields that we have had to bother with an altair um you know no more um like really you know complicated interactions between lmd ghost and like all the um all of these things and no more a swap or not shuffling there's just a lot of things that just go away um if we um if we do something like this and it would be uh so it would be nice to also like use this kind of opportunity to kind of a long term simplify the ethereum consensus lawyer as well um so that's what i have thank you [Applause] [Music]