leanConsensus Call #6: 3-slot finality

Transcript

Introduction

Justin Drake: Hello and welcome to beam call uh number six. Uh this call is dedicated to finality specifically 3SF. Uh today we have five different speakers across four different talks and I'm also going to give a very uh quick uh logistical uh presentation. So without further ado, let me share my screen. Okay. So, um these are links that I've shared quite a few times, but they are useful if you're new to these calls. Uh we advertise the calls on the Ethereum

protocol calendar. You will find all sorts of other calls if you're very much interested in Ethereum R&D in this calendar which is public. Uh there's also a discord uh with lots of uh various topics uh discussed uh across the devs and the researchers. And finally, these calls are recorded and go on YouTube. Uh and there's also a very handy website uh beamroadmap.org which uh o a community member um has uh built. So um the way that we're organizing these calls is uh basically in three parts. First, we had a bit of a special call, the the the social updates

call where the the the people who had reached out uh at the very beginning and wanted to to contribute uh were given an opportunity to to introduce themselves and then we had this whole series of calls around research updates of the key topics uh within uh the the the beam chain. And it's quite exciting because we're almost done. This is the the penultimate call um just before rainbow staking after which we'll basically have covered uh the main uh topics within within the beam chain and uh it will kind of culminate with beam day in in can uh just before ICC on on June 29th and then in the second half of the

year uh in Q three and four we're going to be diving much more into the the specs and the strategy here is to start with so-called subspecs. So specs for the specific um subm modules within the beam chain and then towards the end of the year in Q4 putting all of the pieces together and having a full feature complete um beam uh beam spec for the state transition function. And uh we're also going to have a a special beam day in in Buenosyus which we're organizing right now. And if you'd like to join uh beam day, here's the the luma registration.

No promises, spaces are limited. Uh but uh yeah, do do apply if you're will be in in can. Now I also want to give a little bit of a shout out to the sister project in some sense to to the beam chain. If um if uh the the beam chain is kind of this this this radical upgrade to the the consensus layer, if proofs is all about a radical upgrade to the execution layer where we're snarkifying the EVM, we're radically increasing the gas limit by 100x, a thousandx uh we're doing things like native rollups which expose the L1 execution and all sorts of other exciting things. So if you are

interested in in that topic uh there there is a dedicated call series uh and um telegram group and the next call will be on real-time proving and if you are a ZKVM enjoyer I would recommend joining this call because uh there's going to be some some big announcements regarding uh real time uh proving. Now here are today's speakers. We have five different speakers. Luca and Franchesco are going to give us a uh quick sync up and intro on 3SF. Uh then we're going to have Vitalik talk about an actual proof of concept implementation in Python 3SF mini. Uh and then Roberto um will talk uh about

Gasper & LMD-GHOST Overview

Justin Drake: formal verification and then uh Draim uh will talk about uh accountable aliveness. So yeah, without further ado, uh let's have Luca and Franchesco uh on on the stage.

Luca Zanolini: Thank you, Justin. Let me share. Can you all see? Yes. Awesome. Hi everyone. Thank you, Justin. Uh yes today as Justin already mentioned we are

giving you a an overview of the theoretical foundation and practical considerations of our proposal for a faster finality protocol for Ethereum. Uh I will first start by giving you an overview of how the currently implemented consensus protocol works Casper so that we can build everything organically and then Franchesco will start introducing the our proposal. So uh let me first start with uh with Casper. This is again a very high level overview so that we can all synchronize on the terminology mechanism that will be used then to for later for the presentation. So as you might know uh Gasper is a proof ofstake consensus protocol meaning that nodes in order to

participate in the consensus protocol need to put some money in stake becoming validators. So throughout the course of the presentation I'm assuming that we have n known validators. uh of course observe that this set can grow or shrink over time because we can have new validators joining the this set or some leaving. Uh but for the sake of simplicity let's assume that we have n validators. Uh the protocol actually comprises two subprotocols or components or modules however we want to call them.

Uh each one with its own properties and each one with its own reasons to be there. Uh one is LMD ghost. This is a synchronous consensus uh protocol that determines the canonical chain meaning that the chain that we are used to transacting in. Uh here with synchronous I'm we mean that in order for this protocol to satisfy all the good properties uh we need to assume synchrony meaning that we need to assume that there is a known upper bound on the message exchange among honest validators. And the other subrotocol is Casper FFG. This is a partially synchronous protocol that irrevocably commits the chain outputed by LMD ghost or another term or used is that it

finalizes the chain outputed by LMD ghost. What it means is that we basically have this chain that uh keeps growing output by LMD ghost protocol and then we have this casper FFG that is sort of a gadget that finalizes a prefix of it in a way that basically if um a synchronous periods happen or network partition or something that happens we know that the finalized prefix of this chain will never will not be reverted. So it's always safe even in case of a synchrony. Uh because we have two subprotocols, two protocols, we also have two time scales in which we in which Gasper operates. One is a time scale for LMD ghost which is a slot. A

slot is a time unit in which a block is proposed and voted and a collection of 32 slots define an epoch. The epoch is the time scale in which Casper operates. What happens basically is that for every epoch the set of validators is partitioned into 32 disjoint committees one committee per slot and because of that in every epoch every validator gets to talk only once. Okay. So if we consider a slot what happens is that we have a commitee associated to this slot and within this committee a randomly uh a validator is randomly selected to be a

proposer. What the proposer does is to create a block and gossip this block around. Basically this block is created that is appended on top of the chain that the proposer deems as valid. What it means with valid will become clear in a couple of slides. It gossip this block around and ideally the other validators within this committee will cast a vote ideally for this uh for this block. In this presentation I'm always assuming that we have good network conditions. So we have synchrony honest proposer so that it's also easier to describe how the protocol should work. Of course there are then corner cases but they are out of the propo of the scope of this very general overview of the protocol.

So what happens is that under these conditions we have basically slot after slot a new block votes on it new block votes on it etc etc etc. This slot has a duration of 12 seconds. And what happens is that over time we have basically a chain which is the chain that I mentioned before this canonical chain output by LMD ghost. And what I mentioned before is that validators needs a way to identify the chain. For example, if I'm a proposer, I need a way to identify where to append my block.

And we have a function called fork choice function which in the case of Casper it's also called LMD ghost fork choice function which basically takes as input all the messages received up until a certain point on time in time and it outputs basically the chain the valid chain and the way in which this function identifies this chain is based on all the latest votes. Basically the valid chain is the heaviest chain identified by all the latest messages of the latest vote cast by the validators excluding equivocation. So for example in this in this picture this is the chain. This means that if we are in slot B10, the

proposer will see this chain and it will append assuming that this proposer is honest, we'll append the block on top of B9, gossip this block around and also all the other validators within the committee will also evaluate the forest function and they will ideally cast a vote for the block that is proposed. uh again the weight of the chain is given by the votes uh cast by validators because every validator again has some stake. So each vote comes with an amount of stake associated with it. Uh up until now I was very generic generic in describing this ving mechanism but if you remember at the beginning of this presentation I meant that um Casper has two subprotocols. One is LMD ghost the

other is Casper FFG. Okay. Moreover, I also mentioned that within a given epoch, every validator gets to talk only once. This means that when it's time for a validator to vote to to talk, it needs to contribute at the same time to both of the protocols. It mean that validators in Gasper participate in the two subprotocols at the same time. And because of that the voting structure in Gasper is a sort of complicated beast that is made by multiple components. One component is the component that I just described meaning this head block component meaning the vote or the block proposed in the block in in the in the

slot. However, there is also a contribution for Casper that needs to be taken into account and this is itself divided in two subcomponents. One is called source checkpoint and the other is called target checkpoints. Here checkpoints are a special structure but you can think of them as blocks at specific high of the chain and generally again as a sort of textbook protocol. Generally these are the first block proposed within an epoch. This means that within a whole epoch all the validators will cast a vote having as a target checkpoint the first block proposed in the in the epoch and if at

the end of this epoch we are able to to to find more than two3 of votes weighted by stake uh with the same target then this target becomes justified in the subsequent epoch this justified target will become the source and if at the end of this second subsequent epo we are able to find more than twothird of votes with the same source then this source gets finalized. So as you can see basically in general the source checkpoint is the latest justified checkpoint in the view of a validator and the target is generally speaking uh the first block proposing an epoch again here I'm being very generic

there are there are other cases but just to give you a rough idea of how the protocol generally works so we have this idea we have this mechanism where under full participation synchrony and all of these good condition a block uh this prefix of this prefix of the chain gets finalized every two epochs. This means that currently Gasper takes between 64 95 slots to finalize blocks. And this means that all the time we at all the time assuming good network condition we have a nonfinalized prefix that has a that has this kind of size. This means that in case of non full participation

