Francesco D'Amato - Fast finality, Faster blocks

Transcript

Hi everyone. [applause] Um yeah, I should actually say the the title was changed. I I think it was a uh it's a talk I've given before. Uh it's it's similar it's a similar kind of a uh topic but uh yeah it's actually called fast finality faster blocks. uh but same idea basically I'm here to uh tell you about uh first of all like why should we uh care about fast finality um how exactly are we thinking about this like concretely like you know what uh do we want to do to actually get the protocol to finalize faster how does it relate to shorter blocks that's not immediately clear and uh then you know why should you care about it like why should stakers specifically care about it um

and yeah the a quick why I think just to motivate like um why is fast finality important I think there's a few like clear reasons like one is um there's this like UX security trade-off uh that we get whenever um you could either basically choose security or UX as a as a user like in in this case I can choose to wait for finality and user might mean like uh actual user like anyone doing a transaction it might mean rollup it might mean app um you can use uh you can choose to use finality and just wait for the you know 12 minutes or whatever it takes um and you're going to get great security but really bad UX or you just say that you don't care about security and just use something like um that you know maybe like a like a weaker kind of

method of confirmation or like a third party thing like when you're bridging or these kinds of things. Um so essentially you kind of put users in this uh like uh with in the situation where they have to choose and they can't just get security by default. Um and this basically uh pushes them to potentially solutions that are not actually um as good as the the native one. And uh then another reasons that uh you should care about it uh it's not so much about the fast part but it's more about the consensus upgrade part. Um and of course you know we probably would do this consensus upgrade if to actually make the the protocol faster. But something that we'd also get out of it is that uh we can actually use it as a chance to clean up like a ton of uh technical debt that

exists in the in the consensus protocol. Um so I think like I mean technical debt and also just like high high level um really get like optimal uh provable security properties that the consensus protocol today just doesn't have. And um a quick like uh note is that um when we say faster finality or I mean even single cell finality something that has been said a lot in the past we don't actually mean that there's only finality. There's still this idea that we have today that the chain can progress even if we don't finalize. So there's this like available chain kind of blue thing and there can be reorgs like here this gray things are not canonical blocks uh but they can still exist and there's only like a prefix that is finalized. So none of that

conceptually changes. Um just the finalized part is supposed to like not lag behind nearly as much basically just like follow much faster. And um one protocol that we've discussed a lot over the last year for achieving this um is 3SF three slot finality and it's what I'm going to call today an integrated protocol. Um and here integrated kind of uh goes at this level of like finality and availability. So there's like these two things that are happening uh in the in the protocol and an integrated protocol is one that basically kind of smashes them together like both of them are essentially happening like at the same time uh in the same uh kind of way. Um and here you see this uh basically it looks quite a lot like uh the protocol that we have

today in a way um except that basically every slot you have uh all the validators voting. So here you have this like head votes but it's not a committee it's like the whole validator set. Um and uh this is what actually enables you to get like finality much faster. So you essentially have this like finalizing pipeline that's three slot hence the name where first like you confirm a block. This is kind of a technical thing that I don't necessarily need to get into. Um and but after confirming it can enter this finalization pipeline that in a way looks the same as today. It's just you first justify and then you finalize.

you have basically two voting rounds of like the full validator set. Um and at the same time uh the another block can enter the the same kind of pipeline. So at any given time there's kind of three blocks that are trying to do the the same thing at different stages. Um but otherwise like everything looks quite the same as as Gasper basically you have like head votes, target votes, like source votes. So it's like same component just in a way like um everything is happening at the same time, everyone is voting at the same time so that we can get finality much faster. Um but there is kind of a problem with this protocol even though this is something that like we we worked on for a while and have like really good understanding of like the security of it like which guarantees it provides and

the problem is basically that we have this couple thing like the these two things like finality availability they're basically like as I said happening kind of together um essentially just the fact that validators have to vote every slot like all validators have to vote every slot. Um and this has some consequences like uh it's basically like a birectional dependence between like finality and block production. Um so one thing is that finality essentially slows down block production. So every every um in every slot everyone is voting. So we kind of have to wait for this like full round of aggregation in order to produce like a new block. Um so in a way it's like finality is kind of the the needs of finality are dictating how fast we can move basically in terms of block production. And and this means also like we can't really have too too large of a

validator set because you know you can't have uh millions and millions of validators voting every slot if you want to have blocks that have a or slots that have a reasonable length. And uh on the other side block production also slows down finality. So block production has its own needs. Um you have to propagate blocks, you have to execute them. There's some other things like bit more technical that you may want to do to ensure that for example the next proposer is sure that they can produce a good block that's not going to get reorged. So there's some kind of some things that are happening in a slot that actually have nothing to do with finality and uh they actually just end up kind of slowing down the finality pipeline and getting in the way. And to kind of visualize this um you can uh oh

uh I think there's a missing slide. Um okay it's it's okay. Um yeah basically um you can think about it as um yeah I mean we can take basically the the case study of uh of Gasper to to think about this. So the the current protocol um where we um essentially have like a very similar structure. We still have slots. We still have like committee voting uh or like um some some amount of voting every slot. Um and you might think that in in Gasper timelines are not coupled because you have these like long epochs where finality happens whereas slots are much shorter. U but actually the timelines really are still coupled. Um and this is it kind of manifests in this way that if you were to u basically um have smaller committees this would help

