Fast Finality update

Transcript

[music] U great to see great to you all here and many familiar faces. Um I would like to talk to you about uh decoupled consensus which is uh an idea that more or less almost exactly a year ago became the kind of default understood path for bringing a faster finality to to Ethereum. But a year um a year ago it was just an idea more or less. was uh you know something that you could maybe write in a blog post. Since then there's been a lot of uh real progress and u we actually have like um we've gone quite a bit further and we we're um on on the way to trying to get this domainet. I would like to tell you a bit about what

the process was like um what kind of problems we we had to solve along the way and how and then yeah where basically where we are and where we're going. Um so yeah the kind of title is like from an idea to a formally verified protocol cuz spoiler that's kind of the the current state of things. So uh first of all let's start with what even is the the problem in a sense. So we we have a consensus protocol that's obviously pretty uh crucial part of of a blockchain. There's a few things that we want from it. There's actually a lot of things that we want from it but there's really three like highle um problems um that we we we would like to improve. uh one is we would like to have a provably secure and optimal protocol. So we would like to have a a protocol that has like

proval properties um and that is kind of bestin-class where you can you can say that you you can say that whichever for example adversarial it tolerates that's the best that you can do. Um and uh we would like to have much faster finality than we do today. Today it's about 13 minutes or so. We would like it to be uh you know a few minutes eventually seconds and then we would like it to be postquantum. So there is BLS signatures which are not postquantum. We would like to get rid of those. You might have heard about mission 2028. So that kind of fits in in that whole picture. And uh so uh on the on the first problem what is the status quo? The status quo is the consensus protocol of Ethereum is called Gasper. Um it's a basically a fusion of two parts. One is Casper FFG, the other

one is LMD ghost. Um, basically there's this kind of two modules. One is this finality gadget that that tries to like finalize things and give uh economic security. So give this guarantee that uh in order to have um if there is a double spend there's going to be slashing. And then there's an available chain that tries to make sure that we always kind of make progress and keep producing blocks basically no matter what. even if like a lot of parties are offline or kind of in really the worst cases that we can imagine. And uh yeah, and overall the picture looks like this. You have this kind of finalized chain and and then you have like this suffix that just continues growing even if we're not making finality progress.

Uh now there's a few issues with the the current protocol um that are kind of have been well known for years. Um in particular, two kind of parts of this are are a bit um sketchy. So the the available chain part uh which today is LMD ghost for years we've kind of known that there's some attacks these attacks are not um you know not something that can like bring down the network or anything un otherwise of course we would have made it a priority to fix them years ago but they basically weaken the security of the protocol in ways that um essentially make it hard to really prove that it's secure under like the kind of standard models that people use for for proving uh that protocol consensus protocols are secure. Um and the other thing is like prevent this optimal kind

of property that we would like. So they make it so that um we know for sure that the protocol does not have the optimal resilience that it could have. So um under certain conditions um you know bad things can happen that should not be possible uh or like it does not tolerate adversaries that are as uh powerful as as it could in theory. And then the other part is there is this kind of all interaction between these two boxes. Um so actually the the box on the left the final gadget in a way it works very well like it's it's fine you know we it has the right properties essentially um it's really more just the box on the right and the interaction. So uh the way that these kind of two boxes talk to each other um the the way that the finality gadget interferes with the

available chain and the way that the available chain communicates things to that to the finality gadget to be finalized. Um, this has kind of a a long history as well of like uh patches in the specs and kind of many like um you know a bit of like whack-a-ole with like oh let's try to fix this in this way and and so on. This has actually been stable for a few years. So now I think we we understand quite well what the current state is but we also know that there's some fundamental limitations where like we actually need a redesign. We cannot really improve it further just by like you know mcking around with the with the protocol.

Um another problem is uh or you know goal is is fast finality. Um and uh so again what is the status quo? The status quo is this top bar uh that where we basically have um this long period where we we vote uh for um trying to finalize things that we call epochs. And um we kind of spread out the votes over this epoch where the votes are kind of accumulated slot by slot. So there's like uh 32 slots in an epoch. in every slot a subset of the validator set votes which today is like about 30,000 validators or a bit less so still quite large um and so yeah we have all of these votes that kind of come in in every slot and this is how the two protocols kind of um like these votes work for both of the protocols both for