this non-finalized prefix can grow and grow and grow always more. So in some sense exposes also to reorganizations of this non-finalized prefix in case of network partition or synchrony. So what we want here is to have a faster way for analization. Ideally, we have this notion of single slot finality, but technically speaking, we don't literally need single slot finality. What we want is a protocol that can finalize faster. So, Franchesco, now in after this slide, we start presenting our proposal for a three slot finality protocol, meaning that ideally under good network conditions, etc., we are able to finalize a block within three

slots. Another property that we want is this reorg resilience meaning that we want that honest proposals remain in the canonical chain wherever assuming synchrony. Right now we do not have this property in the LMD ghost component and here I so I have another motivation why we were driven for to work on these proposals. One was to make protocol faster. The other was also to kind of fix quote unquote the security of the LMD ghost protocol because in the past few years few attacks have been discovered against LMD ghost even under good uh network condition and and etc that were able to create problems at the

safety of the protocol. So what we did basically was first of all to improve LMD goes by giving some proposals for an alternative component that could that was that was able to satisfy this real residence so that honest proposals will always remain in the canonical chain. This means that even if we do not have full participations we know that under synchrony if a prop if an honest proposal is made it will remain in the canonical chain forever and it will eventually be finalized. Another thing that another property that we might want is this dynamic availability for this uh component that outputs the canonical chain. Meaning that we want to be able to tolerate participants validators

going offline coming back online even if uh without sorry without halting the chain. This doesn't necessarily happen in Ethereum because as you might know, we have a sort of incentive scheme for validators to remain online and cast timely votes. But at the same time, you also want to be able to tolerate, for example, consensus client crashes as it already happened a couple of years ago where a bug affected couple implementation of the consensus client and 60% of the network went offline for some time. And we want to be able to keep building a chain which together with this real resilience property we know that if we have synchrony then

everything will be good eventually because then full participation will come back and we will be able again to finalize without having to halt the chain. At most we can hard finality. And the property that we want that we already have is this accountable safety. Meaning that we want to be able in case of safety violation, safety inconsistency to identify protocol violators and punish them or slash them um removing some of their of their state. So these are the properties that we want. And now Franchesco will actually get into the more interesting part I guess for this presentation which is actually our proposal that I

3-Slot-Finality (3SF) Protocol

Luca Zanolini: mentioned uh before.

Uh Franchesco

Francesco D'Amato: do you want to share? Uh yeah I'll just share my my own screen. Okay sure. Um you have to allow me I guess just thanks. Uh yeah so I'll just continue from there. Uh yeah so the the proposal that uh we currently have it's as already mentioned is uh we call it a three slot finality protocol uh in contrast to what we had talked about before for for a while which was this SSF single slot finality kind of paradigm. So the first question is uh you know why move away from single cell finality and there's a

there's a few uh reasons. So the the obvious thing is that it requires uh more uh voting rounds per slot. It's actually three voting rounds not two. Like you might know that generally finality requires two voting rounds but we're in this specific uh kind of uh context where we have this dynamic dynamic available chain and it imposes a bit different requirements. So actually uh we think at least that you you need really three voting rounds. Um and uh yeah, being able to pipeline this voting rounds uh means that we have lower block times. Like we we essentially have uh less voting per per uh block. Um and this is better for for a few reasons.

It's better for onchain markets. Like there's this whole lever kind of uh line of uh reasoning that that uh um or like how lever scales with with block times. Uh it's better for censorship resistance. We just have more proposers per time. Um, and yeah, it's uh there is a there is a trade-off, however, not everything is is better. It's just that we we actually get higher time to finality, but not uh too much and it's still uh very very much lowered compared to uh the two epoch uh time to finality that we have today. So though there's this trade-off to make uh very possibly it might be the right one. And there's also other reasons. uh one is that uh if we have more more voting runs per block

it also means that there is less time to propagate the block compared to the whole slot. So like you could fix you know keep fix the time for for block propagation but now the the the slot time increases um and block propagation is is kind of a sensitive uh thing that like essentially uh um something that we'd like more of not not less. Uh we'd like to increase block sizes have more blobs and so on. Um, and then another thing is that having multiple voting rounds without blocks in between them is a bit tricky from a incentive perspective. It means that you don't have chances to include votes in between voting rounds. Um, and so yeah, this just makes the design of an incentive mechanism more complicated. It's not to say that it's impossible, but at least

that's not how the current one works, and it seems a bit definitely a bit harder to to see how you would do it. um at least by maintaining the same kind of guarantees that we have now. Um yeah and uh motivation as a side uh this is kind of uh how the the protocol is structured like first starting from the uh dynamic available component. So basically the the replacement for LMD ghost. So on top here um you see uh this like proposed vote proposed like kind of structure which is essentially just what we have today. Um I mean it's not uh you know here maybe the the voting part would be not half of the slot because we have vote aggregation today but it doesn't really matter. Um the point is there's kind of just two phases like proposing a

block and voting. Um and we basically need to add two new phases uh which we call fast confirm and uh freeze. Um so kind of add more things to the to the slot structure. Um and uh yeah just going through how the the slot works. uh proposed phase, same thing. The the voting phase actually also same thing. Uh you would basically just be voting for the the fourth choice head. So you you run the fourth choice. Um this is going to be like a slightly different protocol than LMD ghost, but still basically the same as LMD Ghost. Um so yeah, just really more like tweaks that kind of um allow the protocol to have better properties. Um and yeah in the in the happy path the thing that you're

voting for is just the block that was uh proposed immediately uh before uh then the the first new thing is this uh fast confirm phase. Um so essentially all that happens here is that if you see a quorum uh so twothirds of the stake from from the whole stake um and remember like we are in this kind of dynamically available uh setting where you might not actually you're not expected to always have uh all of the votes. Uh but still in in in this case like if you do get a quorum so same kind of similar as you you would require for a justification or or finality more or less um you you actually consider um a a block to be confirmed and this is a notion that we don't quite have today exactly it's it's

a bit weaker than justification and and of finality but essentially it's it means that the block is synchronously safe. So uh assuming uh on its majority and synchrony the the block it's not supposed to be reorg if you if you uh kind of satisfy this condition and then I'll later explain like why do we even uh want to have this why you want to add uh this phase uh then we have this freeze phase uh which essentially u means that validators stop adding uh new votes to their to their let's say active view.

They're still like buffer votes. they don't like just throw them away or or not receive them but they don't uh kind of act actively put them into the votes that they consider for for the next time that they run the for choice. The reason for this uh and yeah importantly the proposer does not do this. So the proposer keeps listening let's say actively so it keeps adding votes to to its actual uh the place actually keeps votes that he uses for the for the for choice does not just buffer them and uh the reason to do this is that basically the proposer gets a bit of an advantage in the sense that whichever votes were seen by validator at this freeze time the proposer should also see assuming uh the network is synchronous and so the

proposers should essentially be able to incorporate all of the votes that everyone else uses uh in in its own view. And I'm not going to go into details of exactly how the mechanism works, but essentially this allows uh the proposer to synchronize uh everyone's view on on what it's seeing. Um which basically allows honest proposers to make sure that other validators uh vote for their proposals like basically agree with with their view um of the of the for choice uh and actually vote for for what they're proposing. Again, this is only for honest proposers. So you can't just propose whatever and get other people to agree with you. Um you can only kind of uh get a little bit of an advantage to to make sure that certain attacks that exist in LMD ghost don't uh affect

you. So it's part of this like kind of fixes of LMD ghost that Luca alluded to. And so one question um you know coming from the the picture above this like very simple LMD goes propose vote propose uh picture is like um well now we add these two extra phases like can we just not uh why do we have to make the the slot longer um and it's I mean it's not uh sure that that this to be the case but it might be that this is the price we have to pay for for dynamic availability. So there's definitely like conversations to be had about this price and well two things whether it can be reduced and and whether it is worth it.

Um but yeah in terms of uh the first part which is uh whether it can be reduced let's look at them individually. So the this fast confirm phase um the reason why it's there in the first place it's not just because we we just would like faster confirmations like in principle we could just wait for finality. That's kind of the whole point that we're making finality faster. So why do we need this faster confirmation and uh yeah the reason is that um basically as far as we know like all uh existing dual ledger construction so all of these things that have an available chain and a finality gadget on top of that um which is exactly the kind of construction that that we're dealing with but not the only one that exists.

there's been like there's some literature on this and basically all of the ones that have uh good properties that have been shown to be provably secure. Um they all work with this principle of first confirming a block in the available chain and then try to finalize them. Um so you don't try to finalize uh things that are not safe in the available chain. And yeah, the reason for this is is essentially that if something is not safe in the available chain, um it it might and you try to finalize it, it might be that you succeed and then it causes a reorg later. And I I'll explain a bit with some pictures a bit uh what that looks like. And uh yeah, if um in given if we take this as as a given that we we need