you with uh shorter slots. So you could say okay why do we have 30,000 validators voting every slot? Uh let's just have you know a thousand validators voting every slot. This probably is going to let us have shorter slots. Uh but this would mean very very slow finality. Uh and on the other side you could say okay why do we have this like um in a sense still small committees? Why do we have like epochs that are 32 slots long? uh we could just have a bunch more uh people voting every slot. This would make finality faster. This would mean that that bloke production slows down a lot. So the same exact trade-off essentially like exists in the in the current protocol. Um and the current protocol just finds like a compromise between the two. It just says okay uh one epoch being 32 slots is

reasonable enough. You get like good enough finality, good enough slot time. In practice in a sense you you you get neither really good finality nor really good slot time. So, it's kind of um it's it's a compromise, but it's not a great it's not a great one for either of the the two sides. Um and yeah, TSF doesn't really um change fundamentally this trade-off. It just says, okay, let's hope that we can basically have really good consolidation actually near perfect consolidation um having like almost down to the the validator set being equal to the the node count. So um kind of fully getting rid of this like uh factor overhead factor and uh yeah if we assume that that's going to be the case um then we can say that okay instead of a

committee that can be the whole validator set um and all of a sudden we can get much faster finality without actually creating too much of a problem for for the slot time. Uh but still the the underlying trade-off doesn't really change like both sides are kind of getting in the way of each other. And uh a decoupled protocol is kind of a way out of this where you can actually say let's just pull apart these two things. We have finality, we have availability or block production. Let's just separate them. Um so you could say okay we're there's maybe some uh small enough committee size that we're fine with from a security perspective. Let's go with that from the perspect let's ignore finality for now. Let's just say you know this committee vital post already said this could be 256 validators could

be 500 it could be a thousand. We can like argue on the number, but this number would have nothing to do with finality. It would just be its own kind of independent assessment of what this number should be. And so you could have a much smaller slot basically because this part gets compressed. Um and finality could have basically its own separate timeline where um you know in this timeline what you care about is just like as fast as possible aggregating votes from the whole validator set. Um it's not kind of interacting with what's happening in terms of block production. like you're not trying to um have a a round of voting then do some things that are related to block production then another round of voting you can just do rounds of voting as fast as they can be basically and uh then yeah what this

looks like in terms of the you know uh trying to compare with with 3SF you would still have this confirmation phase at the beginning that's basically um getting like a minimum level of uh security on the available chain and now you enter the finality pipeline again but now the finality pipeline is just directly kind of just going ahead with the with the voting rounds. Um, and it doesn't have to kind of slow down to to accommodate the the available chain. And um, something that's kind of a recent um, I [snorts] don't say discovery, but uh, yeah, essentially something that we we didn't know before, like for for um, quite a long time, we thought uh, yeah, it would be nice if you could do something like this. U, but there's problems once you try to use committees

on the available chain. Like this was this key part that just didn't really seem to work. like whenever you try to put committees on the available chain, security properties would just break essentially. So we didn't really think that we could actually do this. Um but as of recently, we actually have a design that essentially achieves this that gets like the same kind of properties that 3SF does or you know whatever u properties you want to write down for the kind of protocol that we want that has this like available chain and finality component there's you start with this and you define some security properties. Um and essentially we we now have a design that actually achieves the all the security property properties that we would like uh without actually needing this um tight coupling essentially between the the two layers

and um yeah basically once we have um I mean now that we have a design like this like uh this enables enables us to do a few things. Um one is that basically uh we can just have both essentially we can have the the best of both worlds. Um we can have fast finality. We can we can have faster blocks like faster than than the finality timeline and faster than today. Uh even um and basically just both can be as fast as they by themselves can be. They don't have to kind of talk to each other and agree on you know you can only be so fast as it allows you in in um like finality doesn't have to kind of worry about how much it slows down block production and and vice versa. uh basically it's uh both can be optimized independently and

uh this also means that we don't really have this hard dependency on the full consolidation of the validator set if we want to do an upgrade such as this. So before we we basically always had this idea of okay if we do want to do this 3SF upgrade or you know whatever other form of this that we've uh kind of discussed over the years we first need to get down to like 30,000 validators like for example the amount of validators that today are voting in a in a single slot. Um maybe could be a bit more maybe a bit less. Um then you know there's like shorter slot times. This idea like that this is something we want to do in the future. This would also kind of put extra pressure on this consolidation process because all of a sudden if we have six uh seconds instead

of 12, we probably would uh you know want to be even more sure that we can uh squeeze a whole voting round for uh for the full validator set in there. So we basically have this like really hard dependency on getting the validator set down from like a million to you know almost maybe like 30x less or like 100x less like more than order of man of magnitude. Um and now in a way this goes away like we um once we're working with this kind of decoupled protocol this hard dependency is not there anymore. Um what happens if um the validator set is let's say 200,000 instead of 30,000.