finality gadget and for the available chain and um yeah you could think okay what would be the the if we just keep things as they are how do we make finality faster well we would like to basically shorten the epoch uh but what happens when when we shorten the epox if we just kind of stick with today's protocol. Well, we get something like the the bottom part of the picture. So, imagine that for example, we made epox four times smaller. So, we kind of try to pack everything into eight slots. Well, now every slot is going to have four times as many as many votes. Um, and so this has, you know, consequences.

We need to actually be able to deal with so many votes into each each slot each slot. We might need to increase the slot time, for example. Um or we might need to really like work hard to optimize the the networking. Um and then you know you could think of the extreme case where like we're really trying to like uh make epoch as short as possible, make finality as short as possible. We pack everything into one slot. So the whole validator set votes into one slot. Um this is of course difficult when there is uh 800,000 validators. And uh yeah, basically you can see that there's a bit of a trade-off. Now the slots will become like potentially very long or like compared to today. Um so there's a bit of this trade-off where um we could have faster finality but then we would have to have slower blocks or vice

versa. Um and we cannot really like independently try to optimize the the two things. Uh now problem three is that we would like to have a postquantum consensus layer. So we would like to essentially get rid of BLS and put in place um cryptographic primitives that are hashbased and and postquantum and you people are now start starting to also talk about post AI. um that's a bit you know less of a um the claim is less clear there but there there's at least some let's say plausibly post AAI um story there and uh yeah so what what is the problem there u we we actually have the primitives so the a lot of this work has actually been done um thanks to to um lots of people at DF working on this

for for years um but the issue is still there's kind of some fundamental um trade-offs that we would have to accept if we try to just swap in these primitives in the current protocol Um the main thing is the BLS signatures are actually very small and they also um and and once you aggregate them they stay in the same size. So it's like 96 bytes and aggregate is also 96 bytes. Um and also aggregating them is kind is fairly cheap. Uh on the other end once we swap in this hashbased signatures they become much larger. So a signature is uh 3 kilobytes so 30 times larger. An aggregate is 300 kilobytes or so. So like another 100 times larger. So you can see you know we would start with much larger signatures we then aggregate

them we have even larger aggregates um and also then there is kind of this actual aggregation work like this like you know CPU or or GPU uh work that would be in this in this kind of aggregation pipeline um this would be much heavier than it is for BLS and so you try to cram everything into the slot um it's it's not that it cannot work but it would definitely be like much more challenging it would really you know stress things u into the slot so ideally we would not need to do this and so what is the solution? Well, a solution that has been brought last year is let's actually just decouple things.

You know, we had these two boxes um this available chain and this finality gadget. Um do they need to kind of work together in this like tightly coupled way? They actually don't. So maybe we could just uh decouple them and have them be uh kind of on their own timeline. Um so for example on the slot side also on the block production side we could have very small committee um that yeah would be like maybe wouldn't need aggregation or anyway it would be quite small so it would be much easier to fit into the the slot timelines. We could have even shorter slots potentially. Um and on the finality gadget side where we have this kind of whole big validator set that's that's voting. Um we could just uh have that completely decoupled from slots happening on its own timeline taking as

long as it needs. um and also being able to kind of optimize it independently of these kind of slot deadlines. And so yeah, basically we we try to remove this trade-off of like finality and and and slot time having something to do with each other. Now, uh what what actual benefits do we do we get from this? Like what what what concretely how do we visualize the benefits of decoupling? Well, so let's look at the couple. Um basically, let's look at the status quo. So the the top one is what it what we have in today's protocol. Um everything happens kind of together. So in every slot we have these like let's say 30,000 votes or or whatever the amount is um and they need to be uh they need to be sent they need to be aggregated there's a lot of them there's a lot of aggregates um and this

kind of h and then there's some dead time so for example when the block comes there's no votes happening um so because we're coupling everything together with the slot there's some inefficiencies that arise um and the slot also has to suffer from having to kind of accommodate all of these all of this activity happening on its own uh deadlines. Uh now once we decouple um we can look at the the top bar the the yellow one um on the slot size side um we have just a few validators voting so we can conceivably kind of cut a bunch of the slot the the aggregation part um and we can just kind of leave that um to this small committee um on the um finic gadget timeline. So in this timeline where we want to aggregate the whole