to to have this kind of u uh confirmation before trying to finalize something, it's at this point not clear if we can do this in one slot. So we we want to uh make sure we don't add delays to the finalization pipeline. So we want to do it as fast as possible. And it's not clear if we can do it in one slot without this extra delay. At least we don't we don't have a protocol that that does this basically without an extra delay. And so this this extra phase essentially um as for the freeze thing similar story like it's not uh it's not there's no proof that that you need this extra phase but what we know is that basically all the existing dynamically available protocols uh except longest chain so all the ones that have some

kind of voting mechanism and I mean longest chain is not interesting here because it has like super long confirmation time so it's really and and like it allows reworks so it's it has like very bad properties is um I mean it also has very nice properties in other ways but and it's very simple but it's it's kind of out of scope of what we're interested in u and yeah basically all of the ones that have the kind of behavior and properties that we want they do have some kind of proposer synchronization mechanism uh like this it's not exactly this one but they always have something uh along these lines so at least so far it seems like a possibly an avoidable thing again not clear it's possible that someone comes up with a with a better mechanism or a better protocol without such a mechanism

but so far it seems a bit of a uh again price of of dynamic availability and uh yeah about the the first point uh do do we need confirmation um you can think of basically this example imagine that um we have this u situation with like conflicting blocks some honest people vote for one some honest people vote for the other one and then there's some adversarial votes that are they're hidden for a while on top we have the the block that wins it's this a block, it's the head of the chain. It keeps winning, but it cannot get justified. So, this yellow block is the is the justified block and it stays the the justified block. Um, so it it keeps getting 60 votes for a while, but it doesn't get justified because it's not 2/3. And then eventually this 40 uh

adversarial votes are are revealed. And this basically constitutes a justification of B because again here we we try to justify something without first confirming it. So uh the the uh block B wasn't confirmed. I mean it wasn't even canonical uh ever in in any uh honest validator's view, but we still justified it. We still allow these votes to to basically form a justification certificate. And so yeah, once B is justified, it it creates a reorg of the the whole chain on top. And so yeah, under certain conditions like it really uh makes the whole um thing unsafe essentially. And uh yeah, so that that was for the dynamically available component. Um and then as Luka said, we have uh this uh I mean just this general

family constructions is like you take a dynamically available component and then you put like a finality gadget on top. And this is kind of how we construct this uh threes law finality protocol. So actually looks very much the same. It's it's the same structure as before. The only difference is that this voting phase is now actually just like today in in Gasper. you don't just send a head vote, but you send a head vote and an FFG vote. So, kind of a vote for for both protocols and uh what it looks like uh and and yeah, I mean I should say the right the finality that we're using is is still basically Casper FG. So, actually there's like essentially very little change there. Um and uh yeah, this is essentially what it looks like.

Uh once you look at uh I mean it's it's called three slot finality. So, you know, we're looking at a three slot sequence. Um and uh oh yeah I mean here the slot is uh for some reason missing uh the confirm phase but yeah pretend that it's there. Um so yeah these are meant to be the same slots as before but basically what the kind of uh the the path of a of a block in in in this uh uh protocol looks like is that in the first uh slot where it's where it's proposed it gets confirmed in the second slot uh so everyone votes for it in the second slot everyone uses it as the FFG target and so it gets justified and then in the third slot uh it's it's used as the FFG source and so it gets finalized

essentially. Okay. And yeah, this is as I mentioned before these three voting rounds that uh we we would otherwise need to compress into one like the confirmation round, justification round and finalization round. And instead we kind of spread them out over three slots and uh yeah and we have this uh so that that was uh looking at a single uh the path of a single block through the protocol but uh we have in parallel multiple blocks that kind of go through these stages with a kind of off by one. So this is the same as before. confirm, justify, finalize and at the same time uh the the next block would be confirmed while this one is being justified and uh yeah same essentially uh afterwards this would be this one would be justified uh the next

one would be confirmed and and so on. So in the ideal conditions we're always at the same time doing three things essentially and uh yeah so this uh I mean uh this point was a bit uh high level but uh more specifically um it's worth maybe looking at how exactly do we vote do we vote like what what are we voting for and uh so let's take uh slot t and say that the latest justified checkpoint is uh block b at checkpoint at slot s so this this block b and there's a corresponding checkpoint which is justified. Um so if this is deleted justified, this is where we're starting the the fourth choice. Um so how we vote is the the head of the chain is the uh so the the thing that we we do the head

vote for is just the out the output of the fourth choice. So we we start from the latest justified. We run this uh LMD ghost like protocol um and we uh then get the thing that that we're voting for. The source of our vote uh of our FFG vote is exactly the latest justified checkpoint. So this be at slot S. And then the thing that's a bit different in today than in like kind of regular caser FFG is what the target is. So the target would be a block T at a slot T at well slot T is is the current slot. Um but it kind of uh there's a bit of a um difference in how we determine what the the block T is. So as I said before,

it's meant to be uh the target is meant to be confirmed. So this is something that we're basically inputting into the justification and finalization pipeline. It's kind of the entry point to towards being justified. And so we want this to be confirmed. Um the the best case would be basically that we try to vote for the highest confirmed block which in the in the really best case would be the block from the slot before. So kind of going back to to here something gets confirmed and then immediately afterwards we try to justify it. Um so it's it's in the next slot it becomes the target. So yeah it basically would be this like if we're in this slot and then uh we we use this as the target uh if it was confirmed.

But actually we only do this if we are in the in the happy case where uh basically the latest justified is recent. It's really something that was justified in the previous slot. So this s is tal t minus one and uh if it's that's not the case we're kind of in a in a non as great case where there's not a recent justification then we would basically make the target be uh either B or the KD block. So we kind of go deeper in the chain and find some block that we are sure is safe. Um and yeah I mean if this block is after B we take that block otherwise we we will take the latest justified itself. So for example in this case we would take this block here. So kind of a K or Kappa from the beginning

of the chain. And the idea here the idea here is basically that um this block is um so once we're in this case something bad is happening where uh the delay is justified is not very recent. There's a potential for some new justification kind of in between that can cause reorgs. there's this concept of bouncing attacks that I can't I don't don't have time to to get into but uh it's it's kind of a tricky another tricky thing of this uh merging of finality gadget and an available chain and kind of once we're in this uh potentially tricky situation we want to make sure that we use a target that's uh that everyone can agree upon and so the the nice thing

here is that if anyone that agrees on what the head of the chain is would also agree on what this uh capadep block is So if you if if you agree that this is that of the chain, you agree that this is the the block KD deep and so you would also agree on what the what the target is. And this means that uh the justification is actually guaranteed in this case that if we're in an honest uh slot in particular uh then we we're sure that in this bad case we can actually fix things kind of save things and and make progress and and justify a new block. And in this case we actually guarantee that we get finality in three slots which is a bit counterintuitive because as I said this this supposedly is the bad case but actually in this bad

case uh we can guarantee that uh if if it's an honor slot we it will actually be finalized uh for sure in three slots and uh yeah with this I think I'll leave you uh there there's more that Roberto will talk about but uh in between I think Vitalic wanted to to talk about uh 3SF mini prototype that he's been working on.

3SF Mini Prototype

Vitalik Buterin: Yes. Hello. Hello guys. Um, okay. Let me quickly share the GitHub. Uh, there we go. Okay. Uh so this is uh just a a project that I uh worked on uh for like just fairly recently which is

basically just a very simple and minimal uh implementation of three slot finality in Python. Um and so it's in GitHub Ethereum research and then in the 3SF mini directory. And the goal of this is basically to try to uh like present a concrete implementable version of the three three swat finality consensus logic and then put that in an environment where we could it actually runs. Uh you can actually test it. Um, and uh, you can you actually get to see like what a live network out of these kinds of things uh, is able to look like and you're able to see all of the core

pieces of the of the protocol running. Uh, so maybe just uh, uh, go through some of the files here, right? So this is uh, like the whole thing is basically about like 400 uh lines. I think like 500 if you include the testing code. Uh but uh so this is consensus. So this is basically the equivalent of the file that would go into um you know the like beacon chain specs and so we have a state um we have votes we have blocks everything is getting hashed um and then the yeah core functions here that are interesting are one is the yeah a function for getting the fork choice