It's just that we finalize slower but it doesn't actually kind of break the protocol. It doesn't mean that now we cannot uh do voting rounds in the in the basically time of a slot. Um this kind of finality process is happening on like a different separate timeline. Um and the the um slot time that we can support has nothing to do with it in principle. And um yeah, and this also kind of um means that we don't need to worry so much about um putting like really strict mechanisms in protocol to ensure that there's a maximum kind of validator set size. So before we had always this worry of uh we have to really ensure that you cannot go beyond you know 50,000 or whatever the the magic number is. Once we've made this upgrade, you can just

upgrade and then um some staking pool decides to split up their validators or like enter a bunch of like 32 validators and all of a sudden we're back up to like 200,000 um and I don't know slots uh just are not long enough anymore for for a full voting round. Um so now this dependency kind of uh goes away. This worry goes away. Um if something like that happens, the only thing that happens is that finality can degrade. So finality can become longer. And I mean we can put still incentives in order to kind of really try to um ensure that this is not the case, but it doesn't become it's not quite as um as as bad of a worry. We're not really worried that the protocol is going to break or something like that.

And uh yeah, I mean this is maybe a bit like surprising uh that I'm saying this because maybe if you knew that I was going to talk about fast finality in this crowd, you'd expect that I would just be trying to convince you to consolidate. And now it seems like the story is changing and consolidation is not really that important anymore. Um and well it's this is not really the case actually. I'm I'm still here to tell you like fast finality does matter. Fast finality does need consolidation. Um and you should like try to think about uh you know in whatever whether you're a solo staker or a staking pool or whatever in what way you can try to to help the the network with that. Um and the reason is like you know sure we don't have this hard dependency anymore.

We could in principle do this upgrade even without getting down to like 10,000 uh validators or something like that. Um but still we're only going to get the benefits if actually the validator set is consolidated from the perspective of finality. If uh you know we have 800,000 validators, we're still going to finalize in a similar time as today. It's not going to all of a sudden go down by you know 20x or something like that. Um so basically yeah we really only get the benefits if we actually put the work. Um and the other thing is that in terms of uh thinking about you know scheduling protocol upgrades this is going to be a massive effort um from really every point of view like I mean the um at like the specking level testing level u at the level of like uh

consensus uh devs like trying to uh figure out how this transition is going to work. So there's there's a ton of work involved. We're only going to do this work if it's actually worth it. So we're only going to do this work if it actually gives us like real benefits uh in terms of finality. So still super important for for everyone to think about how they can basically contribute to to us getting there. How can they contribute to to consolidation and uh yeah I mean I think this is kind of um an exciting time in in uh in the realm of like fast finality and this like stream of work because I think we really realize that um this is one of the really weak points I think in Ethereum story. there's a there's a lot of uh concern that this is something that Ethereum really does not do well

and and it where it really should be doing better. There's there's uh much better uh much better kind of guarantees that we can provide much faster and um so there's a lot of interest in in having this happen and we also kind of now have a bit of a better idea of how we can go about this um in a way that as I said doesn't run into this like hard kind of blockers of like okay we can only do this after like you know 100x consolidation or something like this. So it's it's it's you know really kind of exciting times there but there's still a lot of work to do. So from the the protocol side um I think what we want to do is really like ramp up on this work in in 2026 and really try to kind of finalize uh a candidate protocol and

ideally specs and uh from you know you your side from the the staking world side I think what we would basically ask is just like um think how you you know what's your strategy around consolidation uh if there's any blockers that you have try to talk to us try to figure out you know what are timelines in which we can resolve them like what things even like at a protocol level could help you let's talk about any IP that's on the table or will be on the table in the future about any tooling improvements probably even more important than than the IPs um let's basically talk to us try to uh help us help you help the network um this is really important and I think in maybe you know two three years we'll look back and and see that okay we actually did the work and we can enjoy the this great

benefits um thank you that's all [applause] >> I see lots hands for it. We have time for one question. So, I'm going to grab this side of the room over here. If you decouple the finalization and uh this whole concept basically from the epoch transition, then could you possibly get rid of all the epochs as well and just have slots coming in without any epoch transition?

>> Um, yeah. Uh, I mean I I think there might still be a reason to have some concept of epochs. Um, for like for example something that shows up when you when you work on this like um on trying to fix problems in the consensus protocol like said very broadly um is that you have to keep track of more things than you do today. like now in a way like things are a bit streamlined in the way that beacon chain does state transitions related to consensus. Um but this creates problems and I think to solve these problems it probably would still be makes sense to have some kind of

sense of epoch. It's a bit hard now to explain without getting into like too many details. Um but yeah I I think there's probably like some things that don't make sense like some aspect of what we do today with epochs that will not make sense and some that will. Maybe they can say that. >> Thank you. And Francisco, you'll be around uh questions afterwards. I I think my lesson to myself is every time that uh we host one of these events and we have a core researcher from the EF come uh we really need to provide more time for their talks and questions afterwards. But thank you for offering to stay here. But uh I'll keep us going because we do have quite a lineup of speakers uh still yet for the day.