Roberto is a researcher specializing in distributed systems and formal verification, with extensive involvement in the Ethereum ecosystem since 2017. His early work includes the design and formal verification of Byzantine Fault Tolerant (BFT) consensus protocols, such as QBFT, as well as contributions to Distributed Validator Technology (DVT). More recently, his focus has shifted to advancing the Ethereum consensus layer protocol and ensuring its security.

Roberto Saltini

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

Stage 1

I am a research scientist at the Ethereum Foundation where I am involved in the long-term improvements of Ethereum’s consensus protocol. My research is currently centered around faster finality protocols for Ethereum. More generally, my research interests include blockchains, distributed systems, and consensus protocols.

Luca Zanolini

A Fast Confirmation Rule for Ethereum

 Hi everyone, I am Luca Zanolini and today together with Roberto Saltini we are going to give you an overview of our fast confirmation rule for the Ethereum consensus protocol. This is a joint work with Aditya, Francesco, and Cheney. So let's start by answering this question, what is a confirmation rule? 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, it's basically the output of the fortress function, but let's just stick with the chain followed by the honest validator. Our fast confirmation rule is an algorithm that enables nodes that run this algorithm to identify blocks that will never leave the canonical chain, assuming good network conditions. Basically, this algorithm outputs 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 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. 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 are out of the scope of this overview. Okay. Why do we need a fast confirmation rule in the first place? So today, the way to know whether a block will always be in the canonical chain is through finalization. The problem is that with the currently implemented protocol, finalization takes up to 13 minutes in the best case scenario. protocol, finalisation 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 blocks are appended on top of a block, the higher was the likelihood that this block remained confirmed. Because in the current protocol, we have seen 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. So with a fast confirmation rule, what does a fast confirmation rule give us? For sure, it gives us improvement on the user experience in Ethereum because having faster confirmation rule implies that small values transaction can, in some sense, don't have to wait for finality, but they can already immediately be assumed as confirmed, implying that they will eventually get finalised. Moreover, it reduces also risk trade, basically trade reversal made by forex changes that allow to optimistically trade immediately upon deposit. And moreover, it improves also reliability of some wallets. In particular, there are wallets that tell users that a transaction is already confirmed upon entering, upon including in the block. But as we said before, because of this possibility of a balancing attack, this doesn't really tell us anything meaningful. So having a fast confirmation rule can really improve also reliability of wallets in general. It's also useful for PBS in the sense that it provides block builders with an indication whether the block that they are building upon is actually not going to be re-org'd. 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 is because Roberto will introduce some technical terms that is better if we are all synchronized on that. Casper is 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 blocks that are outputted by this LMD ghost. Basically, it finalizes blocks on this canonical chain. The time unit in Gasper is a slot. A slot lasts 12 seconds. 32 slots define an epoch. For every epoch, the set of validators is partitioned in 32 disjoint committees. epoch the set of validators is partitioned 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 on top of the head of the canonical chain and and the other validators in the committee will just cast a vote ideally for the block that has just been proposed. How validators choose which is the head of the canonical chain, they do it through the fork choice function. Fork choice function selects 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 append a 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. Now let's dig into the information that we have. So we have to be able to determine the weight of this chain. Now let's dig into the rule and Roberto. Thank you Luca for setting the stage with all the concepts we need to understand how the confirmation rule works. So let's start with some assumptions we rely on. The first one, we rely on the fact that votes sent by validators are received by other honest validators by the end of the slot. The second assumption is that we assume that there exists a maximum beta fraction of dishonest 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 1 minus beta is for sure honest. Okay, as Luca mentioned, we cannot rely on chain depth at all. We do need to rely and look at the weight of the LMD ghost vaults. How do we do this? Well, let's start by assuming this block B10 is canonical for now. For our example, we use beta 0.2, 20 per cent. Then we assume also for simplicity that the weight of a committee is 100. Now what we are going to require is S represents the support, the weight of LMD GOST that goes towards block B11. We require that the S is larger than W multiplied by half plus beta. We'll see why. But just running through the samples, in our case, this means S of B11 more than 70, and we pick 71. We know that any other block for this slot that is conflicting with V11 has no more than, actually, it has less than half W volts, which means less than 50. Let's pick 49. What is the worst case scenario? Well, the worst case scenario is that beta of the stake equivocates. With beta of the stake equivocates. the stake equivocates, then 20, weight of 20 is subtracted from 71. We have 51 for B11 and 49 for anyone else. Well, B1 wins the choice. With this rule, we can say B1 is canonical. 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. 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 slot? example, when we go to the next lot. So let's move to the next lot. example. the committee weight goes to 200. votes for B13, these votes, 80, goes to B11. we have B11 as a weight of 131, but what we need is higher. We need 200 multiplied by beta plus half. We need 140. So we're not quite there, and what does this mean? Is B still going to be canonical? Well, 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 H. H represents the votes for B11 that are from honest validators. Bear with me, we'll go over this honest thing later. And J represents the validator, the stake in the committee. committee. represents the stake in the committee that is honest. is that H of B11 is larger than half the committee. clearly this will make B11 win the fork choice. the fork choice. we are going to work with which is this, we are going to require J, which is the honest committee, divided by 1 minus beta. condition implies the first one. Can show you by running, using our numbers, we get HB11 more than 50. We just pick 51 for now. So what happens when, OK, sorry, I forgot this. We use a, we define an indicator, p, for usefulness of 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 note? Let's have a look. Okay, the committee increases to 200, the B11 increases to 160. Now everybody that is honest vote for B13. 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 we wanted. As we showed before, this actually implies that the B11 is at least more than half of the possible votes. So B11 will be canonical. Now, for those who actually know intimately GASPR, they might ask, well, when you cross the epoch, things are not exactly like that. But I show you that that's not a problem. So what happens when you cross the epoch is that it's possible you have a new validator set that is sampled, but it's possible that in the new slot you have validators that have already voted before. So in this example, we assume that the honest committee only increases by X, some X of some sort. So in the new slot, 80, or the honest one, will vote in support of B13, and the honest one will vote in support of B13 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, it's 51 plus X over 80 plus X. Because X is added both above and below the line and 51 is less than X, so the new slot is 51 plus x over 80 plus x. Because x is added both 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 achieved, what we have shown is p, this indicator p, never decreases. So once it's higher than our target, which is half divided by one minus beta, we know B1 will be canonical forever. But now, how do we measure P? Well, lucky for us, if we use our initial fraction, which is S over W to be larger than half plus beta, Actually, this implies the threshold that we want for P. So I left it one last thing. Oh, sorry. So basically what we have is that if you have this, the Q, which is what we mean to be defined to be S on W to be more than half plus beta, this implies that our threshold on P and that B11 will be canonical forever. One last thing, 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 B11, then we go back to B10, to B9 until we get to the finalised block. So in terms of LMD cost, that's all we need in terms of confirmation rule. Things get a bit more complex when we add FFG-Gasper. So with FFG-Gasper, the fault choice gets a bit more complex. We start from the latest justified checkpoint, which is roughly the checkpoint that is ready to become finalised. 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 block B is canonical forever, we apply the rule that we saw before for LMDGhost, and then we need to work out a series of conditions that ensure that B will never be filtered out by the effect of integrating LMDGhost with Casper. This amounts to, in our case, we require that the checkpoint justified by block B is from the previous epoch. This ensures that in the current epoch, block B is not going to be filtered out. And then we have this more complex condition, which I'll break down soon, which ensures that B will not be filtered out in any future epoch as well. So what we're going to do in this condition, the the will not be filtered out in any future epoch as well. So what we are going to do in this condition, we look at the weight of check point of B, we remove the maximum amount of those votes that can be slashed because perhaps they are Byzantine, 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 2 third of the total stake. What this gives us, it gives us the checkpoint B the the this gives us the checkpoint B has enough votes to be justified. assumption, this checkpoint of block B will be next epoch, and then because we know that And then because we know that every honest validator only votes for a descendant of B, if there is any checkpoint in a future epoch 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 that are due toi Circle. Hvala Circle, ker jih je pripravljen. Načrtovno je tudi postavka na blogu, tako da se pripravite. Svetovnika je izpralna za šest dni. V tih šest dni so izpralni 56 blokov, ki so bili preizv 56 blocks that were reorgs, some also were two block reorgs. The implementation was a proof of concept, there were some approximations. So for example, they were polling VCO nodes every 10 seconds rather than running the confirmation rule at the beginning of each slot. Also they were estimating the FFG weight using just the LMD weight. However, the results are very encouraging. First of all, none of the reorgs were ever confirmed, no matter the value of beta. So this gives quite good confidence of the security provided by this rule. security provided by this rule. Second, in terms of performance, what they saw was that if you fix beta to be around 20% of the stake, you could see confirmation in four, five slots. If you go up to 30%, you get to eight, nine slots. However, we think, this has to be proved in practice, that if the rule is implemented by running it at the beginning of a slot, then we should be able to confirm 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 confirmation rule on a Bitcoin node, reach out to us. 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 if you are interested that's all, thank you applause okay cool I'm going to approach from behind and push you towards the middle as we address questions. So we'll start from the top. Seems like confirmation rule will get obsolete with single slot finality. Does it make sense to work on it at this time? Seems a question we asked ourselves. . 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 helpful in some sense while waiting for single slot finality. But yes, once single slot 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 difficult, that doesn't require any hard fork. It's not that difficult to, I wouldn't be the one implementing it, but I don't think it's difficult to implement, so it wouldn't take that long, and provides good benefit in the meantime, yeah. Okay, cool. The UI is not updating. How do you estimate beta? Is it a new parameter? It's user subjective belief on the value of beta. So the user picks their beta that they believe is the maximum and they query. And according to what they believe is they get the result accordingly. Well, can a confirmed transaction still be affected by a reorg? As I said, one of the assumptions is that votes are delivered by the end of the slot. If there is a network partitioning, this is not true anymore. Yes, it can be affected by reorg. So, it's not as safe as finality, but it's quicker. It's a sort of trade-off. What is the recommended value of beta you suggest? Is it 0.2? and how does it impact security? That's a very good question. Of course, beta cannot be larger than 30%. In other aspects and some, for example, that work on EPBS that's been 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, you know, we have this assumption saying we take any sequence of slots and the maximum beta of the stake is dishonest. As you know, the committee sampled randomly, and so when you cross actually the epoch, you have some probability measure that if you assume that over the entire stake, say beta 1 is dishonest, the fact that over some set of committee this is less than beta is a probabilistic measure, but the probability goes up very sharply. So, yeah, there is some probability from that perspective. Can you explain validator's honesty scoring more? I'm not sure I fully understand the question. I'm trying to fully understand the question. If not, we can move on and whoever asked the question can, I guess, re-clarify. So then 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? Okay, that's right. If I understand the question correctly, I mean if this is the behavior you're thinking about that should be accounting the data, so thinking about that should be a count in the data. So this rule relies on belief that one minus beta, they're honest and they will vote according to the rule. If some point, if in the future, some of them become dishonest,

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6736ce9e9dbb7a90e1f57ba7.vtt