Single-Slot Finality

Transcript

um so um today here um what i i'm going to talk about is um would they say proposed the long-term uh roadmap for long-term change for the beacon chain that it changes how finality works in the beacon chain that changes um how the beacon chain comes to consensus so it's still proof of stake um but the proof of stake ends up being designed somewhat differently in such a way that it finalizes uh transactions much more quickly it finalizes uh transactions after a single slot um and instead of using the entire validator

set of to finalize it uses committees and i'll talk about like what problems i i'm trying to solve with this kind of approach and basically what are the advantages of doing this what are some of the disadvantages and just why i think this is a path that is so worth exploring um not like this is not something that i think the ethereum ecosystem is like needs to start putting a huge amount of like effort into thinking about immediately um so this is something that's still lower priority than the merge so less important than the merge less important than sharding less import

less important than statelessness but still in the longer term um something that made that maybe worth uh going towards um so basically the uh the way that the etherium beacon chain works today right is that we have this concept of a hybrid fork choice finality mechanism so the consensus algorithm the algorithm that the chain uses to figure out which block um actually represents the head which block uh kind of existing nodes and validators should follow it's uh it's hybrid for choice and finality right so it has this concept of finality so

in the same way that like bft algorithms like center mids have finality but then it also has a fortress role right and uh the fortress rule is lmd ghost the finality mechanism is uh casper ffg i mean so lmd ghost and the casper ffg together uh they uh they're usually called gasper right um so the way that this works is basically that once a validator proposes a block there's a lot of attestations these um many different messages that are being made in parallel and so after one slot the blog has some hundreds of confirmations but then that block is only finalized after um two e-books so after about 64

slots um technically it could go up to like maybe 80 80 or 95 squats but it takes uh it takes some time it takes more than 10 minutes for a block to get finalized um and the thing that i'm proposing here is a kind of an alternative design that may be worth uh switching to in the long term uh where basically instead of having this separate fork choice and finality where a block is protected by the fork choice after one slot and then it's protected by finality after like um say 60 or 80 squads we just have some degree of finality that a block is protected by that becomes active almost immediately

so first of all what are the problems that we are trying to solve right um so recently there has been this uh discussion and uh debate about uh mev um attacks and specifically reorgan attacks right so there is mev as stands for minor extractable value um and it just it's in proof of stake i guess it becomes proposer extractable value but it's the same concept um basically the ability of uh miners validators participants in the consensus to use custom strategies to like basically modify their clients in uh to process transactions differently to act uh

differently within the consensus in order to just increase their revenue uh and the concern basically is that like sometimes this behavior is totally okay right sometimes this behavior is even quite helpful for the network and even quite helpful for the chain's efficiency for users ability to make more complex and more efficient applications but um there are other forms of mev that are clearly just really abusive and harmful right and re-origami attacks are very much um abusive and harmful so a reorg mev attack is basically an attack where the miner or the proposer actually create instead of creating a block that

builds on top of the previous block they build a block that competes with the previous block and so i make a block on top of some other block and then you make a block on top of the same block that i'm building on top of and so now my block and your block are sister blocks and your block is competing with my block and the reason why you would want to do this is so that you can basically get fees and get mev you get revenue not just from the transactions that you can include in your blog but also from the transactions that you can include in my um or that i already included from my blog right so you can take my transactions and take your transactions and take all the transactions uh and

reorder them um potentially yeah just uh like you would even be able to break existing flashbots bundles potentially there's just a lot of very mean things that you can do if you can reorg now reworking in proof of work and or in nakamoto consensus is not very difficult reworking in proof of skin gas per proof of steak is uh significantly harder um but reworking in tendermint which is a single sword finality system is um it's not possible to do unless you're willing to have um like most of your validators be slashed uh so basically they're like i am

there was a post that i wrote with georgios constantinopolis where we have like you can see what these game charts actually mean in detail but the core idea right is that in proof of work it's easy to do a reorg in proof-of-stake the proof-of-stake that ethereum is implementing it's much harder to do that um basically the difference is that in gaspar you need a lot of validators to switch to doing an attack at the same time for the attack to succeed um but in a tender mint-like design like you actually have even more security because it's not even possible um to reorg even one single block uh without getting slashed right so once even one single

block is published and confirmed that one single block is finalized and so there's just is no possibility there is no way to do a to revert um so this uh property is extremely powerful um and basically the challenge here is well you know what if we can basically take the ethereum beacon chain and try to get some of these benefits by making its more tender bit like right so we'd not copy the exact center mid code definitely so like for example um tender mints i i think currently does not have bls aggregation this would definitely have bls aggregation um but the core concept of uh consensus that