head which basically yeah start a genesis by default but then actually yeah generally it gets called with the root being the yeah latest justified block and then from there it identifies what the latest votes are and then going through the yeah latest votes basically figure out what the vote weights are and then you do this kind of walk going from the route all the way up to the tip where you pick the highest awaited parent at each step. And uh it also has this min score parameter that basically allows you to stop uh progressing as soon as the uh weight drops below some particular threshold. And uh the goal of this is to just make it very natural and easy to implement the optim the the

targeting mechanism that Franchesco talked about. Um so um one other interesting bit uh that's in here that I think uh is a sort of original research contribution and that like so far is not part has not been part of discussions but like this is my invitation for people to take the idea seriously and uh either um rip it apart and show why it's insecure or um ideally yeah show why it works. And this is the um the quadratic backoff mechanism. And this is uh basically something that I discovered from simulations is that if you push the peer-to-peer latency up uh to the point where it's too high for the chain to

converge really nicely. So like I've been running this with the peer-to-peer latency parameter being um I mean we can actually uh uh go in here and see what the the the default setting is. uh you go into test uh test P2P um and uh as you can see the yeah latency is bounded above by 2.5 times the slide duration so I'm literally testing it at sort of 10 times uh provably safe parameters and the thing that I notice is that like there are situations where the chain just kind of stops uh converging and nothing breaks in an irreversible way uh but uh like basically once Soy goes above a certain

level, it's the the challenge is that it's just hard to get this like nice uh clean, you know, like three step in a row thing of like a block becoming a safe target and then being justified and then being finalized. And so the mechanism here is we say that there's only a subset of slots that are justifiable and the solats are basically any salat up to five after the last finalized one and then if you go greater than five then it's sort of backing off with and a perfect square relationship right so uh like you can finalize the slot nine slots after and 16 slots and 25 slots and so on and then uh also just here I add I added the obelong numbers So this is basically the numbers halfway

between perfect squares because that's like empirically better but nothing in between. And this is interesting because it lets you say that you finalize without needing two things to justify one right after the other. um instead you basically need uh to have your justified occasion slot your two justified slots where in the range in between them there aren't any other justifiable slots right and so the kind of 30,000 foot explanation of this right is that you can turn any yeah protocol that is uh safe under asynchrony and converges when uh synchrony recovers into a protocol that is that can that

finaliz izes under partial synchrony in the sense of under some delta where you don't know the delta and the way you do it is you basically search and replace time with a square root of time right because uh as then as time increases uh the sort of deltas in square root of time just kind of naturally shrink and shrink and so virtual time just kind of shrink zero right so look one the just like one interesting tidbit here um then um the way in the peer-to-peer file Oh, this is the other thing. Uh we have a uh this is the equivalent of the honest validator implementation. Um and the honest validator implementation. So it just tracks the chain and tracks known votes. It tracks all the stuff that

you'd expect it to track. And then the most important loop is this guy. Right? So this basically shows the logic of what you do at all four different parts of a salot. Right? And so you have four subs. So at time t equals z you propose a block. Um and then you have a viewge mechanism. So you accept at theest stations from the uh newest block from the most recent block. Uh but then um or um at the stations that you got uh from over here um but then generally the yeah time delay to get other people's at the votes is

like this right. So then um Over here we have uh and then at time t equals a quarter we vote and then at time two quarters you compute and uh and save the safe target right and then there's a function for proposing the block and for proposing the block we choose the parent based on the safe target. Um and then for voting uh we choose save target and then we do the like back off uh based mechanism where if there isn't uh like basically if the most recent block isn't safe then like you you walk backwards a bit. Um and then you walk backwards to either the justifiable slot or some maximum. I

set the max to three here. You can set it to whatever and you make a vote. You submit it to the network and uh you have code over here for receiving blocks, receiving votes from other people. Uh so pretty basic stuff. And then this is uh just a very basic bare bones peer-to-peer network simulator. So uh you can have many peers. They can send messages and then they can recover receive different messages. Uh so a bunch uh and then over here we have the code that actually runs the graph stuff. So I wonder if uh we can actually uh do uh a uh thing do programming research uh 3SF mini um try new share uh on uh this

guy um and then basically if you do like Python uh the test P2P then you know the thing should run um and then okay Well, it's uh unfortunately uh not actually showing the thing. Uh but here I'll uh I'll wait for it to run and then you there's like a nice Mattbot lib view of like what the network looks like. I'm almost done. Almost done. Uh crap. Sorry, it just uh stopped. Okay, here I'll uh click click figure one share. Let's see. There we go. Okay, there you see it, Justin.

Yes. Perfect. Yes. Okay. Perfect. See, and then the thing is growing. And so what we see here, right, is like you saw during the first twothirds of the simulation, the network latency was 10 times what the algorithm is rated for. And so there were like a lot of forking, but you saw the justified and finalized one like still make progress. The chain still remains stable. And then after the two/3s window latency dropped to zero and then the chain just like completely stabilized very quickly. Um, so there we go. That's the code. Uh so uh again Ethereum GitHub Ethereum research and then it's the 3SF- mini uh directory right in the top level of that just uh encourage people to take a look at the code um like pour through it carefully make sure it accurately represents the

algorithm if it doesn't complain to me um you know I welcome complaints and uh also um again invitation to explore the backoff thing because I expect it will it actually will be quiteant important in making the thing this this whole algorithm work really well under uh like high latency situations and just uh try different variations um and uh just a really good playground to do different things and uh you know potentially even use this as like the base of any spec work that happens. So thank you guys.

Justin Drake: Thank you. Vitalik has to um board a plane very very soon. So any questions for him? Now is a good time to ask. Feel free to unmute or ask in the chat or raise your hand. I mean one uh kind of social question that I have or meta question is um how much time did it take you to build this and um how much are you of your time are you planning to spend on on research and the beam chain going forward?

Vitalik Buterin: Yeah, I mean so this thing uh to remember I think it took like a few days. I mean it was done um you know like over the course of about one and a half weeks but very uh interspersed with uh a bunch of other work. So uh I mean if I had to like retroactively estimate and like turn it into like a lawyer billing hours I would probably say 5 to 10. Um and then uh I mean in general like I'm definitely happy to continue to be in uh like be more involved in different places and I think you know both this you know the the beam chain and all this um or I guess you know lean Ethereum if you know we're calling it

that and all these projects you know they are really important to me so you'll definitely see me back.

Justin Drake: Yay. I mean, just as a historical note, um, you know, something like half a decade ago ago, Vitalic wrote the initial draft of of the the beacon chain and he kind of whipped it up in a week and that was what we we polished from that point onwards. Um, so having uh Vitalik involved is a sigh of relief at least at least for me.

Any other questions before we let Vitalik board his plane? Camille,

just a quick one. Uh, is this research of three slot finalities kind of orthogonal to orbit SSF or is completely different direction? Like

Vitalik Buterin: good question. It it is orthogonal. So you might notice 3SF mini as written it's technically in one of those like evil banker consortium chains like it just says here are the 10 validators and they yeah make the blocks. Uh so the idea is that you're able to like plug in whatever validator set mechanism you

want. The one thing that would need to be added to 3 to this code to make it kind of more comprehensive as the proof ofstake part of the beacon uh you know the Mchain would be yeah the one the validator set changes and the logic for like syncing through many validator set changes and then of course like inactivity leaks and economics. Uh but the difference between um kind of the you know like four 4,96 validators and uh and and that's it versus orbit is something that you can kind of blackbox and put into that framework. So from the perspective of this logic, it just looks like validator sets that have different

rules for changing.

Justin Drake: Okay. Well, thank you guys. So good luck with the rest of your call. Thanks, Vitalik. I guess uh we can also open it up for questions on the first two speakers uh Luca and and Franchesco. One question that I have for Franchesco is um it seems that there's a lot of subtleties involved. There's all these attacks that are like totally non-trivial that uh we have to worry about. And so my question is to what extent is the protocol that you proposed uh provably secure?

Francesco D'Amato: Uh yeah, there's definitely a lot of subtleties. I think it's it's hard to deny, but I um the so the protocol that I am kind of talking about today is maybe one could say a simplified version of something that a paper has been written about. I think the the protocol that the actual protocol that the paper's been written about which is more complicated but uh in some way but yeah anyway that protocol I would say I'm very confident is is probably secure um just because there's been like a lot of thought over years uh around like there's been you know different evolution of things like first like this SSF protocol and then

that kind of turned into this other this first version of 3SF. Um, a lot of these attacks that that I'm talking about, um, they really are attacks that are relevant to the current version of LMD ghost and how it relates to Casper FG. And I mean, they still point to there being, you know, many non-trivial uh, things that you need to keep in mind. Uh, but we have like a clear uh, view of how these attacks are resolved and like just why yeah, why basically there's there's no reason to to worry about them in the in the current protocol. And also besides that, it's not uh I'm not just saying that I'm confident that it's secure because we think that we've resolved these attacks. Like it's it's not just like a whack-a-ole kind of

