Consensus in the era of low latency - Alejandro Ranchal Pedrosa

Transcript

[music] All right. Hello everyone. I'm Alejandro from Saleaps. Oh, this is not great. Anyways, I'll take you through it. Um, so I'm Alejandro from Sale. I'm going to be talking about consensus in the era of low latency. First, let's set a bit of the foundations. You know, quite what's the state of consensus at the moment? Where do we come from? This is not showing at all the same thing that I'm seeing here. But anyways, uh so basically I like to see consensus evolution as three five generations.

First we have the uh the beginning of consensus with like you know classical consensus protocols like PBFT. Um then first generation starts with Bitcoin where we finally have some civil resistant mechanism to have an open system for consensus but um it completely bypasses BFT consensus protocols and the result of it is to get probabilistic finality that takes a long time and relies on synchrony assumptions and whatnot. Um that's also at the time where Ethereum start right then. Um from there we have a big change in Ethereum with proof of stake right. Um instead of relying on you know some tying civil resistance to some real resource we have some deposits of some virtual coin that represents the amount of power that

somebody has in the system. And then uh an interesting key takeaway from this slide is that in generation 3 this starts happening some trade-off right in order to which is embodied by Solana right in order to um reach more users more applications they they need to get more throughput and lower latency and in order to get that at the time they traded security and decentralization instead of having a system that's so decentralized at Ethereum and having that one of the primary values and primary goals um they just come up with a consensus protocol that has never really been proven correct and um and and like you know much less validators and just be a lot faster and that is a trend that has continued for a while. It

has gotten a a little bit better in Solana itself as well and um there has been also some other um key um breakthroughs like the decoupling of uh data dissemination ordering and execution so that they don't happen in a sequential manner in order to increase throughput reduce latency. Um but this trade this um trend of focusing on low latency has really taken the space by storm and really caused a shift in the space and you can see that even in Ethereum here highlighted are some of course this by the way this is not a slide that represents uh all the possible chains or you know it's kind of opinionated um but yeah so here here you have in red some of the chains that are either Ethereum one or rollups of

Ethereum and in blue chains that are uh EVM that are tied to Ethereum somehow Right. And um in the case of Ethereum in order to compete in this space of uh not so much caring about security and decentralization but putting first throughput and latency what they did is the roll of centric road mapap right let's just like have single sequencers but they eventually settle on chain and that's how we get like this trade-off and we get to compete with like Solana with others that are able to provide services that Ethereum main chain is not able to provide because of these uh challenges that giving a lot of the centralization. a lot of security um entails and that on the other hand this is okay well that in the other hand cause a

little bit of a confusion complications in the Ethereum ecosystem because finality became a fuzzy word right consensus is there in order to provide finality in order to provide a guarantee that everybody agrees on something and that that thing will not be reverted and it used to in BFT chains this is very simple right is whenever a super majority of the people vote on something that is settled that is final but now with Ethereum and the Ethereum in the rollentric road map um we have many stages where somebody might consider finality and it's actually growing this year has grown by one more with the fast confirmation rule so imagine you have Alice that uses some neo bank which is a web three app in some rollup and this is a secret rollup and this roll up

eventually commits and set on ethereum so and I'm a merchant and Alice pays to me for some product right at which point do I give off my product I could give my product when Alice Alice pays me, right? When Alice says that she's going to pay and that will be instant finality, right? But I I get no security, right? If Alice misbehaves, I don't get paid. What I can wait for the Neo Bank to say, "Oh, you know, Alice has sent the transaction, so you will probably get paid." Um, and then of course the risk is that I'm trusting the Neo Bank. Another stage that I can wait for is the pre-MP of the rollup, right? The rollup says in the in this the rollup includes the transaction where Alice pays to me in the next block. But of course that still has the risk as Adria was saying

is a single sequencer. I'm just trusting this rollup to eventually commit this onchain. This is not Ethereum level security. And this is a key point that is is like often forgotten I think nowadays and is not talked about enough. Um then I could wait for commitment right of the rollup state. And at that point I start getting from 12 seconds to 12 minutes depending on how much I wait for increasing security increasing uh probability that my transaction that like the commitment transaction that appears onchain will not get reverted. And then after the 12 here there's a a side note that with the current proposal of the fast confirmation rule under some different assumptions like synchrony and at most 25% of the stake being controlled by an