validator set um we could actually do it in um much kind of less constrained ways than we could uh with the uh with a couple protocol. So we can really be as creative as we want in optimizing uh this uh this process. So for example here what I'm I'm showing in the in the bottom row is um we could just try for example to keep things more or less as they are today but pipeline it. Um so I mean one thing that you notice is there's no dead times. there's always some work that that's happening and also we can kind of pipeline this work. Um so we kind of cut a bunch of inefficiencies that we just cannot cut in the in the top bar. Um and then just as an example this is not it doesn't have to look like this. It could look in many other ways.

The the for example it could look like uh everyone votes and then we have this like bigger aggregation three that goes on for a while. Um the point is we basically have the freedom to just optimize uh the the bottom part completely independently from the top part which is of course um how you can actually get to like something optimal or or anyway uh much more optimized than today. And uh so there there there's um this decoupling is not just for faster finality it also simplifies a lot the PQ story. So if you remember there is this larger signatures now we can actually uh visualize them there. So again BLS 96 kilobytes um hashbase sig um is um basically 30 times that 3 kilobytes more or less uh and then u aggregate of of

those is another 100x so we're really talking kind of uh you know big numbers that we need to like fit into what we're doing it's not fully really like a drop in replacement once the replacement has such different characteristics and and there's also the the CPU part that that's not shown here. Um so what would it look like with decoupling? Well, on the available chain side, so on the kind of block production side, the stuff that we need to cram into the the slot and which ideally we would like moving fast. Um, we can have a very small committee. So, we can have for example 500 validators. These are the numbers that have been kind of going around for a few years. Um, this would be only 1.5 um megabytes per slot. So, not not so much to to go around. And potentially the proposer can be the only one that

aggregates. So, there does not have to be like a multi-layer aggregation structure there. um whereas to today even with BLS we still do have this kind of multi-layer aggregation process and so and yeah and actually uh while this aggregation uh path is quite a bit heavier than BLS it's still very much doable uh by by individual nodes so we could have something that looks like this on the finality gadget side um again we have this ability to pipeline um so we could this kind of looks very much like what we what we showed before except now the signatures are um much larger so we still need to accommodate for that um but we have basically the ability to like stretch out the timelines to pipeline things um and not only pipeline in the sense of uh for

example voting um and propagation of votes and propagation of aggregates but we also have the ability to pipeline the CPU work um so it's not all you know happening at the end it can happen throughout like we can send uh send votes uh start aggregating them have that CPU work happen while other votes are being propagated um so again it basically really gives us a lot more flexibility um to uh play around with the timelines, play around with the how we structure things um and actually both fit uh this new overhead of that comes from PQ while also ideally not not compromising on performance. So not uh you know needing to increase finality time and actually potentially shorting it shorting it. Um now what is actually so yeah up to here

we've kind of talked about the goals um and uh you know a bit the problems and how decoupled consensus a bit help helps with that. Um just quickly um you know we we can look at also like what actually does a decoupled consensus protocol look like um in in the actual consensus protocol machinery. Well it actually looks very much like what Gasper does today if you really like squint and just look it from you know from very far. So it still has these two same boxes of finality gadget available chain um and this interaction between them. It still produces a finalized chain and an available suffix. The main difference basically is um the finality gadget is now uh quite you know essentially completely redesigned to fit

this this new protocol. Um it's a variant of simplex. So it's a quite well-known protocol. It's used in a bunch of places. We we understand it quite well. uh the available chain it would be a variant of a protocol called goldfish that we worked on years ago also quite well understood um and yeah the I don't want to get too much into details of the protocol but um basically the I guess the the key point there is like the components are well understood built on established foundations and then the kind of um the trick is actually putting them together which is is very much non-trivial um you kind of see why but putting them together in the right way and this is what we've basically been doing for for the last here figuring out how to do this in the in the right way. So, uh yeah, what is

actually difficult then about putting all this together? Well, what's difficult is we have a ton of properties that we actually want from this. Um we want the finality gadget to have a whole bunch of properties. We want the available chain to have a whole bunch of properties. This is more than most blockchains ask of their consensus protocols. Most blockchains, for example, don't need to stay live no matter what. Usually if uh um twothirds of the validator set uh if there's less than two-thirds of the validator set online, they just stall. Ethereum does not do that today and wants to keep not doing that in the future. Um so yeah, I won't go into through all the properties, but this is even like a very much non-exhaustive list of of properties and already some here you just won't find in basically almost any other uh blockchain. And now so this is