thing, but actually we have like proofs of of security. And um I think the security proofs are actually very like it's actually a lot easier to think about it in terms of security proofs than in terms of uh the the original attacks. You can you can kind of just ignore all of the original attacks and just look at why the protocol is secure. And in some sense it's actually simpler though it's it's also nice to then go and and figure out like you know how did this uh like where does it show up that these attacks were actually resolved and and kind of we have both of the views I think um then yeah specifically about the protocol that I'm talking about now um this maybe I'm like slightly less confident about just because it's a bit more recent that we've like made some

simplifications which I think were necessary um for like implementation complexity reasons. Um I mean spec complexity just complexity in general. Um so there's some like relaxation of some things essentially compared to to what's in the paper. Um for example this uh last slide that I had about the two different uh mechanisms for choosing what a target is. Um but yeah I'm still quite like you know very sure that that this is uh kind of safe in all in all the well you know live and safe uh and so on. Um, I think it's it's it's more I guess that it's still an evolving process and like I think as we're we've been like more actively uh writing like a sort of

pseudo spec with with this simplified version of the protocol um and uh there's often little tweaks that we want to make uh because some something is just would be nicer uh to simplify it for like again implementation complexity reasons like u often it's something around what are we tracking in the state and like wanting to reduce that. And so, yeah, as we make this like little tweaks, then always there's a little bit of like lowering of of confidence. You need to like reconvince yourself that actually the tweak doesn't break any of the previous reasoning. Um, but I think yeah, overall it's it's not too bad.

Okay, got it. Um so like putting my optimistic hat on um for example Vitalik's new idea of the quad quadratic backoff because we have this mental model of what the attacks are and what security proofs are we can just adapt the proof to to to all the tweaks.

Justin Drake: Um I guess my other question is um do you feel like Vitalics implementation to the extent that you you've uh you know you only have limited knowledge of the details if you haven't looked at it carefully how how closely do you do you feel that matches your simplified version of 3SF?

Francesco D'Amato: Um, so at first it didn't, but then it was it was more of like a really simplified version of 3SF, but then like we we had some rounds of like I I looked at it at first and I kind of mentioned some of the things that were missing like Pmerge whatever and like as far as I can tell like all of the things that um that that we discussed. So I think right now it's quite like yeah like quite close. I I I I I haven't looked really like very in depth at uh I don't know, for example, this uh um target mechanism. I honestly don't remember if I'm pretty sure he does have the the fast confirmation thing. I don't remember if he has the the kind of other case of like resorting

to to the KD block. Um but yeah, I think most of it is actually what the the simplified kind of last version is.

Justin Drake: Okay, that that's great to hear that you've been uh working with him on this. Any further questions before we move on to Roberto?

3SF Finalization Time

Roberto Saltini: Okay, Roberto, the the floor is yours. Good. Thank you.

So what I want to start with is expanding on the actualization time of 3SF. as kind of Francisco with the with reference to the protocol that Francisco presented. The guarantee that we have in terms of finalization as a guarantee is that if you have two consecutive slots with honest proposals, the block proposed by the first proposal will be finalized within three slots.

Now the question is what is what if the sec the the second proposer is not honest. Well in this case actually thing things are not that bad. Um it's what what's going to happen is the guarantee that we have is that the block will be finalized three slots after the first pair of two two consecutive honest proposals. However, um we still have this guarantee that the block proposed by the honest proposal initially is not going to be a real out. So potentially if the second proposer is not honest, there is a potential delay in finanization compared

to this uh three slot. However, there are conditions like the one Franchesco mentioned before where the um the greatest is justified is not from the previous slot but from other slot where the the protocol Franchesco presented actually guarantees uh finalization in three slots even though the second proposal is not honest. Uh we uh as some people know we have written a theoretical paper and this theoretical paper actually uh present something that is uh that allows finalization of a block in three slots regardless of whether the second

proposer is honest. So we go from the first picture uh to the one at the bottom. Now problem with this theoretical protocol so we know how we can let's say get rid of this uh second requirement is that introduces a quite heavy change in how justifications are computed. First of all, we allowed to justify more than one checkpoint per block as you can see in the middle. And essentially now in this picture, the red red uh the red arrows are the FFG votes. And if you have a an FFG vote that kind of surrounds a block or a checkpoint, we

justify that checkpoint. I don't want to go into details because it's quite complicated and that's actually what I want to communicate with this slide is that there is a lot of complexity in this extended uh justification rule and so the question really is it worth it like is it worth to have this complexity uh to put time and effort also this this uh having to deal with more checkpoints is likely to require uh significant significant more data to be stored in the recon state. So there's a question here whether having this additional guarantee that um regardless whether the second

propos is honest to finalizing slot is worth is worth basically going down this route or not and again with protocol that just presented is not that if the second proposal is not honest then we don't finalize in three slots. we just don't have the guarantee that that that will happen. So this is a a question for the for the community or that would be nice to to get to get a feel about. Now I'm going to move into discussing some implementation consideration that come up when we consider the self regardless of which uh protocol the one that Franchesco

presented or this second one with a slide with a change in the justification rule. The first thing I want to talk about is about justification transferability and this is something we don't have today. uh this is because today the weight that this is that is associated to an FFG vote depends on the chain where it is included. So if you look at this example, we have an FFG v from checkpoint A to checkpoint BM and if it's including the first in the chain of block in if it is included in block E the weight is W1 if it's included in block G the weight can be different and this is because you you we use the balances at the at the point where the

vote is included and this creates problems. So the problem this this is creates is that because votes can have different weights based on where on the block where they're included. There are justifications that uh sorry there are checkpoints that can be justified on one branch but perhaps perhaps not on another. So if you look if you look at this example let's say let's say there is a checkpoint VM that is justified on the bottom chain but is not justifiable on the top chain. Now let's say that this block this point BM is actually the greatest justified. What we have to do?

We have to filter out the top branch because in the top branch we can't justify BM and therefore we can't continue in the branch. We'll never be able to justify anything new. Now the problem with this is that perhaps the top branch is the branch that LMD go has chosen based on the headboard is the actual the canonical chain. So what ends up happening is that actually this causes a real of the of the canonical chain which is clearly not not as as Luke has mentioned in the properties that we want. This is not something that we want at all. The solution to this is that is to make the weight associated with to an

FFG vote based on the chain or based on the target block. So in this case the idea is to make the weight based only on the target block B. So it doesn't matter where you include this uh this vote if you include it in E or if you include it in G it will always have the same weight associated to it. In this way we can transfer we can move justification from one chain to another and because of this we don't need to have that filtering mechanism that I kind of explained before that can cause potential reop now with with these techniques of course

uh we have an increase in data that we to keep track of because now we can't use the current balances when evaluating an FG world we need to go back to the balances according to the target block. So one solution is to introduce snapshots. So the idea the overall high level idea is that we take snapshot at given intervals like every 100 slots and what is going to happen if we have a FFG v one at the bottom where the target is block 150 we don't look at the balances in block B 150 but at the balances according to the snapshot just before in this case the one the snapshot S2 which

is uh which corresponds to the balances in block B this the the the advantage of this uh this solution is that we do reduce the amount of data that we need to keep track of in order to be able to process FD. Now of course we you reduce it but we do not uh cap it as potentially as the chain progresses the number of snapshots that we might we need to keep track of progresses as well. So one solution is to have a snapshot window.

Basically we we give a timeline after which uh snapshots expired and if you have an FF v that has a that requires an expire snapshot this FF vote is invalid. the pro the the advantage of this solution we have less information to store in the BON state but however we because of this let's say expiry we need this this introduces new opportunity for real in a way similar to the one I showed before that we get rid of by uh using the target to to to to determine the the weights this can

introduce new reorg opportunity. They're not that bad though because they actually happen only if the network is in is there is high latency or there is a synchrony and they have a lot of consecutive dishonest proposals. There is potentially another solution is that which is that if an FDG vote requires an expired snapshot then the proposer must provide a miracle based proof of the balance that um that needs to be used and we can do this because we have historical historical roots in the in the Bitcoin state. So this is something that can be done. The great thing about this is that it doesn't doesn't intro introduce new reorg opportunity but it it adds protocol complexity and also testing

complexity because now we have two different ways to um to create a justification. One that requires the proof, one that doesn't and the one that requires the proof is probably very rarely used. So if there is a bug, it will take long time to discover it and perhaps the bug comes out at the wrong time. And also there is an extra burden in creating this uh miracle proof if if the if the if the snapshot required is expired. Now connected to this uh uh this concept of uh uh the the snapshot window creating potential reorg opportunities. We also