finalizes within within a single slot um we would keep that um and basically just to use that to make it not viable to make these uh mev rear attacks so this is the first goal right the first goal is to basically reduce the ability of even a majority of validators colluding with each other to cheat the network to do um uh to attack the participants in the network uh profitably uh so this is goal one um goal two is to reduce um attacks harms um risks that come from flaws like ish um issues problems that are already known in the combination of lmd ghost and casper ffg

that ethereum already used uh or that the ethereum mad beacon chain uses today right um so basically there are there are a number of these attacks so there is a balance attack there's an attack that um jumps uh between two chains in the middle of an epoch um there's uh in a um this um attack on the fortress rule where if you have one third then you can rely on like the way that adjustations are processed in order to reorder one single slot um so there is some just a bunch of these attacks that have been discovered recently over the last decade or so and um we already have ideas for and uh like very well developed ideas that can be

implemented soon for um how the uh consensus can be hardened against each of these attacks individually but these fixes uh increa they do increase complexity right and so and i think it's clear that the the fundamental combination of lmd ghost and ffg is definitely like less elegant than and like it's more inherently um unstable than it seems to be about it about a year ago um and so the goal here is well how about instead of trying to combine together lmd ghost and ffg and having these two very different mechanisms and trying to get them to talk to each other and agree with each other instead of doing that how about we just

comb um just to use um ideas that are already well known to work which is basically just single a single slot finalizing consensus right there's plenty of papers talking about it there's plenty of implementations of it it's something that everyone uses that's a theory well-established and robust concept so let's just use it um now we are going to still need a fork choice for the case where more than one third is offline but it's not but that's only an exceptional situation right like it's not the fact it's not the case that like in every single like even in the normal case you have this conflict between lmd ghost and ffg and you even have these just inherent problems and lfd ghosts popping

up so that's cool too goal three is to increase the efficiency and decrease the cost of uh running validator notes right so one of the reasons why the deposit size currently has to be 32 each why it has to be so high is because the we really need to have a fairly low cap on the number of validators because there's a limit to how many validators can be safely processed and the problem the other problem is that the actual cost of running a node can be very volatile right because it depends on how big the validator set size is right so

right basically the bigger the validator set size the the higher the cost of running a node and it's about a linear relationship so right now we have we only have about 7 million if a little bit more than 200 000 validators the cost of running a node is fairly low but then in the future like what if there's 40 million is taking the cost of running a node could end up being much higher right so the cost of running a node could easily end up being although being up over here and the problem is that you have basically node operators they have to buy hardware designer setups with the assumption that they have to survive not

just this case but they have to also survive this case um so node running cost is high no running cost depends on the validator set size in the proposal um because it's committee based because it's based on a randomly selected uh sample of validators where the size of that committee is a fixed number um the chain does not become harder to validate um if the validator set size increases right so there's a a fairly simple maximum and you just whatever the validator set size is the node running cost is going to be about the same right so the proposal basically just means that the cost of running a node is going to be lower and the cost of running a node is going to

be more predictable um so that's goal three goal four is to just preserve important properties of this of the beacon chain as it works today right so the beacon chain as it works today provides a high level of economic finality it provides this really important guarantee that once a block is finalized it's it's like it's extremely expensive to revert that block right once a block is finalized in order to revert that block um you have to be able to like basically get get one-third of your validators slashed and that and that the penalty for that costs like hundreds of thousands or even or right now millions like more than two million if um so

we wants to preserve a high level of economic finality we want it to be continued to be expensive um to attack the system and to revert finalized blocks another important property we want to preserve this is the property that the beacon chain has that tendermint does not have and that we want to have is uh the continued function and contain when more than one third is offline and the ability to recover in the case where more than one third is offline so when more than one third of a committee is offline we do not want the chain to just stop uh we want uh some kind of mechanism where the chain can't recover from that so that's goal number four

so what is this new idea that i'm proposing right like how does this work um basically today in the beacon chain right every validator participates once in every epoch right so in every epoch an epoch is a 32 swats every single validator in the entire system has to sign one at the station has to participate in in one round in this design instead consensus is done by committees so and there is a committee every swat so for example you might think well in every squad there might be for example 8192 randomly selected validators um and there can be different numbers that we choose 8192 is a is at only slightly more expensive than uh or or slightly

more than the amount of work value or the amount of validators burst a lot today so it's uh a number that we know that we can handle um so the idea would be that consensus is done by committees and the committees are just always this size at any point in time a particular committee is responsible for finalizing the next block and the committee that is responsible does not change it stays exactly the same until one of two things happen the first thing is a block gets finalized or the second thing is the committee gets inactivity leaked away right so what that means is that if the uh if uh currently there is one committee like we'll call it a committee a and that one

committee finalizes a block then after that the committee can switch to committee b if more than one-third of committee a uh drops offline then the inactivity leak starts and the inactivity leak is exactly like or very similar to how inactivity leaks work today right so every the deposits of every validator who's not participating decrease until eventually the deposits of every validator who is participating um become like two more than two-thirds of the remaining uh validator set and then it finalizes again and that's when uh you can switch committees um so consensus is done by committees and