kind of the easy mode. Uh again, very much non-exhaustive property. Uh now this is still not exhaustive uh but maybe gives you like a bit of a better look into like what actually is the the complexity of coming up with a protocol like this. So this is on the left is the list of properties that are currently proven in in lean. Um there's actually more but this kind of the core of properties that really like in a way define the protocol being correct. There's a whole bunch of them again I won't go into it. Some of them have to do with finality. Some of them have to do with the available chain uh safety, livveness, behavior under specific cases like uh boundary synchrony. There's really a lot and on the top you find the assumptions. So the different kind of regimes under which the protocol can

operate. Um some of it is low participation, some of it is high participation uh but potentially having asynchrony before. Some of it is boundary synchrony. There's really a lot and combined you have this cool kind of matrix of results holding under certain assumptions um that are currently proven in lean and uh now how we actually you know how how have we managed to to navigate this complexity um well the first half of the year um did have some some help with AI so it really I mean 2026 has been this year where you know we've all tried to adopt uh AI into our workflows and have been trying to like play around and figure out how to do it in the first of half of the year this was kind of working. It was very helpful in some ways. It would allow you to

iterate faster. It would like generate ideas. Uh it would let you explore paths faster, uh write specs and proofs faster, but it had a lot of limitations. Um it would produce a lot of slop. Um it would be hard to share with co-workers. Like you'd have just these mountains of like slop proofs um that you really, you know, could try to to get AI to like verify and verify and verify, but you could never quite convince yourself that everything was fine. And if you wanted to to share it with a coworker, it was kind of hell. You had to really just like, you know, wait through pages and pages of slop and try to figure out how you're going to actually um go to someone and say, "Hey, take a look at this." So, it was it was okay. It did it did quite a bit, but it really was like

almost it was it was a pain to work with it. Now, in the in the second half of the year, because 2026 has uh moved really fast, and you you could really do this for like maybe every 3 weeks actually, you should break down what were the changes based on which models were available. Um but formal verification really became like a a key part of protocol design. Um so over the last few years um oh and yeah sorry actually this this is still first half like in the first half formal verification was there but still very partial. It was really kind of you would maybe uh take some proofs that you had already try to formally verify them get something but still limited results uh not so useful. In the second half we've kind of moved to formal verification really being like a integral part of the

design loop. So where basically uh what a researcher might do is like uh come up with ideas, come up with a design, then uh throw it to models, have that design end up in a in a lean model that you try to maintain and then you iterate by having basically when when whenever you iterate uh you also iterate on the lean model. Um and so you can quickly say um this change is correct or this is exactly what breaks. I have to go back and figure out uh you know why did this break and and kind of go back to the design loop. So this has actually really really helped the process. Um you introduce verifiability, you let the models just kind of work much more autonomously and you can actually be convinced that things work without having to check so much yourself and uh yeah I mean basically this has

led to this kind of process where the spec evolves with the the design. So we have this like um lean spec um for for the consensus protocol. Whenever you want to make a change um you basically um make a change to the spec. Maybe it leads to like a new property that you want to prove. Maybe sometimes you figure out that this property does not work and you have to make some changes. Um and yeah, it really has made this process much easier. You can uh sometimes in hours figure out if something is wrong or if you have to uh basically make adjustments. And um yeah, I kind of [snorts] getting running out of time. So let me just show you uh here on the right u the current state is we have a basically um full lean model of the the consensus protocol. Um, and that

that's fully formally verified. Um, the outer ring there is the proofs. So there's all of this stuff that you don't actually need to read. It's very large, but you don't have to care about the the lean kernel checks that. Um, inside we have this kind of trusted code base um that actually defines correctness. This is actually fairly small like a human can deal with this. And yeah, I mean this is what the kind of overall uh how you can visualize the the the all of the properties and you know how they they interact with each other in the in the lean model. Um and yeah this is where we are basically uh plan would be to target things are in motion. Um we have this former verified design. We have an EIP um specs are starting, prototypes are starting and yeah the goal is finality