thought about potentially having a introducing a max reorg depth. The idea here is that we have parameter D or max depth as you want to call it and whatever is before we are never going to revert it even though it's not finalized we never revert it. So as an example, let's say that you're in this situation where we have the greatest justified GJ and then we receive a new branch with a greater G with a greater justified checkpoint GJ prime because this is this should this is beyond the max depth. We are not going we if we introduce the

rule this rule we will not reoll from branch B to the branch where uh including GJ prom so which is what without the max depth we will do. Now the problem with this solution is that king in can create split views can create split views because it's possible that for example half of the validators were on the branch at the top and they don't reorg so they stay the branch at the top perhaps not half of the honest validators they so a prime first and so they're locked on that branch so we can get into this view where we we might be able we need to recover from it using uh social social recovery

So there's a question that you know there's a benefit we know that we can automatically reorg beyond a certain depth but then we do need this can create a a split view scenario where we do we need social recovery to to to to to recover. So there is a question whether this is something worth doing or or not. Next next topic we want to talk about very quickly is about inactivity less. So with CSF like today we want to ensure that the chain doesn't lose lose livveness even if more than one/3 of the validators go flying forever. So we do need in a way to leak inactive validate the stake uh if this updates so the funation can start again and uh I think

joy in the next presentation by joining is is connected to this. Next topic is about commit management which was uh mentioned before. So uh committee committee protocols like for example orbit are a way to uh allow to have a very large validator set but to contain the number of validator that that are actually voting in a given slot. So this introduces committees so subset to the the overall validator set and a way to move from one committee to the next. So the way we have think we thought about implementing such

committee uh rotation to committee change in the 3s protocol at high level is to change committee whenever that committee finalizes a block. So if you take a look at the picture at the bottom initially we have committee N then committee N finalizes block B. After delay K, we need this delay K to ensure that all honest validators can actually see this uh finalization. They all are all uh they all have the same view what the actual tenant active committee is.

So after this delay then the next committee committee M plus one uh starts. Then when committee M plus one finalizes a new block we move to committee M plus2 and so on. Now this is a very high level. There are a lot of details in in how to make this secure and we need to add additional dashing rule and overall say it adds a lot of complexity to the protocol. So it's something that I think from a theoretical level we are say quite confident can be done. But whether this can be implemented efficiently, uh

that's that's currently an open question.

Francesco D'Amato: Finally, I hand over to Francesco to cover this last slide. Um yeah, this is almost like a more of a um just quickly calling out this not open question, but just I guess something that it would be nice for for more people to to think about um and yeah, where there's maybe like expertise that's not necessarily ours. Um yeah, so the so rewards are are a bit tricky I think. um for for for a few reason, but um one particular one that's not obvious at first is that during normal

3SF Challenges about Rewards

Francesco D'Amato: operations there isn't like a a correct target, something that you can objectively say like this is the thing that people should be voting for. Um and this is essentially because fast confirmation uh is basically not not objective. This is something time independent. So different people could have seen different boots at different times and this could have led them to confirm something um different from each other. So even when you focus on a specific chain um you you can that chain cannot be sure of what is the right thing to to vote for. Whereas today uh from a chain perspective it's clear that uh there's a correct target there's a correct source. Uh in our case that that's that's not exactly the case. And

so one possible solution is uh to basically take justification as the only uh signal of something have been been done correctly at least as far as the the target. So only basically uh reward validators that actually contributed to to a justification. Um and one other good thing about this would be that it simplifies uh what what you need to track um in the in the state. And uh but then yeah but there's questions even if you did decide that okay this is the right thing to do. There's like questions around how do you do you want to do it? Um you could reward only the first justification or you could reward like anyone that contributes to justification. Um, for example, if you don't want to like um kind of uh make sure that you can still reward votes

that get included later so that I don't know you you don't uh create like ways to do discouragement attacks or basically just create like griefing uh vectors of of various kinds and uh but yeah all of these things also interact with implementation complexity and like you know what things you need to track track for for how many uh kind of ongoing justification during during periods of finality. So there's there's a lot of um it's definitely more complex than on the current chain because on the current chain there's only two possible uh targets at any given time. There's only like the current epoch and then previous epoch whereas here in principle there could be many possible justifications that are that are going on at the same time. And here also like there's something to think about with

how this intersect with Vitalik's backoff proposal because actually that in principle could simplify things. it could just reduce the space of things that we need to keep track of even if we do want to have a more um basically comprehensive way of of of tracking things and rewarding uh voters. And uh yeah, a little thing about this is that of course during the inactivity uh leak period the you you don't expect to have justifications and so there's you can't quite use this uh this rule uh to to reward people. Um but actually things get easier during the activity leak. Uh strangely because um we during the activity leak we can just say that we tell people not to vote based on that uh

on the this fast confirm uh target but to always choose the kind of safe uh uh conservative one like the for example the the K deep block. And so in that case there actually is an objective target. So where if you voted correctly for the head that also implies you've correctly voted for the target. So, so at least that part get gets easier. But yeah, this is more just like describing some almost like vague thoughts that that we've had about this. Um, and I feel like there's a lot to to think about here that that we haven't uh done at this point. And uh yeah, it would be definitely be great for I think Anders is on the call, people like you or I mean many other people uh that have expertise on this to to give this a thought at some point. And yeah, with

that I guess I'll leave you to to Yokohim.

Justin Drake: Any any questions for Roberto before we move to Yakim? I have one quick question. Um, by the way, I apologize for um kind of saying that your talk was about formal verification. It's actually not. It's about uh you know these practical considerations. I guess my question is um has the formal verification effort been postponed until we tie off all of these loose ends from a practical standpoint and um how do you feel in terms of timelines for uh closing off all of these these practical

considerations?

Roberto Saltini: Yeah. So formal verification has yeah that has been postponed in we sort out these things basically to the point where we have a spec that we are happy with and that we think is um has addressed most of the if not all of the concerns um terms of timeline that's that's a difficult question I might take the fifth amendment to this one. Uh I don't know like it's it's hard to say. I don't know. I say to we are working through some

optimization at the moment. were beating manual proofs uh say few months say 3 months I don't know I hate to give a time but yeah Francesco Luka feel free please feel free to jump in and yeah if you have different opinion

Francesco D'Amato: does Vitalik's implementation have a lot of these uh loose ends on Uh I haven't taken close look at it. I don't think it has uh but um I don't think so. Um

I think on the on the tracking of things which like uh is one of the things that we're generally trying to figure out the the the best way to do and like that ends up usually causing u that or like is one of the things that has caused some of these like needing to tweak things or like wanting to to tweak things. Um I think maybe if I remember correctly uh Vitalik's implementation is simple in the sense that I think it's just tracking all the the things that it could be tracking like all the all the checkpoints. Um and so yeah I I don't know if it has the the snapshot or like these other kind of logic that Roberto was was talking about but I I should double check. Um but yeah, I think that's that's the like

area that um where I think like uh um some some decisions should be should be made uh at some point soon and other than that I think yeah more like um things are not so like things like on top like rewards and and so on are are a bit more up in the air but but also they end up kind of feeding back into the uh into into how the protocol is structured. So it's there's yeah if sometimes it feels like okay the protocol is done but then like something that you build on top requires you to make changes to it. So that's where we're at I guess.

Justin Drake: Okay. Got it. Thank you. Uh Jim uh the floor is yours. Thank you. One sec.

Accountable Liveness

Okay, everybody sees my screen. Yes. Perfect. Uh, thanks for having me. Uh, good to meet you all. Um, I'm going to be talking about a new paper of ours titled Accountable Liveness. This is joint work with Andy Lewispai, with Tim Ruffgarden uh and with Luca Zandolini who spoke earlier. And if you're interested to know more, I highly

encourage you to check out the paper. It's on e-rint on this link. I will also have that in the end. And uh the introduction is about like three pages uh and fairly self-contained. Uh explains kind of the intuition of what I'm about to to tell you. And so I very much encourage you to to go check that out. Uh before I start, I have to give you important disclaimers. uh none of which what I'm about to say is financial advice only for it's only for academic andformational purposes. Um so here's the thing right so if we think about accountability for blockchain consensus um there's a soft problem which is if a blockchain suffers a double spend who is to blame uh the answer is for PBFT style protocols and that captures things like

tender mint or Casper FFG like what we what we have on Ethereum roughly the answer is nodes that have voted for two inconsistent blocks and that's what we use in Ethereum uh for the slashing mechanism um here's an unsolved If a blockchain stalls, who is to blame? In Ethereum, we have a mechanism for something like this, the anactivity leak. Um, which, uh, is however only a huristic. Um, and in this work, um, we give a description sort of of the security property we would want to have of a mechanism like this. Um, we call that accountable livveness. Um, and we sort of develop the foundations of of that concept. So we explore when is it

