# A Fast Confirmation Rule for Ethereum | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 24:19
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-p7JPRTELnJc
- YouTube: https://www.youtube.com/watch?v=p7JPRTELnJc

## Description

In this talk, we present an algorithm that, assuming good network conditions, reliably determines in less than a minute whether a proposed block will always be part of the canonical chain.
This represents a considerable speedup compared to waiting for the full security guarantees provided by block finalization, which takes 13 minutes in the best-case scenario.
Also, this algorithm provides a far better metric than chain depth, which some services still use. Paper https://arxiv.org/abs/2405.00549

Speaker(s): Luca Zanolini, Roberto Saltini
Skill level: Intermediate
Track: Core Protocol
Keywords: Layer 1, Consensus, User Experience, confirmation, rule

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hi everyone I am Luca zanolini and today together with Roberto saltini we are going to give you an overview of our past confirmation rule for the ethereum consensus protocol this is a joint work with Adia um Francesco and Chene so let's start by answering this question what is a confirmation rule uh before that let me give you a quick definition that will be useful throughout the course of the presentation what is a canonical chain a canonical chain very roughly speaking is the chain that is followed by the honest validator so the honest participants in the consensus protocol for more technicality is basically the output of the Fortress function but let's just stick with the followed by the honest validator um our fast confirmation rule is an algorithm that enables nodes that run this algorithm to identify blocks uh that will never leave the canonical chain assuming uh good Network conditions uh basically it this algorithm outputs uh whether a block is confirmed or not and it satisfies these two properties one is safety meaning that if a block is confirmed by a Val validator at a given time it will always remain in the canonical chain forever basically moreover we have also monotonicity meaning that if a Block B is confirmed at a given time it will always remain as confirmed meaning that if we confirm a block today tomorrow it will remain confirmed sorry uh sorry something is going on with the presentation okay sorry today we will focus only on safety property given that monotonicity actually requires some technicalities that uh are out of the scope for this of this uh overview uh okay why do we need a fast confirmation rule in the first place so today the way we to know whether a block uh will always be in the canonical chain is through finalization right the problem is that with the currently implemented protocol finalization takes up to 13 minutes in the best case scenario and for some kind of users this might be too long to wait to get a confirmation in some sense moreover we cannot really use block confirmations as we were used to do with proof of work for example where the more block blocks are appended on top of a block the big the highest the higher was the uh likelihood that this block remained confirmed because in the current protocol we have seen uh some attacks called balancing attacks where the adversary could manipulate in some sense the view of honest validator making them believe that they were participating in a chain so in some sense this might not be the real chain under this attack so block confirmation doesn't really say anything about whether a block will always remain in the real canonical chain in some sense um so with a fast confirmation rule what does a fast confirmation rule give gives us give us for for sure it gives us a Improvement on the user experience on of in ethereum because uh for having faster confirmation rule implies that small values transaction can in some sense don't have to wait for finality for finality but they can already immediately be assumed as confirmed implying that they will eventually get finalized moreover it reduces also risk uh trade um basically trade reversal give uh made by H for exchanges that allow to optimistically trade immediately upon deposit and moreover it improves also reliability of some wallets in particular there are wallets that tell user dat a transaction is already confirmed upon entering uh upon including in the block but as we said before because of this possibility of a balancing attack this doesn't really tells us anything meaningful so having a fast confirmation rule can really improve also reliability of wallets in general um it's also useful for PBS in the sense that it provides block Builders with an indication whether the block uh that they are building upon is actually not going to be reared so in some sense this fast confirmation rule can give us more reliability and can help users that want faster confirmation time instead of having to wait finality before going into details of this confirmation rule let me very quickly give you an overview of Gasper this be this because Roberto will introduce some technical terms that it's better if we are all synchronized on that um Gasper it's the name of the consensus protocol this is a proof of stake protocol that can be seen as made by two sub protocols one is lmd Ghost which is a synchronous consensus protocol that determines the canonical chain and Casper is the finality gadget on top of this that finalizes block that are outputed by this lmd ghost basically it finalizes blocks on this canonical chain the time unit in Gasper is a lot a lot lasts 12 12 seconds a you 32 slots Define a neoc for for every Epoch the set of validators is partition in 32 disjoint committees and at the beginning of a slot a proposal is randomly selected from a committee and it proposes a block on top of the canonical top of the head of the canonical chain and the and the other validators in the committee will just cast a vote ideally for the block that has just been proposed how validators def choose which is the head of the canonical chain they do it through the Fork Choice function for Choice function select all the latest messages ever cast by validators and it chooses the heaviest chain in terms of stake that these messages carry so for example with this image this is the canonical chain and proposers will just aend the block on top of B9 for example one last thing in case of a validator sending two conflicting votes for the same slot we do not count these votes for determining in determining the weight of this chain so we discount equivocations um now let's dig into technicalities of the confirmation Rule and Roberto thank you microphone thank you Luca for uh setting the stage with all the concepts we need to understand how the confirmation rule works so let's start with uh some assumptions we rely on the first one we think we rely on the fact that votes uh sent by validators are received by other Honest validators by the end of the slot the second assumption is that we assume that there exist a maximum beta fraction of uh Dison stake across any set of committees so take any set of committees we assume that maximum beta of the stake of this committee is dishonest and one minus beta is for sure honest okay as Luka mentioned we cannot rely on chain depth at all we do need to rely and look at that the weight of the uh lmd ghost board so how do we do this well let's start by assuming this block B1 is canonical for now we for our example we use beta uh 0.2 20% and then we assume also first Simplicity that the weight of a committee is 100 100 now what we're going to require is s is represents the um the support the weight of lmd ghost that goes towards block B1 we require that um the S is larger than W multip by half plus beta we'll see why but just uh running through the examples um in our case this means uh s of B 11 more than 70 and we pick 71 any we know that any other block at this for this slot that is conflicting with V1 has Max has no more than uh actually has less than half W volts so which means less than 50 let's Pi 49 what is the worst case scenario well the worst case scenario is that beta of the stake equivocates with beta of the of the stake equivocates then 20 uh 20 basically weight of 20 is uh subtracted from 71 we have 51 for b11 and 49 for anyone else well B1 wins the four choice so yes with this rule we can say B1 is canonical uh but are we done no we are not done all we can say is b11 is canonical in this slot we want to say b11 is canonical forever and we can do that but we see why we can't do that just right now so what happens for example if we move to the next lot let's start with our progress with our example um when we go to the next lot the committee weight goes to 200 um Everybody every Honest One votes for B13 this votes 80 goes to be uh 11 now we have B 11 as a weight of 131 but what we need is a we need 200 multiply by Beta plus um half we need 140 so we're not quite there and what does this mean is be still going to be canonical what the answer is yes it is but in order to prove it we need to do some clever trick this clever trick is assuming that we somehow for now we know who is honest so we are going to use this um H H represents the uh V for B1 that are from honest validators bear with me we'll go over this honest thing later NJ represents the uh validator the stake in the committee that is honest what you're going to require is that age of B1 is larger than half the total weight of the uh committee clearly honest validators never equivocate clearly this will give um will make B1 win the fork choice but we actually going we are going to work with something a bit more complex uh which is this we are going to require that age of B1 is larger than J which is the honest uh committee multiply by half divided by 1 minus beta we'll see why this Metals thing is that this second condition implies the first one uh can show you by running uh using our numbers we get HB 11 more than 50 we just pick 51 for now so what happens when okay sorry I forgot this uh we ually uh we Define an indicator b for usefulness of uh the fraction of H over J which in our case turns out to be around 0.63 which is larger than half divided by 1 minus beta so what happens when we go to the next doot let's have a look okay the committee increases to 200 the honest committee increases to 160 now everybody that is honest vote for B13 this weight goes to b11 as well if you now calculate P we have 131 over 160 which is roughly 0.81 which is larger than our Target of 0.625 that's exactly what he wanted as we show before this actually implies that the um B b11 is at least more than half of the uh possible vot so b11 will be canonical now for those who actually uh know intimately Gasper they might ask well but when you cross the AO things are not exactly like that but I show you that that's not a problem so what happens when you cross the aoke is that um it's possible you have a new validator set that is sampled but it's possible that in the new slot um you have validators that already voted before so in this example we assume that the honest committee only increases by X some X of some sort um what and so in the news law 80 or the honest one will vote in support of B 30 and because X stake is new they have not voted before so the support for b11 will increase by X now if you calculate p is 51 plus plus X over 80 + x because uh X is added both uh above and below the line and 51 is less than 80 we know this is larger than 51 over 80 which already shown is larger than our Target so what we have to T what is shown is p this indicator P never decreases so once it's higher than our Target which is half divided by 1us Beta we know B1 will be canonical forever but now how do we measure P well lucky for us uh if we use our initial uh fraction which is s over W to be larger enough plus beta actually this implies uh the threshold that we want for p so we left with one last uh thing oh sorry this um so basically what we have is that if if you have this the Q which we it's what we me we mean to be the defined to be S on W to be more than half plus beta this implies that our threshold on P and that b 11 will be canonical forever one last thing how do we we we assume that B10 was canonical how do we solve the problem that's very easy we ask the question is q more than half plus beta for for B1 then we go back to B10 to B9 until we get to the finalized block so in terms of lmd uh cost that's all we need in terms of confirmation rule things get a bit more complex when we add FFG gaspa so with with FFG gaspa the fork Choice gets a bit more complex we start from the uh latest Justified checkpoint which is roughly the checkpoint that is ready to become finalized we remove some blocks that are problematic and then we apply the fork choice that Luke explained before to the remaining blocks so what we need to do to ensure that b and some some Block B is canonical forever we apply the rule that we saw before for lmd Ghost and then we need to work out a series of conditions that ensure the B will never be filtered out by this by the effect of integrating lmd G with GPA this amounts to in our case to we uh require that the checkpoint justified by Block B is from the previous ook this ensures that in the current EP Block B is not going to be filtered out and then we have this more complex condition which we I'll break uh break down soon which ensures that b will not be filtered out in any future ook as well so what we are going to do in this condition we we look at the the uh weight of FFG votes for the checkpoint of B we remove the maximum amount of those votes that can be uh slashed because then perhaps they bu and time so this corresponds to Beta the weight of the committee from the beginning of the slot to the current slot and then we add the minimum amount of weight that we keep voting for the checkpoint of B which is the one minus beta the remaining weight between the next slot and the end of the slot and we require this to be more than two3 of the to Total stake what this gives us that gives us the checkpoint B has enough votes to be justified so through a uh kind of quite weak assumption this uh checkpoint of Block B will be Justified over the the next ebook and then because we know that every honest validor only votes for a descendant of B if there is any uh checkpoint in a future OK which will be justified that for sure will be a descendant of B which means that b will never be filtered out and therefore will be canonical forever just going through some initial experimental results there are due to Circle so thank you Circle for running them uh there is a blog post actually coming out soon so stay tuned uh the set up was um they run the confirmation rule over 6 days uh they detected over the this six days 56 blocks that were reor and some also were two block reorgs there the implementation was a proof of concept the there are some approximations so for example they were pulling uh Bon nodes every 10 seconds rather than running the confirmation rule at the beginning of each slot also they were estimating the F the FFG weight using just the lmd weight however the results are very encouraging first of all none of the of the reorgs uh were ever confirmed no matter the value of beta so this gives quite good confidence of the sa security provided by this rule second in terms of performance what they saw was that if you fix beta to be around 50 20% of the stake you could see confirmation in four five slots if you go up to 30% you get to 8 nine slots however we think uh this has to be proved uh in practice that if the rule is implemented by running it at the beginning of a of a slot then we should be able to confirm uh a block in 12 seconds so this leads me to the last slide so if you are interested in testing this and you're interested in implementing this confir confirmation rule on a bon node uh reach out to us uh our contacts are in the talks description also one with the QR code for the paper which is also linked to the talks description and the second QR code is to the ethereum consensus PPR if you are if you are interested that's all thank you okay cool I'm going to approach from behind and push you towards the middle uh as we address questions so we'll start from the top seems like confirmation role will get obsolete with single slot finality does it make sense to work on it at this time seems a question just ourself yeah the point is that we still don't know exactly when single slot finality will come out and the confirmation rule is something that we already have so it can already be an helpful in some sense while waiting for single finality but yes once single finality will be out probably there will not be it's not needed anymore but yeah it's not say it's in our opinion not too diffic that is doesn't require any hard for it's not that difficult to I wouldn't be the one implementing it but I don't think it's that difficult to implement or doesn't wouldn't take that long and provides good benefit in the meantime yeah um okay cool H the UI is not updating um how do you estimate beta is it a new parameter it's uh it's uses subjective belief on the value of beta so the user picks their beta that they believe that that is the maximum and they query and according to what they believe is uh they get the the result accordingly well can a confirmed transaction still be affected by a reorg if if uh so this as I said one of the assumptions is that votes are delivered by the end of the slot if there is a network partitioning U this is not true anymore yes it can be it can be affected by real so it's not as safe as finality but it's quicker it's a sort of tradeoff what is the recommended value of beta you suggest is it point two and how does it impact security that's a very good question um of course beta cannot be larger than 30% in other aspects and some for example the work on um uh epbs that that's been uh researched out usually 20% tend to be what people are comfortable with in setting beta so that seems like a good reasonable value what are the security guarantees do you have any probabilistic assumptions we have some probabilistic assumptions which is the one that said know we have this assumption saying we take any sequence of slots and the maximum bait of the stake is dishonest as you know the committee sampled randomly and so when you cross actually the EPO you have some also probability measure that if you assume that say if you assume that the uh over the entire stake say beta beta beta 1 is dishonest the the fact that over a some set of committee this is is less than beta is a probabilistic measure but it it it goes the the probability goes up very sharply so it's yeah there is some probability in there from that perspective yeah um can you explain validators honesty scoring more uh I not sure I fully understand the question if not we can move on and whoever asked a question can I guess re-clarify um [Music] so and we have the example has an honest amount of validators quite optimistic what about a more pessimistic scenario can validators be honest most of the time until they find something they vote adversarial um okay that's try if I understand the question correctly um I mean if this is the behavior you thinking about that's should be accounted in the beta so this Ru lies and belief that one minus beta they're honest and they will vote according um to the rule if some point if in the future some of them become Dison