either of what gets finalized or the committee gets inactivity leaked away this is the only way that committees change um so this is just a diagram showing an example of how this might work so basically like let's say we start off that you hear we have a block a and there's a committee that's uh responsible for finalizing a and the committee runs the consensus algorithm the committee algorith uh the consensus algorithm then um we'll say it agrees on a and it finalizes a um then after that it's um um

there is the next block um and there's a block b and because consensus succeeded the validator set changes and so there's a new committee um and the new committee tries to come to consensus on b now we'll say for to make the example more interesting let's say that that this this committee fails right let's say the network does this is not working well and let's say b does not get finalized right but um let's say block b wins the virtuous rule so now what happens is in block c there's a validator set now there is an inactivity leak and uh b it does end up like the validator set does end up a little bit different um and it tries finalizing uh finalizing b

again um and it maybe succeeds it may be fails and let's say the enter the network is uh being inefficient right now and so consensus fails again now let's say there's a block d now because of the network is not efficient um and d does not even notice c d instead builds on b um but um the validators they still come to consensus they're still trying to come to consensus on the same block b so the value set of d comes to consensus on b and they let's say they come to consensus successfully um and so finally they succeed um and like this might be because while the validators like

there's an activity leak so the validator said or at least the composition the balances of the validator set up are already changed so maybe like the validators that were offline over here they have less their deposits are smaller the validators that were acting correctly their deposits are the same and so the validators that were acting correctly they're now up to two-thirds so they can finalize b correctly and so now you could go up to the next validator set and then the next validator set is now trying to finalize e and e builds on top of d right so basically during every slot you the committee just keeps trying to finalize um and during um what when you have this a long

period longer period when you do not have consensus um then you have a fortuitous problem right and so sometimes like the fortress will decide so like you see the head is be the head is d the head i'm even over here like when the committee decides to finalize e it it actually checks that e builds on top of the head right um so you have a fortress rule you also have this consensus mechanism and the fork just roll just always runs as it does today but the consensus mechanism instead of uh working every epoch it actually tries to finalize every single slot um so this is roughly how this would work right now for the consensus algorithm there's two options one option is to try to copy tendermint as close as we can

the other option is to start with casper ffg so can't start with casper as it exists today but instead of having casps for ffg today where um an epoch lasts for 32 squats like you would have a casper ffg where an epoch lasts for one slot um and for safety reasons you actually have to have the validator set um like say between this and this instead of changing completely it would only change by one quarter right um so these are the basically the two mechan um the two options that i think we have there's some interesting trade-offs between them um but i think ultimately and either one of the two can work so why is this safe right and the reason why this is safe is because is um that

in order for two conflicting blocks to get finalized um they're basically like if you have two different thing blocks that get finalized um then there has to be some first point at which two conflicting block blocks get finalized right like you have two chains that what one chain diverges one chain splits up into two chains there needs to be some first block on the one on the left chain then some first block on the right chain that get finalized for both of those blocks to get finalized because we know that this is how consensus algorithms work you need either one third to be slashed on both sides or on the more recent side so on the side that finalized later um you needs to have a very large inactivity

leak right so he needs to have one of these two things to happen and the reason why this is true is the same in the committees in this uh version of uh consensus as it is in the casper ffg as it exists today um so exact same logic except instead of applying to the whole validator set it applies to a committee um but like basically the first time you have these the double finalization the committee finalizing um on the left and the committee finalizing on the right will be the same and so like you just have to have of this slashing happen in both cases if a committee goes offline or if more than one-third of a committee goes offline the possibility of an inactivity

leak allows recovery and then if a committee uh if a committee or 51 percent of the validators in a committee start censoring then the community can do a user activated software and it can recover from the censorship right it can basically just go off and finalize a minority change um so basically it's safe for the same reasons why um a regular um um or the current version of a casper ffg where everyone is validating and every round is safe now one important nuance here right this is extremely important is the fact that the committee does not change until either it leaks or something gets

finalized right now this is really important because it means that like it you're not going to be able to have a situation where like oh well you get double finalization you have a different block finalized on the left and a different black finalist on the right because they're finalized by two different committees like no in order for there to even be two different committees you have to have already had a finalized block on the left and a finalized block on the right that that both use the same committee um so and for that to actually happen well you need 130 to get slashed or you need an activity leak right so that this is the core idea um one interesting extension is multi

confirmations right so basically the idea is that what i call the dynasty and committee right dynasty meaning like the number of finalizations that happens the committee for dynasty n is chosen based on data that was already known in dynasty n minus 50 right so basically like if the block the the data um that the blockchain has today or that the blockchain has right now will only be used to choose committees after 50 uh confirmations right so after 50 rounds of this consensus the goal of this is that if you have two conflicting chains then for the committees to start to diverge you don't just need one committee to double