possible and in particular also when it is when is it not possible uh to achieve uh accountable livveness and how can you do it using what protocol techniques. Um so here's my uh 202 consensus slide. Um, atomic broadcast consensus is about the following, right? We have transactions that get input to our n uh validators uh that run the protocol or nodes. Um, and these nodes then output logs and and the job of the blockchain really is uh to produce an ordering uh of the transactions um on chain. Um, this problem is hard because the network is not perfect. Um, there's message delay whenever validator sent

each other messages. And for the purposes of this talk, I'm mostly interested in something called partial synchrony. Uh if you haven't heard about this, um it's not that important. If you have heard about it, remember there's this global stabilization time and there's a delay upper bound delta that holds after sort of the period of network asynchronous over. And the problem is also hard because we have to make the assumption that a certain um number f of our nodes is malicious. And in this setting um we want to design a protocol which is essentially an ordering protocol that has two security properties. One is called safety which basically says uh if the adversary is not too strong like for example the adversary is less than a third of all

the nodes um then for every two nodes p and p prime and every two uh points in time t and t prime the logs are basically consistent. So either one is a prefix of the other or vice versa. That's one important property. And the other important property you may have also heard of is is called livveness which is if the adversary is not too strong then for every transaction and every node um you know shortly after like for every point in time shortly after this transaction was submitted to the chain and we've given the protocol time to to confirm this transaction that transaction should actually be in the output log of every honest node. And accountable safety uh is a strengthening of this safety

property sort of turning the argument around and saying okay you know what happens if the adversary is stronger than this uh than this resilience of of n of n over three right and accountable safety um gives the foundation for like cryptoeconomic security and it basically turns the argument around and says okay I you know I want the following property suppose it's not the case um that everybody always has consistent output logs in other words there is some inconsistency then I want to be able to provably identify uh a certain fraction of nodes as Byzantine.

Um and this is sort of the you know the state of affairs uh up until now. And in some sense what we are doing um and that's where the name accountable livveness comes from is we're trying to do sort of the the same trick uh to the livveness property. Right? We want to turn this argument here around and say suppose it's the case that a transaction is not confirmed within time then we can provably identify a bunch of Byzantine nodes. And we'll have to revisit sort of what what number it is whether it's n over three but uh you know that that's sort of the gist right so for accountable safety and this has been studied um you know comprehensively in the last 10 years basically um going back to to

2007209 are the earliest papers I'm aware of um accountable safety is is this property that when there is a safety violation we want to have a smoking gun implicating Byzantine notes right Um it's important to keep in mind right the non-trivial regime here is when the adversary is stronger than n over3 because otherwise we have the safety property right this is just the strengthening of the safety property. So if the adversary is less than n over 3 we have the safety property anyway so there are no safety violations. So then accountability is sort of trivial. So interesting here is when f is greater than n over 3. Um and the way we get accountable safety is um roughly right through some sort of a blaming function where if you're given message histories

of two honest nodes with inconsistent output logs then you're able to identify a large set of Byzantine nodes. And how do you do that? Intuitively you output nodes that you that you're catching voting inconsistently. And it's important and this is preserved by this mechanism that no honest node should ever be falsely accused. Um and and you want to make sure that you you know whenever there is a safety violation you can actually identify Byzantine nodes and you can then go and remove them or slash them uh or whatever. Right? The the question of how you actually affect slashing um and and actually make it happen and and sort of uh clean up the validator set and and kind of recover from a from a um from a validator set that has less adversaries

is outside the scope of what I'm talking about here. But if you want to know more, there's um two recent papers um by uh Lewis Pi and Ruff Garden um where you can learn more. So for accountable livess, we want something similar, right? We want if there's a livveness violation, there should be a smoking gun implicating honest nodes. Again, the non-trivial regime is if the adversary is greater than n over three because otherwise there are no livveness violations to begin with. Um and we'll try to sort of our goal will be to to base this on something similar to this blaming function, right? Where if you're given message histories of you know at least all the honest nodes um then you want to be able to output a large set of

Byzantine nodes. So the idea here is um right again we want the property that honest nodes should never be falsely accused and byzantine nodes should be uh identified uh when whenever there's aliveness violation so that we can remove or slash or leak them whatever you want to call it and intuitively here um sort of we we have to change how this blaming function works. The idea is we want to output nodes that we that we catch not voting for blocks that they should have voted for. That's kind of the the intuition. Um the TLDDR of this property is that accountable livveness is harder to achieve than accountable safety. Um why is that so? Well, you you may guess

that that is so because in some sense for accountable livveness you need to prove the absence of messages that the node was supposed to send. absence of expected messages rather than the presence of unexpected sort of uh you know too many or inconsistent messages. Um but you know an unreliable network by itself may be to blame for liveness violations and not Byzantine nodes. Uh that's in contrast to uh safety violations right? uh safety violations come from conflicting votes that are signed by the same node and and no matter what the network does at least that node should have had uh uh you know should be self-consistent with with the honest protocol and the other the other aspect of this is that um you know we somehow

then have to rely on like uh you know bringing honest like bringing the views together and sort of figuring out who saw what at what point in time in order to blame people and and find out who who is actually guilty. Um and because of that process, Byzantine nodes can can be uh can frame honest nodes, which is also not the case in in accountable safety. Um where you know vote where the conviction is basically based on signed votes and and nobody can forge those. Okay, so that's roughly intuition at this point, but we can make that precise, right? Accountable safety has uh two uh very good properties, right?

One is that it can be added to optimally resilient partially synchronous protocols without any new assumptions. For example, on message delays. Whereas for accountable livess, we prove this theorem in the paper that no optimally resilient protocol can be accountably live if the network is in some intuitive sense more often asynchronous than synchronous. Uh and in particular then also not under partial synchrony. And what exactly this uh you know more often asynchronous than synchronous means um that has a technical definition to make all of this precise to get an actual theorem which you can check out in the paper. But you know the intu the intuition is that over prolonged periods of time sort of if the network is more often asynchronous than synchronous um

then you cannot get accountable liveness. So that sort of justifies this intuition of unreliable network maybe to blame for livveness violations. And so if the network is just too bad then uh there isn't that much hope. Um and then the other nice property about accountable safety is that it can be provided no matter how many nodes are Byzantine, right? Even if almost everybody is Byzantine, the adversary cannot evade um being held to account. Um whereas in the case of accountable livveness we prove a second theorem which is that no protocol can simultaneously provide safety under partial synchrony even you know if there's basically no adversary um and accountable livveness um when sort of the majority of the nodes is is

adversarial even if the network is synchronous and that sort of you know is a is sort of a formal natty version of the statement that Byzantine nodes can frame honest nodes and um Yeah, based on that you may expect uh this accountable liveness to not work under dishonest majority. So it's actually true that accountable livveness is harder than accountable safety. Um so given those two impossibility results, what's kind of the coolest thing that we could possibly hope for? Well, we know that there's not much hope um to get accountable aliveness for f greater than n /3 if we are in minority synchronous executions or for f greater than n /2 um even if there is synchrony right and the

problem is vacuous if we only consider f less than n /3 in sort of majority synchronous executions. So the best we can sort of hope to achieve is that we can get accountable livveness if s f is less than uh n /2. So if we are majority honest and we are under majority synchronous executions and the main result of the paper is that this is in fact the case. So we have a protocol that uh that that has this property. Um more precisely the main result of the paper is that we can augment uh a protocol like tenderment but the same construction applies to things like FFG um in such a way that as usual if f is less than n /3 we get a

save and live protocol under partial synchrony and we add an additional functionality which is as long as f is less than n /2 then we can get accountable livveness in majority synchronous executions. Um I will try and give you sort of a highlevel idea of how this protocol works. Um it it's you know I make a bunch of simplifications. You can find the full version uh in the paper. Um but yeah we'll see how it goes. Um so we start from a protocol like tenderint.

Recall in tenderint we have um you know views like the the protocol proceeds through um a sequence of views and every view has the same structure. uh this is similar to these phases that uh Franchesco was talking about earlier. At the beginning all validators sort of send their latest state to the leader of this view. The leader then makes a proposal and then we have two rounds of voting um until we eventually reach confirmation. That's the idea of of tenderment. And um in order to make tenderment accountably live, we add logic to each view. Namely, we make all the nodes rebroad rebroadcast all the messages that they've received and monitor messages that they see as being

sent by other uh nodes. And if a node P observes that a node Q has failed to send a certain message, think in particular a vote that it should have sent under the assumption of synchrony, then we say P blames Q in that view V. And then eventually if there is a livveness violation for example nodes exchange information about who uh blamed whom and and at what point in time and then we do some sort of accounting of all of this blame um in order to figure out um who is uh actually guilty who we actually want to hold accountable for this. So remember uh you know there are a bunch of reasons why tender why a