adversary you can actually get um finality not probabilistic finality but finality within one slot within 12 seconds. Um another thing I can do I can wait a bit longer and eventually get offchain finality right I get the finality of the commitment. So that happens at the current moment with Gasper in about 12 to 18 minutes. However, this is for the commitment. So if I want to make sure that this transaction is valid, I need to execute it myself. I need to run a full note of this uh rollup. So if I don't want to do that, if I'm running a light client, then I need to wait for settlement. And that imagine that in this CK rollout that happens every hour they submit a settlement. I know some of the rollups are happening faster at the moment. Then

I need to wait one hour and the same thing, right? probabilistic on chain finality or maybe trusting synchrony and like a small stake adversary not existing in the chain to get the fast confirmation rule level of finality or the final final final final final finality which in this case will have it after an hour and 18 minutes which is not ideal right now this is getting better right I already talked about the fast confirmation rule that's already being implemented by clients it doesn't require any changes on the protocol it hasn't been done I'm not I'm not implementing that at all with some of my colleagues um some of which are the Etheum foundation and uh yeah so this is just involves just looking at the existing information available in the network and creating a newistic and there's some assumptions that give you a

guarantee of finality a guarantee that gasper of the finality gadget will eventually finalize the fork that contains this transaction in that order um the assumption as I said is less than 25% of the stake being controlled by an adversary and synchrony synchrony in the sense of if there is a message that disagrees with what I'm seeing that message is not more than 12 seconds old and that gives you finality in one slot. Another thing that's happened that's important uh in order to decrease the amount of time that it takes to get two rounds of voting in a finality gadget in order to get deterministic economic security level finality is the decoupling of uh the available layer epochs and the voting rounds in in the finality gadget which is also very

interesting by made by my colleague Luca. And uh imagine based on the publicly available information a future where we have all of these that I'm that that has been proposed implemented in Ethereum and let's compare it with a state-of-the-art and again this is uh not great um [laughter] okay well I don't know if you see anything I think you don't see anything do you do you see okay do you see the finality at least >> okay good okay well the point is um here's like some chains that are uh competitors to well not compet I don't think any of these chains are competitors to Ethereum. Ethereum is a whole other kind of monster because of the number of validators that it has because of the high values that it has in terms of decentralization and

security. But here's some of the other L1 level chains that have decentralized consensus as well BS consensus and what is the finality that they get right the deterministic economic security for their systems. And what you can see is in all of them we're getting in the case of say for example at work we're getting like 200 millconds right for finality. So every you you get an economic tick every 200 millconds. Um in the case of Ethereum the most optimistic current scenario you pro it would probably take 30 to 90 seconds currently with the if we implemented the latest consensus proposals for Ethereum but that's because we have a million validators virtual which hopefully gets reduced by one or two orders of magnitude but that's still like four five orders of

magnitude more validators than any other competitor that I'm showing here. So of course it's really hard to compete in that environment. Um but still there's some interesting takeaways that that we can look at from uh these other chains that have been really really extra extremely focused on low latency and what they have been doing in order to optimize to those levels. uh one which is already being looked at at the peer-to-peer layer of Ethereum is eraser reless coding right instead of disseminating data to everyone sharded well it's actually being used also for data availability sampling even at the CKVM level is now being proposed for the execution layer um another one I don't want to push too much for that one in this talk although tomorrow I'm talking a bit more about that about the benefits

of that uh but I think it's important there has been proposals in Ethereum with braids with fosil fosil of having multicurrent proposers And I think that's super important for me and censorship resistance. Um but uh but yeah, it's it's it's perhaps not the time at the moment uh to look at in in the Ethereum ecosystem. Another low hanging fruit is pipelining consensus iterations of the finality gadget uh which is also known as nottorizing uh the notoriization threshold. A very interesting one that u we are implementing at say at the moment and it's also being worked at is I'm collaborating with some colleagues Ethereum to to look into these things is um in a consensus protocols you typically typically have a leader that proposes a value which is good because it gives you a synchronization point. So