finalize you don't just need one committee to finalize two um giveaway conflicting blocks and get squashed you actually need 50 consecutive committees to um finally or to confirm to conflicting blocks and to get swash on two conflicting blocks right so basically instead of requiring like one fi um finalization or one of these um a round of consensus to consider a blog finalized you require 50 rounds of like sets to consider a block finalized um and then you do this trick where the committee is based on data from uh dynasty and minus 50 some from 50 rounds of successful rounds of consensus before and

this means that you actually do have the security of 50 consecutive committees 50 committees um what coming one after the other um actually adding on top of each other um so a lot of nice properties so how does this affect cost of attack right so we really care about cost of attack one of the really nice properties of uh the beacon chain as it works today is that if you want to revert a finalized block you have to slash one third of the validator set right and that costs the attacker like over a million if it's extremely expensive so we have a chart here right basically if you have different deposit sizes different committee sizes um different

committee look ahead so like there's a number um instead of 50 like what what you actually set that number to and one column is the amount of ease needed to break one single committee and here is the amount of if needed to break finality right so the number on the right is the amount of if that an attacker needs to be willing to burn to revert a block that has been fully finalized and this is an extreme amount more than one million he is completely unrealistic right um this is um what the attacker needs to break one single confirmation so to get uh it's a one-third of one single committee um basically if the attacker is willing to burn this um the smaller amount of e if

the ethiated to break one single confirmation they can revert a single finalist slot they can prevent finality for two weeks and they can censor and they can force a um ut a user activated soft fork to stop the attacker so the attacker could do some pretty mean things um with uh depending on the parameters between three thousand and the two hundred thousand each um so it's a good argument to set these parameters to be on the high side um so that's one thing that they can't do um if the attacker is uh willing to actually burn the amounts on the right then the attacker can do a lot even more crazy things

now one um notice that all of these attacks like these numbers are just the cost right these numbers are the amount that the attacker loses from being slashed the amount of if the attacker needs or the amount of alligators the attacker needs to control is still the integrity is to control close to 50 of the entire validator set because the attacker like every committee is randomly sampled right and to get more than 50 of a randomly sampled committee you have to have close to 50 of the total validator set so the budget is still very high the amount of validators the attacker needs to control is still very high the cost is lower but i claim that the cost being lower is okay

because even in the current beacon chain there's a lot of these low-cost low-grade attacks um attacks that do not cost a huge amount that also do not cause a huge amount of pain but the still but still cause a pretty large amount of pain um so persistent extreme or hostile maybe extraction um griefing attacks um mild censorship attacks there's all of these attacks that an attacker can already do if they have 50 where these attacks are low cost and they're not uniquely attributable which means that you cannot like easily detect um in a way that can convince everyone exactly which nodes were responsible for participating in the attack right so basically

like if an attacker has access to controlling half the validator set and the attacker is willing to burn a hundred thousand if there's already a lot of very extreme things that the attacker can do and so i would argue that going to like this committee-based model of consensus is actually like it only um it it does add like one new opportunity but to attack but the one opportunity is not even cheaper than opportunities that already exist um so benefits for validators from this design um constant node running load um so basically instead of the uh the computational cost of verifying the beacon chain uh being variable it like

instead of it depending on the number of validators it's it's a constant it's just the size of the committee um you could actually have very quick withdrawals in some cases right because um most validators are inactive most of the time while a validator is inactive it turns out it's actually completely safe for them to withdraw um also a simpler code base from not having this kind of complex combination of uh um lmg ghost um and e-box and slots but just the code base can be simpler and this means less software risk for validators and less software risk for users so how do we get there right so for now mostly wait right this is a long-term

idea this is an idea that like i'm throwing out there early but i expect to be implemented after the merge after sharding after stateless clients um so not soon um there's the merges uh and sharding are more important and more urgent problems for now ongoing thinking ongoing review um check does this path really make sense and how does this path compare to cbc right like if you look at the uh ethereum roadmap that i published on twitter um i think in december last year um the current the roadmap for long-term beacon chain evolution talked about cbc um this would be an a replacement for cpc right

it would be an alternative that has very different properties to a cbc um but properties that i think could be better right but you know are those properties actually better like actually do this analysis and then once there's some more analysis a more detailed specification and a more detailed testable notation um so that's it and this is where we are now um so you know this is um basically just an alternative idea for long-term evolution of the beacon chain which is something that we wanted to do already right um making some modifications and fine-tuning and refining the beacon chain consensus has been something that was part of the plan

since the beginning and this is just a different way to do it um and it's a plan that at least i think deserves some consideration um it satisfies some goals that i think a lot of people care about and for now it's just uh some um something that's worth that's worth thinking about and something that's just worth us doing some more research and some more exploration into thank you