tenderment view may fail to confirm a transaction. It could be because of asynchrony. It could be because there are just a bunch of Byzantine nodes not voting basically for the proposal or there could be some like bunny shenanigans like a Byzantine leader. But I want to make it a little uh simpler. We we have a technique in the paper to sort of extend it to all those cases. But for now, let's ignore three, right? And let's focus on uh sort of these two options, right? Either we're in the asynchrony or we are under synchrony but somehow there is still no confirmed transaction. um we're under synchrony and we have an honest leader um and for some reason there's still no confirmed transaction then this must be because somebody has been withholding votes right so suppose tenderment fails

to confirm transactions either we're in a synchronous view this happens more often than asynchrony um now it's interesting in a synchronous view we can the protocol is built in such a way that honest nodes do not blame each other right they basically always know there's an honest leader all the honest nodes will will vote for the proposal of the leader. So nobody is sort of missing a message and so nobody no honest node blames uh any other honest node. Um but if we don't get confirmation right there there's there's n over3 votes sort of missing right and because these votes are missing uh there you know all honest nodes will detect that that they have not been sent and they will be uh they will be blaming uh

n over threeyzantine nodes by all the sort of majority uh like by all the honest nodes right which is the majority so those nodes are majority blamed if we're in an asynchronous view then all bets are off. But luckily that uh that happens much less like that happens less often than synchrony because we've made the assumption that we are in majority honest executions uh sorry majority synchronous executions. Okay, good. Um now how do we how do we determine who is guilty? The idea is that um after we bring together all these uh uh you know we we do like a collective blame accounting and we exchange um our views about sort of who

we have seen not like send votes in time and so forth. Um we go and try and find a node uh as guilty that is majority blamed in a majority of views. Okay. So a node will definitely be guilty if it's majority blamed in a majority of views. Why is that so? Well, um, here's some good news about this, right? No honest node will ever be found guilty because we said that no honest node will be blamed by other honest nodes in all the synchronous views. The synchronous views are the majority and the honest nodes are the majority, right? So, there cannot be an honest node that is majority blamed in majority of views.

The problem with, you know, just this idea is that you're not guaranteed that there is any one Byzantine node that actually falls under this condition, right? So we're we're not sure that we can actually there's actually anybody that we'll be finding guilty with this mechanism. But there is you know an extension basically of this intuition. This intuition um you know holds like roughly morally right. Um there is a a way to sort of restrict the views over which we apply this rule in a carefully to a carefully selected subset of views for which we can then give a cute combinatorial argument to guarantee that the nodes are found guilty. And the argument is really pretty simple. We just don't have time here to talk about

it, but I encourage you to check it check it out in the paper. It's right in the introduction. Uh so yeah, so that's how we get that main result, right? We can augment protocols like tenderint so that they have the typical properties of partially synchronous protocols but also the additional functionality um of giving us accountable livveness in majority synchronous uh execution. Um so I'll summarize. Um we've talked about the definition of accountable livveness. Um we've shown these two results that um you cannot get accountable livveness when f is greater than n /2 even under synchrony and you cannot get accountable livveness if f is great greater than n /3 in as long as you have to deal with minority synchronous executions. On the

flip side sort of we have shown the achievability which is that in majority synchronous executions when the adversary is less than uh uh less than half of the validators you can actually get accountable livveness and we can modify any number of standard protocols to achieve this. the protocol that we have I would you know consider it a proof of concept definitely you know it's a cute protocol uh it works um but definitely much more R&D is needed to sort of streamline it improve its efficiency kind of dock it into uh into the the the protocols that we would actually be running um but uh I I think yeah the the the the goal here is to to kind of provide the the the framework within which we can sort of reason about

mechanisms like inactivity leak One thing we haven't talked about uh but I've briefly mentioned it on on the second slide is uh this question of okay if there is a livveness violation and we go and identify malicious parties how many um Byzantine nodes can we actually find guilty whenever there is a livveness violation. Um and in the paper we have uh upper and lower bounds sort of u you know we show that what is sort of the identification budget of our protocol and we also show um certain bounds on what you know no other protocol can sort of do better than that and there is a small little gap between the two um so yeah I encourage you to check that out it's figure one in the

paper and this is the link to the paper and with that uh I thank you and I'm open to questions

Justin Drake: Thank you, Draim. Uh, any questions from audience? One, I'll kick it off with with one question. Um, I guess the the construction that you're suggesting involves quite a bit of of infrastructure in addition to what we already have. Is there some sort of small diff to the current logic that we have with the inactivity leak which would improve the status quo without bringing in all of this uh this machinery uh into consensus?

Yeah, I would say um we don't know that at the moment like I I don't have a protocol like this in mind but also we haven't spent uh much cycles on this yet. So far we've mostly been interested in uh you know is this possible at all? What does it mean to like do this successfully from like a security perspective from like a properties perspective? Um how to sort of dock that uh kind of into the uh like Ethereum's protocol specifically. Um that's uh still at the very beginning. We we plan to continue working on that and and plan to sort of uh you know write a follow-up that sort of looks much more into these kind of efficiency questions and in questions like you know how much how much information do you actually need uh

to identify and and leak these parties and um you know we have certain information sort of uh on the beacon chain things like you know we we count all the votes there so you know we know which votes are reported there or not. Um so um yeah it's unclear at this point.

Justin Drake: I guess another question that I have is um accountable aliveness is not achievable as shown in the slide in situations two and three. Can these situations be you know programmatically detected so that we don't um penalized uh honest participants?

Um no um yes no um that that that is that is a challenge. Yes. Um basically uh yeah like the moment uh you know the the chain becomes sort of u dominated by a majority uh uh adversary right like u you yeah you know they they can go around and if if if they're really smart and they sort of launch the best attack um then um you know you rely on sort of additional synchrony assumption of like other people sort of uh watching the network um and and sort of knowing what's true, right? But um sort of within kind of this the the

definition of like what accountable liveness is which is you know you produce these sort of certificates this kind of cryptographic evidence with which you can convince other people. uh we need to make these two assumptions and uh you know if somebody shows you uh such evidence uh then you can never you can't be sure you know whether you know that was produced sort of uh honestly or you know maybe one of these properties was sort of broken and and that has then allowed this forgery of the cryptographic evidence. Uh got it Terrence.

Terence Tsao: Yeah. So I think today if I if I remember correctly which I could be wrong right today in Ethereum if you miss proposing a block you don't

really get a penalty for that and and I think in the context of inactivity d it only covers attestations it doesn't cover block so in this case in your I guess in your model are you looking at both the block as a message and attestation as a message or just the distation I guess the question is that what message are are we publishing here?

Um for for for the purposes of uh of the protocol that we have, right? Um it's primarily about the votes. Um the votes in some sense are um uh they're the uh I think they're the more fundamental thing

with which the adversary can sort of prevent livveness, right? like you know the adversary proposers can just not propose blocks right then maybe you should still have some sort of a mechanism to go after them uh that's good but that is not sort of a that that doesn't you know that doesn't solve the problem all the way in some sense right that that's basically on a huristic level the hard part is really you know what happens if you have honest proposers and they do produce blogs and nobody votes for them right because if you know if it the the adversary proposers, they're an annoyance. They're not great. You should punish them if they don't produce a block, but they can sort of halt progress sort of indefinitely because quite frequently

there will be honest proposers, right? And so if you if the adversary wants to hold back progress indefinitely, it needs to sort of stop the honest proposals from going through. And the honest proposals are um you know, it can only hold them up by not voting basically. So for the purposes of like this this kind of uh you know strong notion of like uh punishing kind of lightness violations that is sort of the critical part not not kind of the missing proposal. I think the other aspect to this is perhaps that uh you know the way you could see it see it is that um an an adversary proposal can always just propose an empty block right so just the fact that like the fact that there that there are blocks right is not enough to give you liveness right and so

it's hard to you know right now we wouldn't punish them for proposing like an empty block or a block that sort of misses transactions that we think should have been there or something like that right so this kind of yeah slashing or or like punishing the proposer I think of as a shuristic. The the sort of really fundamental problem is uh what do you do with the adversary if it keeps not voting for legitimate proposals made by honest parties.

Justin Drake: Okay. Uh we're past the 1 hour and a half. We're about uh 15 minutes over. I'd like to thank all of the speakers again and um yeah, congratulations for making through uh

almost two hours of uh of beam call and yeah, the next call will be on on rainbow rainbow staking. Thank you so much everyone. Have a great day. Bye.

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.