from 13 minutes to uh you know four to eight times faster and then go go further. Thank you. [applause] All right, come on. Let's give Franchesco a big round of applause. Wow, you were like a speeding bullet train going through all those slides. But look at the audience. We got a full audience and people watching online as well. People want to ask lots of questions. So again, ladies and gentlemen, if you can scan the QR code, also remember to upvote your questions. We've got a lot, but we're going to try and go through as many as we can. Let's go to the most upvoted one so far. How does it impact homestakers who are running validators using 32GB RAM, 2TB, NU, Pi, 5B devices with low internet bandwidth areas? Very

good question. Uh yeah, I guess the question would be about fast finality like because it's a bit different if you talk about fast finality or PQ. Um but uh yeah, let me maybe try to answer both. I I think generally PQ um can put a stress on the really long tail of the network just because well now we have to deal with um these larger signatures, we have to deal with aggregating them. I think there is some element that's that's a bit um you know inevitable there that you know once we have to deal with this overhead um some part of the network might not need to be a might not need to might not be able to keep up with it. Um in principle the couple consensus allows actually um to play with the trade-offs. So we could um

basically have the finality time be um as long as we want based on what trade-offs we want like based on which participants are we okay with um you know being the the kind of minimum level of hardware and bandwidth and so on. So actually the couple consensus gives a bit more flexibility in how we decide about the trade-offs. >> Yeah. All right. Thank you for answering. I'll mark that. Okay. Next question that also got quite a few up votes is why do consensus related attestations need to to be to be PQ safe? [snorts] Cryptographers still haven't reached a consensus on whether ECC will break. Isn't there a risk that we are throwing away decades of E?

[snorts] >> Uh yeah, I mean I'm very much not a cryptographer. So, you know, this is the kind of thing where I'm I'm I'm happy to just uh uh listen to the cryptographers and try to understand what what is the consensus and and understand what what is the safe thing for Ethereum to do. Um I think anyway we've been on this path of moving to postquantum cryptography for a while. Um I think the question now is just like what are the timelines. So it was never in question that we would do it. Um all the work has been happening for years now. I think uh you know lean under the umbrella of lean Ethereum and and and not only for maybe like two years now. There's been like a huge amount of work going into this. So I think the question is really not been

at all should we do it. It's just when should we when should it be done by? Should it be 2028? Should it be 2029? I think it's reasonable to question this um these assumptions and these timelines in the era of AI where like you know things are really changing very fast but yeah again I'm not a cryptographer so I'm not going to comment specifically on uh you know elliptic curve cryptography breaking or not. >> Yeah. Yeah. I think even in the previous session uh the speaker also shared the age of AI is just forcing all the timelines to be faster and faster and faster and people just don't know when to expect. Okay, next question. Let's go. Another upvoted question. How do we decide who stays in the smaller committee and does it harm decentralization?

>> Uh so this is a simple answer. Does it harm decentralization? No. Um no one stays in the smaller committee. People rotate all the time. It actually looks very much like today. It's just the rotation is on I mean rotation happens every slot. Um you might participate less often but it won't actually harm anything like it's um rewards are based on your weight just like today. Everything essentially looks like today in terms of fairness. >> All right. Very good. Yeah, it does not harm. Okay, let's go. Another question at the top. Current eat is 32 slots. Each slot takes 12 seconds and one epoch takes 6.4 minutes. Finality is after two epochs.

If you have to explain fast finality in comparison, can you summarize what are the changes? Um yeah basically the so the the what we call today epoch will stay the same but it will not be um what decides the finality time uh the finality time will be on its own timeline the epoch kind of stays only as some more or less administrative accounting type of of timeline um and yeah I think most likely at the beginning the idea would be to bring down finance time by four to 8x so you know would be I guess 1.6 6 minutes. Uh maybe maybe uh less but um or sorry no um like one half of finality would be 1.6 minutes. Um and uh the slot time that's undecided but the idea would be

that we can also optimize that separately. So we can go from 12 to 10 to maybe then 8 and and so on. But of course this depends on trade-offs with the rest of the architecture of the the protocol. It's just decoupled consensus allows us to make these choices kind of independently of each other. That's mainly the point. All right, fantastic. Last 10 seconds on the clock. How final is fast finality? Good question. >> Uh not sure what the question means. If it means like is it as strong a guarantee as today, then yes, it's the same exact guarantee as today comes with all the slashing zombie finality. If the question is how final is in the road map, um then it's a bit less clear of a question. I think eventually we will definitely get there. Is it going to be a star? Unclear.

>> Thank you ladies and gentlemen. Let's give a big >> [music]