it reduces by a message delay the uh amount of uh rounds that you need for voting in order to get a decision and everybody agree on something. But the problem is if the leader is offline or is too slow you lose an entire slot, right? you lose an entire timeout and then you have to try again with a new leader. We are actually at the moment working into having a graceful fallback into a leaderless asynchronous protocol so that there's the main leaderbased protocol that is a good case but if the leader is offline the leaderless protocol has already prepared an alternative. So it only takes one more message delay to actually get a decision. And even in those cases something that could happen is that because it's leaderless, it could happen that some people vote for what value and another was in the good

case and he voted for the value of the original leader. Um and in those case even it's actually safe to finalize the common prefix among them. So remember this is a finite gadget. So there's a high probability of people that are proposing things to finalize propose something that may have may not be the same thing. There may be a fork but there's a like high likelihood of having some common prefix between them. So in that case you can even reuse votes for different values in order to finalize the common prefix. But the one that I want to focus the most on in this talk in the remainder of this talk is switching to one round of voting. I don't know if you know what that is, but in the in BFD consensus, in order to get optimal resilience, so tolerating up to a third of bisentine faults, you need to

run to voting. And that has been the holy grail up until recently because of the pressure on low latency because that's another another uh message delay that it in that it includes. And now there has been all these actually pretty much three out of the four competitors that I showed before have switched to just having one round of voting which implies a reduction in bisantine full tolerance from a third of the bisonantine particip of participants being bentine to a fifth right 20%. Um this is something that was already being discussed. I can show here um a post by Vitali where she's kind of like pushing for that. And actually the quote to that tweet by Roger Vatenhoffer the head of research at Anza Sana that gets a bit alarmed about this. Uh but side note Sana is also also proposing something

similar. Um but actually um I actually want to push for it. I actually want to say that means more economic security when so it's counterintuitive. How can it be? I also was like a bit um you know for me the values of security and decentralization are very important and I was a bit alarmed when like there was this shift because of the pressure of low latency to just have a one round of voting and decrease by something tolerance but when you think about it harder especially for the finality gadget meaning Ethereum will always be available if the finality gadget might not generate decisions if there's a period where you have a lot of crashes but the available chain will continue producing blocks um whereas in Solana if if like more than 30 if like enough uh nodes crash there's just no production

at all. So that's a key difference in Ethereum. The point of the finality gadget to is to get economic security and because of the nature of having one round of voting meaning that you need to increase the threshold so the number of votes that you need to wait for in order to get decision from 66% to 80%. It actually means that if you're smart about how you design these consensus protocols, you get an economic security increase from 33% in the current case with Casper in the worst case current case of Casper to up to 60 to 80%. So 60% in the worst case with the with one round of voting and 80% in the good case. So it's a fantastic increase in economic security actually. And um so yeah this is the the key the key the key

thing that if you want to take anything away from this talk. Let it be that it is not true that you need to be alarmed because of a discussion to switch to one round of voting in Ethereum for the finality gadget to get low latency on finality. It's actually the system where it makes the most sense because every round of voting in Ethereum is millions of validators voting. So it's an incredible uh saving in terms of time and because also it's an epon flow protocol so it always will be available. So the key point of the finite gadget is to provide safety not to provide livveness and actually increasing the threshold reduces livveness of the finality gadget but it increases safety.

So this is a no-brainer and um actually in this post I was lying before it wasn't talking about uh so it's talking about one round of voting but not tolerating 20% of basentine faults in the fanatic gadget is actually even less it's 17%. Um and the reason is because of the notoriization threshold and the properties of web and flow protocols. In order to have uh basically synchronous safety of the available layer against an adversary controlling 50% of the stake, you need to have a threshold in one round of voting of 83% instead of 80 and that means tolerating a bisonantine adversary controlling at most 70% of the stake. What that means is that you is there's even the proposal by Vitalic in this tweet is to even go

even a bit farther on safety for the FIT gadget and a bit and you know trade in a little bit less of lightness on the FIT gadget. But that sounds to me that sounds great. That sounds like a fantastic idea and we should it should be something that we should be pushing for and it could be the way to get compet like competing results in latency even though you have inc like Ethereum has an incredible amount of validators with these other chains that have in the order of hundreds or tens or at most thousands of validators. So yeah, that that was all.

[music]