# Fast Finality, Faster blocks | Francesco (January 2026) - Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup) - Date: 2026-04-09 - Duration: 34:00 - Watch: https://streameth.org/watch/yt-X0goy5NSuzY - YouTube: https://www.youtube.com/watch?v=X0goy5NSuzY ## Description Join us on Meetup to get up to date on our Berlin events: https://www.meetup.com/berlin-ethereu... See you at the next one! Apply to speak at our future meetups: https://forms.gle/txTvFB4E8E8KbEqX8 X (Twitter): @BerlinMeetup https://x.com/BerlinMeetup ## Transcript Hi everyone, I'm I'm Franchesco Ethereum researcher and yeah, thanks for the introduction to Enco Martin. Um, actually one thing I might have to disappoint you on is that it's not going to be a broader talk than than last time. So if you were last time and you thought that it was too uh, you know, in the weeds, then this might also be a bit in the weeds. Uh, but I think it worked out well last time in the sense that it turned out that we shipped a lot of the stuff that was in the talk over the last year. And yeah, I mean Fusaka has been on mainet for a few months. So maybe in like a year, year and a half. I I don't think this actually going to apply here, but okay, being very optimistic, maybe some of this will will make it onchain uh at some point in the next year, but maybe a bit later. Um anyway, so yeah, I took it u talking about the road map as a chance to to speak about uh a part of the road map that I really care about, which is u fast finality and its interaction with uh some of the other things that they were doing. Um so yeah the and the the talk specifically is called fast finality faster blocks because um well one part of latency is finality latency there's another part that is just actually block production latency and the two things are very related especially today and I'm kind of going to talk about this relationship and how to maybe um get beyond it basically. So yeah um so one uh quick motivating point is like why do we even uh care about fast finality uh at the protocol level and um it's essentially um the the time that uh the that gives um the native guarantees of the protocol like the time in which the uh the users rollups like whoever is actually using Ethereum to settle something um gets like the strongest guarantees of this happening and if we don't do a good job of providing this like if you like today finality time is very long. It's on average 16 minutes. Um people are just going to not use it. They're going to resort to like less secure solutions. They're going to resort to for example when it comes to bridge into something that uh doesn't actually use Ethereum guarantees and things like that. And then the other thing that I personally care about a lot is that I basically in the process of trying to improve the finality with Ethereum, we can also improve the consensus protocol as a whole. Uh which we know has a lot of kind of idiosyncrasies. Let's let's put it that way. Like just problems that we can we can really improve and and get to like a much cleaner protocol without technical debt and and with like optimal security properties. Um and before like getting a bit deeper like just a quick recap of what even at a high level uh it looks like what are we trying to achieve. Um and just like today we have this image of basically like a two two kinds of chains. We have like a finalized chain this green thing which is the thing that we're kind of trying to be to get to be faster to be like closer to the to the tip. And then we have an available chain the blue thing here which is basically what produces blocks. And it's actually what most users will experience like when you go on ether scan uh you when you see that after a few seconds your transaction is included in block you're actually looking at the available chain. Your transaction is not finalized yet but it's there somewhere. There's a chain that's growing. It's doing things and it can give you some sense that your transaction has some level of of safety. Um and we kind of care about both of these things in particular like we we we want uh the protocol to pro progress even if it cannot finalize basically. And uh yeah more completely what it looks like today we have this protocol called uh Gasper that it's basically a fusion of um a finality gadget called called Casper FFG and a uh available protocol let's say called LMD ghost and again this is kind of what produces the chain that you usually look at um and probably a lot of you might have seen like this um you know how this translates to um slots and epochs in in Ethereum and in on the beacon chain so on the consensus layer uh that we basically have this like very small time units, these 12 seconds number that you probably have kind of interacted with when when interacting with Ethereum. These are slots and it's when block production happens. Um and and then there's epochs these like much longer uh units of time of 32 slots at which at this kind of level finality happens and uh yeah finality happens basically by voting in every slot and accumulating uh the this like weight of of validators essentially. Now one protocol that has been like proposed in the past to kind of uh improve on on finality has been uh what I'm going to call like an integrated protocol and specifically this protocol that's called 3SF or three soft finality that was basically structured in this way that where u this whole finality pipeline that today is very long it's it's two epochs would be basically cut down to just uh three slots. So in every slot uh slots would look much like today except in every slot every single validator would be voting. So now you would have let's say a million validators all voting in in one slot or however the the number of large the number of validators would be. Um and yeah you basically have this kind of pipeline where uh a block is voted on it gets confirmed. Uh this point you get this sort of uh a bit um not quite as reliable guarantees that this available chain gives you. Um and then it can be justified and finalized just like today with with Casper FG. So it can get this like really strong like economic uh security like this uh statements like if you don't get uh if you don't slash like a third of the the stake of the validator set the block is impossible to revert. Um so it's really looks very similar to today's protocol but it basically compresses uh things into one slot where like the whole voting of the validator set doesn't happen by accumulation but it all happens in in one slot and uh one problem and so this protocol had a lot of good properties like we can prove essentially a lot of like nice security properties the issue is that uh I mean one issue is that we basically have this like coupling between the block production and the finality timeline. So we have uh you know these two things that are happening. We're producing blocks. We're voting on them and we're also trying to finalize them at the same time and uh this coupling here is quite obvious like all the validators have to vote at every slot. So you have this very large validator set. You cannot even produce the next block until all the validators have voted. So this is quite like a big bottleneck essentially and it's kind of goes both ways. On the one end, finality slows down block production because you again I have to have this very large uh voting ground in the critical path of producing the next block. And on the other end, like block production also slows down finality because basically you have to do a bunch of things for block production that really have nothing to do with finality and you kind of uh put them in the in the pipeline of finality. And yeah, so the the first side again it's it's quite simple. is just you know you have now this big blob of validators like imagine this big thing is just a lot of validators so it takes a while to to do this voting round um and it could look like this. It could look like uh you have a much smaller set of uh much much smaller committee or something like that. And this is how you progress slot to slot. Um and going from you know the right to the left you have to just increase the the slot time a lot. And on the other side it's it kind of looks like this. Like you could have this nice picture from below where like you produce a block and then you kind of immediately just finalize it by doing this like very large voting grounds justification finalization like in Casper Fuji. But then what it actually looks like in 3SF is is is this picture from above um where everything happens kind of uh interled and so you have uh a lot more uh you need more things basically to happen before you can actually finalize something and uh this actually is just the same now now this is more obvious maybe with 3SF because you have this like uh big validator set that's voting in every slot. So it's kind of ob obvious how it's slowing things down but it's actually the same in today's protocol. Like you might think, okay, today's protocol there's these two timelines that are actually pretty separate. There is like the slot uh timeline and the epoch timeline. They look like two different timelines that have sort of nothing to do with each other. In reality, it's not really like this. It's because we have this coupling that comes from um you know, we basically say we have um in each slot we have one fixed fraction of the validator set that's voting. It's 132nd. So we have like 32 slots per epoch. And um this basically means that if we wanted to um make finality faster, we would want to compress this. We would want uh you know this to not be 32 but to be 16 to be eight or something like that even all the way down to one. Um so we want to basically make epox smaller but then we go towards having larger committees and this being a problem for block production. And on the other side uh yeah the the opposite problem essentially that we could go in the other direction but then we make final finality very bad um to make block production faster. So today basically we have the same trade-off and yeah we just have this like kind of compromise that's not great but it's just fine where we have 12 second slots. It's not awful and we have finality being um basically 12 minutes or 16 on average which is also well it's pretty bad but you know it could be worse. Um, and yeah, that's just it's just one point in the trade-off space, but you could go you could go in a different direction, but you're going to make one of the two things worse essentially. And uh, this 3SF protocol that we kind of had introduced uh, and like, you know, studied a while ago, it basically doesn't really go beyond this trade-off in any way. It just says, well, let's hope that the validator set is small enough that this is all kind of fine. Like we just say, well, um, in every slot we can have everyone vote. Maybe now we don't have 1 million validators anymore. maybe we could get down to like 10,000 or something like we could consolidate the valid validator set and there's this like effort ongoing to get people to to consolidate their validators. Um but yeah, like that's basically just hoping that the trade-off is going to disappear by consolidating the the validator set. And there's like another path which um I'm going to call roughly decouple protocols which is actually trying to get these two timelines to be uh separate from each other and not in interacting with each other in such a way that this trade-off actually disappears. And uh so as many things Vitalik had kind of um you know mentioned this in in some blog post uh he had this proposal to basically say well let's um and hopefully you can now recognize the words like uh LMD goes with 256 validator this is this like available chain thing that kind of produces blocks and so on at the tip of the chain and he was saying let's run this with like a very small committee could be 256 it could be you know more but whatever a small committee um that basically would just like try to keep the chain going when in in fast manner and then fast following finality gadget. So try to have then uh you know after you produce blocks with this thing you have a finality gadget that separately then tries to finalize them. Um which you could say it looks a lot like today uh but it does this like uh important step of actually decoupling the the two uh timelines. So not trying to do finality by uh you know having 256 validator vote first and then then 256 more and then 256 more like uh this committee part would not be how you eventually get finality like finality is not by accumulation of small committees essentially and uh yeah why I mean this is kind of just summarizing what I've said so far but like why do we want this decouple type of protocol um one reason is just uh latency both of uh slots like block production and the other one is finality like latency of finality that we just eliminate this this trade-off and then the other one is that we basically stop having this really hard dependency on validator set consolidation for making this kind of uh improvements to to finality. So we basically don't want to be in a position where we have to say oh we have to get the validator set from 1 million to 10,000. Like that's you know very big step in order to be able to ship something that looks like fast finality. Like it would be nice if we could just do it regardless of where we're at with the consolidation process. And uh yeah what this looks like at a high level is is again this like we have this uh timeline of block production on top this like again blue available chain um which has these like uh orange kind of small committees now. So it's, you know, today this blob of committee blob would look like 30,000 validators. Now this maybe could look like 500 or like a thousand. So it could be like much smaller and much faster to actually uh you wouldn't need to actually aggregate these votes. It could be like a much faster process. So these lots could be potentially quite a bit smaller. So it kind of helps in the in in that part of things to optimize for shorter slots if that's what we want to do. And then independently you have this uh kind of big uh green things that are that are doing finality. Um, and here it's it's maybe like the whole lighter set that's that's voting all at once. Um, but it's kind of doing so on its own time. I mean, here you you see that it it roughly matches the slot time, but it's that's just for the picture to to I don't know, not stretch it out too long and make the picture weird. But this could be completely independent. It could take four slots. It could take 4.5. It doesn't really matter. It's just happening. And when it when it's done, it's done. And so these two things can be then independently kind of optimized. Um and otherwise other otherwise things look still like this like you have this confirmation step and then the finality step like justifying and then finalizing. So two like big voting rounds and one small voting round basically and uh yeah I mean the question one question would be why didn't you know it seems like pretty like simple idea why didn't we just do this um a while ago and uh one reason is that there really wasn't a viable design for this until quite recently um basically it boils down to this like this blue chain this like available chain thing that kind of happens at the at the tip and like produce box we just didn't really have a good enough design for it that supports committees. Uh like we kind of want it to move fast. So we want it to not be the whole validator set that's voting in every slot. We want it to be like some rotating committees. And it turns out that like the kind of protocols that that do that work like that, they all add some kind of problems that that we didn't really like. Um roughly speaking, they basically once you have a bit of network asynchrony, they tend to have uh the same kind of problem. And I'm going to try to describe like what this problem is more or less with an example. And so there's like one protocol that we worked on specifically, but actually it's kind of representative of a bunch of these protocols that that look like this. Like they all kind of tend to have the same problem essentially. Um it's quite similar to LMD ghost, but it has this property that it's memoryless. So um again in LMD ghost you have you have blocks and then you have votes. And votes are what lets you figure out where do you go in the for choice like what actually is the the chain that you're following. And uh this memory memorylessness means that basically at slot t you only care about the votes from the previous slot. So at any given point the only way for you to determine what's the chain is listening to the previous votes. Not the votes from like an hour ago or something but just the previous votes. And so this is very nice in the sense that the protocol becomes super simple. You just really like take these votes and that tells you all you need to know like really the most recent votes. Um and it basically prevents like a certain kind of adversarial attacks that that are basically where a lot of the problems of LMD goes to come from these kind of attacks. So you can like uh prove really nice security properties for for this kind of protocol. Um and yeah I mean here you see basically everything would be determined by these votes at this slot and um yeah so this then would be like expired and now you only care about these votes here and so on. Um and so so this is nice. You can make a protocol with this property that has really nice properties. Again, um the issue it has essentially this you can be in like a very good situation. The chain looks great. Everything is there's one long chain without any forks. All the votes are here. Everyone agrees. Now there's comes one moment of asynchrony. So by asynchrony means some kind of network turbulence like basically for one slot no one knows what's going on. Uh these are these votes are supposed to be like good votes that just get lost like no one makes them or they no one receives them and so on and all of a sudden uh some malicious actor in the network makes basically a fork and then has like a tiny bit of votes to it like maybe it's one vote or or something. Um, and so the again because we have this memorylessness, what ends up happening is this kind of catastrophic outcome which is that uh everyone forgets about where we were before and they just listen to these these votes and then everyone ends up here and all of a sudden we just forked like a whole it could be like an hour, it could be however long basically. So it's like a really bad uh kind of failure mode and like this was like kind of unacceptable and so any protocol that would have a problem like this like we would never use it basically. And uh so for a while this was the story that we just like didn't really like there were either protocols like this which had this problem or there were ways to fix this problem which essentially looked like not having committees because having committees had all kinds of other yeah other issues that that you you wouldn't like essentially without this kind of memory memorylessness. And uh yeah, basically it turns out that there is like a not so hard way to to um fix this issue. And what this gives us is essentially what I mentioned before, which is we can have in principle independently uh independently optimized finality uh and uh block production time. So we can have fast finality and we can have faster blocks at the same time. Um and we also don't need to have this like dependency on waiting for valid consolidation. So basically we could in principle as soon as you know everything is ready deploy something like this and then as validator consolidation happens finality will get faster for users. I mean it can we can it can also be faster with um yeah like doing something like this immediately gives you like a bit of an advantage like you can improve it immediately but then the the point is that once you've done this um the more consolidation you get the more finality just naturally gets faster for for users essentially. Um so but there's no like uh there's not like a hard cut off where like only now we can do it like we have to wait for you know 100 thousand validators or something like today again it's 1 million we don't know when we're going to get to whichever number and uh yeah the kind of at a high level like what this looks like how do you what is the fix um is essentially uh really not that different from the general ideas of how these like uh decouple protocol work decoup decoupled protocols work um is essentially that you take uh these kind of voting rounds where the whole polier set is voting and again this is meant to be for finalizing which in a way you could think of it as well finalizing will definitely fix the problem because once you finalize there's no reorgs anymore like you can't have this like catastrophic kind of reorg the whole chain or something and the issue is just that we might not be finalizing we might be in a situation where we're not uh but it basically turns out that you could just use these votes even if you're not finalizing to kind of stabilize the chain. So to kind of prevent this like catastrophic cases and it basically looks like this um you would have a three-level for choice where um first you start from the latest justified. This is something that is basically produced from the finality gadget is like a kind of it well it's not quite finalized but it's something that looks like it's going to be finalized potentially and so it's kind of it's where you you start your for choice like it's where you you start given like nothing before that you even consider as potentially part of the canonical chain. Then there's this like uh purple blocks which are basically what's been added here. It's um yeah, you use the same votes that you use to finalize, but you use it um even if you're not finalizing to determine uh kind of like a stable prefix like something that you basically say u where you basically say this shouldn't be touched like I should not reorg this uh even if the this kind of underlying protocol is telling me that I should be reorginging it because it might there might be you know this uh like uh network asynchrony or other situations that have caused this and then only then you you go to this like uh you know faster moving kind blue suffix. Uh so you basically go through all of these like more stable steps before you get to the the blue like unstable part. And this essentially makes it so that the unstable part has like a low degree of instability like it can cause uh you know crazy things to happen essentially. And uh yeah one last so that's I mean that's basically the main idea. I'm not going to go you know into too many details because there's a limited time but uh one small uh kind of bonus thing is that um another kind of development of the last maybe year and a half uh which is partially like another reason why we've like thought that it makes sense to generally review the plans for how to do fast finality is that there's been this emergence of what people call uh one round finality protocols or at least actually they call them anyway I I call them one round finality protocol which are basically protocols where u you only need one of these like green things in order to finalize like you only need all the nodes to uh do like basically one vote like one voting round in order to finalize something. Um and like there's some trade-offs and you know whatever we can like we can you can discuss the exact like what what exactly are you giving up by doing this but they're pretty nice protocols. They they have really like good properties. The trade-offs are actually not very bad. Um and getting one run finality is like pretty big deal. Um, so ideally we would like to use something like this for the finality gadget. And so actually what the whole thing could look like is really just that you have a slot, you have like this like very small again orange uh committee that that's voting and this could be like a very small committee. It could be very fast and then you only need a single one of these like green bubbles like of this like whole set voting in order to finalize. So basically the whole pipeline could just look like essentially have a slot have a little bit of like extra time for this like small voting round then have the whole validator set do its thing and you're done and like now uh you know users know that their transactions been finalized. Um now yeah as to like you know when any of these things will actually hit mainet I think it this is more speculative than when you know last time I was here talking about pure I think that was a much to some extent more um much closer to the to the development pipeline. uh but still like I think it's pretty clear that there's a huge interest on both of these things like both on improving finality and on improving uh basically block time like uh just basically like block production time. So yeah, I think both of these things will see a lot of interest and I think a lot of these ideas will hopefully play a role in actually getting this to mainet faster. Thank you. Anyone have questions? Yeah, right here. And I have a couple of questions. Very interesting. Um, and I mean it's also very interesting to see how this is exactly on the road map if uh you can say to this or something. >> Uh yeah. So I I mean in terms of communication um there's probably going to be a blog post on like E3 or something that talks about these things soonish. Um as to like what this could look like in practice on the road map. Um I think that's harder to say. I think one thing that we're basically interested right now in looking in is if um something like this can to some extent be done iteratively. I think like we know that you know it's it's uh always harder to try to do these like grand plans of like you know uh in three years we're going to do this big upgrade or or something like ideally it would be nice to not do not try to chase something like this but actually try to uh say okay let's maybe first do the finality gadget part or the decoupling part or something like that I mean and the two main candidates are kind of these which is like u one could be to first try to do the decoupling so to try to basically move away from uh having like today 30,000 validators vote in every slot. We could go try to already go down to this like small committee basically do this kind of part here. Um and that could also potentially help with shorter slots. Um so we could try to do to do that and decouple from from finality or another thing that we could try to do as an intermediate step is u the the finality gadget part. So we for we could try to to move to like a one run finality kind of gadget before even doing this like broader decoupling thing. Um I think it's yeah it's not very clear at the moment and it also has like a lot of interplay with shorter slots as like a general like people have like really a lot of interest in making slots to some extent shorter fast like you know in the next year in the next fork or uh something along those lines. So I think that's the part that for sure will happen before but it doesn't necessarily I mean it interacts with these things a lot but it doesn't necessarily will not necessarily come with like big redesigns. It might just be like a, you know, just optimize stuff and just try to squish the slot, which we definitely can. So, yeah, I don't know. I hope that answered it. >> Yeah. And I have another question that goes in the direction that you mentioned. Um, do you know what are the interactions of this proposal compared to the lean? Um, >> yeah. Um, >> in what sense? Okay. Yeah, that part. Uh, yeah, I think so. Right, let me start from uh some of the interactions. Um, so there's there's some interactions in like I think for me and I think even if you ask them um lean and you know people primarily working on lean um a big thing in in the whole idea of what lean is supposed to do is this postquantum transition. So that part definitely interacts a lot with anything to do with finality and the reason for that is essentially that um you know there's this whole part on aggregating signatures like doing voting rounds in a reasonable time and so on and postquantum signatures are very large um so that's one kind of minus there that like it makes things harder it makes it more important to have a smaller validator set on the other end there is like a subtlety that uh if you're doing signature aggregation um in this like brute force proof like recursive proof approach which is kind of what they would want to do um in with postquantum signatures. Uh yes the initial signatures are large but actually the the aggregation part is a bit better than what we have today with BLS signatures because basically with BLS signatures you cannot aggregate things that um overlap like you can only aggregate things that are like nice disjoint unions. So in a way it gives you like a bit more power to design uh the aggregation part uh in a in like a more flexible way. So this interaction there it's a bit unclear like it might even there's like you know one side one part of it that's bad and one part of it that's good. Uh but yeah I think bottom line is it might be that if we you know want to design for the postquantum uh kind of transition earlier then we might need um to like plan for a smaller evaluator set like independently. Uh as far as like the iterative versus uh you know big four kind of uh side of things I think um yeah I mean there's I think there's different opinions but I I I would say that generally the mindset is more on delivering things iterative iteratively and and trying to do um you know one time big upgrades only when there's like a clear reason to do so like when it's like okay like this would be genuinely just not in any way like good to split up. So at least I don't know that's that's my take and I think it's fairly shared. >> Chris over there. >> Um so we try to intuitively understand um comparing the time it takes for initial confirmation with like the retro and then the full finality. Is that like the relationship the same which is the comedy size versus like the two/3s of the whole um of the whole value per >> um I think not really because I think probably in the red part what really dominates is just the latency of doing like whatever amount of hops is needed in the network uh versus like it's not like you know about um just like bandwidth like how much like actual like attistation data is going through like if the committee is small enough the bandwidth will basically just be irrelevant. it's just going to be like you know there's a few hops to go through in the network um and that just has some like fixed cost basically in terms of latency um whereas like at some point uh there the bandwidth cost becomes like pretty meaningful um like even you know today with the 30,000 uh kind of uh committee it's it's not nothing like it does make to some extent a difference um yeah so I I think it's it's not it's not quite like linear I guess like the the red one will will have some like fixed cost that that's kind of the same as the the the large one and only this maybe like bandwidth part will will scale scale more like proportionally um but like still I mean I think basically you know there's no reason that if well designed like this um red arrow should be more than you know like 1 second two seconds at most like even without trying to you know go full um data center or anything like it's yeah there's not that many hops to go through in the network and like even the farthest nodes are only I don't know like 100 millconds away or a bit more it's not like uh >> and if you try to understand the just one slot confirmation how much certainty it gives that it won't fork >> yeah so we have like kind of um looked into this uh as part of there is this like somewhat parallel thing going on now of people working on what's called the fast confirmation rule um that's actually on top of the current protocol. It's not trying to like invent anything new. It's just trying to use the existing thing to like extract a guarantee out of it. And um yeah the basically like at least looking on um you know trying to see like on historical blocks or like you know if you run it on current blocks or whatever like how well does it do it never seems to return to like tell you that something is confirmed if it doesn't end up being confirmed and more or less I mean this has to do with like the assumptions are essentially two like one is network synchrony and the other because again this is not finality it's not economic finality it doesn't it's not in particular it's not like an asynchronous kind of guarantee like if if the network blows up um this might not be like a hard guarantee but so yeah one of the assumptions is synchrony and the other one is like how many malicious voters are there so you know the network is pretty synchronous in reality like most of the time it's it's quite synchronous um especially if you make like mild synchronous assumptions of like seconds not of like you know 100 milliseconds or something um and the other one is like there's not really nodes going around the network trying to like game this or like at least you know even if there were there's not 20% of nodes or you know 30% or nodes or something like that. Um, so yeah, I think you can get pretty good guarantees for like the non, you know, if you're sending to someone 50 millions, like you probably want to wait for finality, I would say. But like if you're doing like a minor transaction or even like, you know, exchange deposit that's not like insanely large or something, I think there's not really much of a reason that you cannot get good enough guarantees from this like synchronous uh kind of confirmation. >> And if you were shorten this up, would it become 50% certainty? um 50%. Sorry. What would you >> would be six second slots instead of 12 second slots. Does that mean like after one slot the the risk doubles that it might still not be fine? >> You're saying if we shorten the slots it becomes uh riskier this rule. Yeah. I mean I guess again one of the assumptions is uh network synchrony and of course it's the it's you know the strength of the assumption depends on what is the latency parameter that you're assuming synchrony with respect to. So like if you compress things more and more and more at some point this latency parameter becomes more risky. So so that is true. >> I think uh >> you don't my question. >> Okay. >> Okay. >> Maybe uh one of the small questions. Um how does this fit in in the me pool? Essentially everything before finality would be in the me pool or at which part is it in the pool? Um this is like I guess even maybe it's in a way it's like the mele is the missing part of the story in the sense that it's like so there's you know the blue blocks and the finalized block whatever and then there's even before the blue blocks there's the mempool but like once something is in a blue block it's out of the mele array like if it's in a block that's kind of people consider canonical then they will not keep it in their mele anymore. answer. >> And and just a very stupid question. Um I kind of are slots and epochs again. >> So slots are like um every 12 seconds and it's when like a basically beacon block with an execution payload inside of it is produced which essentially is like when let's say when an Ethereum block is produced like make it simple. >> Slot and blocking would almost is like what's the difference between the slot and block? Um, it's basically just that slots can be empty. Like it might be that someone misses a block, but yeah, essentially for the purpose of this, you can basically think they're the same thing. Like every slot you expect there to be a block. >> Slot for a block. >> Yeah. >> Yeah, exactly. Um, sorry. Oh, yeah. And epoch is Let's quickly Okay. So, I'm going to be quick, but okay. Uh, let's go to the picture. I think it's useful anyway. Um, here. Yeah. So, basically like it's you just have 32 of these slots like in a row. Um, that's what's just called an epoch. And uh in an epoch like the definition of an epoch is essentially that everyone will have voted by the end of the epoch like because basically this like little um well I mean for our actual protocol not so little but yeah so in this is kind of meant to be for actual protocol this would be like 132nd of the validator set. So it's like about 30,000 validators will vote in every slot by the end of the epoch all of the about 1 million validators will have voted. >> Oh that's like consensus. Yeah, I mean you kind of need two epochs to finalize, but in one epoch you can already do this justification thing. And that's like it's not quite as strong, but it's some it's it does like the first round of a finality protocol basically. Thank you. Thank you.