- The speaker discusses decentralized sequences and QBFT (Quorum Byzantine Fault Tolerance) in the Ethereum Engineering Group meetup.
- Decentralized sequences involve a sequencer, prover, and prover contract in a ZK rollup system.
- Centralized sequences are currently used in systems like Scroll, Linear, and Polygon's EKVM.
- Designing a decentralized sequencer requires nodes to agree on transaction order and handle potential faults or malicious nodes.
- QBFT is a Byzantine fault tolerant consensus protocol that can be used for decentralized sequencers.
- The Byzantine generals problem is explained as a scenario where generals cannot gather in one place to collaborate and make decisions.
- BFT consensus can handle communication and information challenges in a distributed system with potentially malicious or faulty nodes.

- The piece discusses the challenges of handling potentially malicious or faulty nodes in distributed systems.
- It mentions various BFT (Byzantine Fault Tolerant) consensus protocols, including PBFT, Tendermint, Click, IBFT, Hot Stuff, and QBFT.
- The differences between these protocols lie in their approach to latency, messaging, rate round change, and their suitability for blockchain and Ethereum.
- QBFT offers instant finality, lower message complexity, lower latency, and formal verification, making it a potential choice for consensus protocol in GoEthereum-based systems.

- QBFT is a fork of GoEthereum with additional features and is managed by consensus.
- The protocol ensures consistency and liveness in the blockchain, even in the presence of potential attackers.
- QBFT allows for programmable block proposers and can be used with a POS algorithm.
- The block proposer sends a pre-prepare message with the proposed block to all nodes.
- Validators send prepare messages to gossip the proposed block.
- When a validator receives a quorum of prepare messages, it sends a commit message to finalize the block.
- QBFT handles signatures in the extra data field and requires a quorum of signatures for validation.
- Nodes set timers for block timeout and round timer for the next block.
- Round change messaging occurs rarely and increases the round timer exponentially.
- QBFT in GoEthereum was ported from Geth and deemed feature completed in 2021.
- Extraction of QBFT from the codebase requires filtering out unnecessary features.
- QBFT uses DevP2P sub protocols, including IBFT and ID64.

- The speaker discusses the differences between IBFT, IBFT2, and QBFT consensus algorithms.
- They mention the importance of having a contract on chain for validated voting, allowing for arbitrary business logic and the election of validators.
- The speaker is working on an EIP for the interface between a prover and a decentralized sequencer, with plans to publicly discuss it in January.
- They mention their thoughts on BFT consensus algorithms and their ongoing research on incorporating QBFT or other BFT algorithms with a proving system.
- The speaker mentions upcoming topics for discussion, including VS Code Solidity extension, Passport wallet, and decentralized sequencer-friendly consensus algorithms.
- They also mention the possibility of collaborating with others working on decentralized sequence improvement for linear.
- The speaker emphasizes the complexity of proof of consensus and the need to avoid locking into a specific consensus algorithm.
- They express their optimism about the future of Ethereum and the potential for innovation on Layer 2 solutions.

- The speaker mentions that someone is joining just as they are leaving
- They say goodbye to Peter and everyone else

- The speaker discusses decentralized sequences and QBFT (Quorum Byzantine Fault Tolerance) in the Ethereum Engineering Group meetup.
- QBFT is a Byzantine fault tolerant consensus protocol that can be used for decentralized sequencers.
- QBFT offers instant finality, lower message complexity, lower latency, and formal verification, making it a potential choice for consensus protocol in GoEthereum-based systems.
- QBFT handles signatures, block timeout, and round timer for the next block in a distributed system.
- QBFT in GoEthereum was ported from Geth and deemed feature completed in 2021.
- The speaker is working on an EIP for the interface between a prover and a decentralized sequencer, with plans to publicly discuss it in January.
- The speaker mentions ongoing research on incorporating QBFT or other BFT algorithms with a proving system.
- The speaker emphasizes the complexity of proof of consensus and the need to avoid locking into a specific consensus algorithm.
- The speaker expresses optimism about the future of Ethereum and the potential for innovation on Layer 2 solutions.

Slides are here: https://drive.google.com/file/d/1WpqvPbMFMlvrnL6Gx-7SZ8UTCEl1rEeL/view?usp=sharing

Peter Robinson described his thoughts on Decentralized Sequnecers, and why he thinks that BFT consensus algorithms are appropriate for this usage. He then does a deep dive on QBFT, for formally verified BFT consensus algorithm.

My name is Peter Robinson, and this is the Ethereum Engineering Group meetup.

So today, I've quickly put together a talk on decentralised sequences and QBFT.

And for people who are watching this going, but how do the 2 intersect?

And so hopefully by the end of this, you will be reasonably convinced that it's a good idea.

Okay, so can anyone or everyone see my slide?

So some of this talk is taken from a talk that Robert Roberto Saltini wrote, so just acknowledging that.

And so I'm going to talk about decentralized sequences, which I think is going to hopefully get you into the idea of why a BFT consensus is a good idea.

And then I'm going to go through QBFT in quite big detail.

And then I'm going to talk about ZK-friendly blockchain consensus protocols.

So, in a ZK rollup system, you have the rollup and normally it's rolling up to Ethereum, but the roll up could be rolling up to another roll up or another blockchain.

But let's just run with an L2 rolling up to an L1 where the L1 is Ethereum.

And so you have a sequencer, which is all about ordering transactions, you have a prover, which is creating the proof, the ZK proof.

And then you've got the prover contract, which is how you verify what's in the proof.

So the small bit of information that you put on Ethereum so that you're happy about the sequencer and prover having done the right things.

And so a user submits a transaction to the sequencer.

When you've got a whole heap of information, you a whole block or multiple blocks, the prover then requests information from the sequencer, and they get the block header.

At the start of each transaction, there is a state tree at that point.

It may be some information about bridging and also some information about consensus.

And then it generates a proof of the actual transactions have executed correctly, and that the storage has been updated and the state has been updated as per what's in the block header, and is able to prove that.

So at the moment, you know, if you look at any of these systems, say scroll or linear, or the polygons, EKVM, they're all using centralised sequences.

And so it could just be a block, a database as much as anything else.

It doesn't need to be any blockchain or anything because it's just a single node.

And so if you think about, you know, if you were going to design a decentralized sequencer, you're going to have different nodes, and they need to be able to fairly come to an agreement on the order of transactions.

Additionally, some of those nodes might be be malicious, or maybe just even misconfigured.

So, you know, when you think about that, that sounds a lot like a consensus protocol, you know, that's what they do, You have a shared distributed database, you have a lot of nodes, and you need to agree on the order of transactions, and some of them might be faulty.

And as well, before those blocks hit the prover, they need to be final, you know, there can be no suggestion of there could have been a fork, and you might prove something that's no longer real on the blockchain, that can't happen.

So you need finality to be deterministic, and it'd be awesome if it was fast finality, and even better single block finality, so that then the block on the blockchain gets proved, or gets finalised, and then you can prove it immediately.

So you don't have to wait, say, 20 blocks or something.

So when people talk about decentralised sequences, a big topic of conversation is well, how decentralised, you know, so we've been happy with centralised single node sequences, you know, databases, and you know, everyone's been popping champagne corks.

So do we really need to be fully 101% permissionless decentralised?

Does it need to be as decentralised as say, Ethereum?

Or could you just have say, 20 or 30 permission nodes?

And maybe that will be okay for some situations, maybe it'll be okay for all situations.

Maybe for some systems, it's a path to decentralisation, but not the end point.

So I think it's a valid way of doing things, though.

And so that whole let's use restricted number of nodes, probably not permissionless, then I think that's a Byzantine fault tolerant consensus protocol.

And so that means that your decentralized sequencer could be for instance, a QBFT blockchain network.

So I've said BFT a lot, but what's it actually mean?

So consensus is all about agreement across a distributed system.

And you know, blockchains need to agree on the canonical blockchain.

So the order of transactions in blocks, the order of blocks in the blockchain.

And so I was using Bing, which uses Dali to create images.

And I said, Byzantine generals problem, give me the picture.

And so it gave me this, but before I go on, can anyone tell me what is the problem with this picture?

I'm pretty useless at guessing, but I mean, it looks like Not everyone can see what's happening there.

You've got, yeah, I mean, there's a lot of people looking on and just a few people sitting around the table.

And it's quite a big scroll, you can't necessarily see everything that's written there.

Okay, well, I mean, the insufficient information is actually a good point.

But for me, the whole idea of the Byzantine generals problem is, the generals can't gather in 1 spot, that they specifically can't gather around 1 table to get an opinion because they're essentially a decentralised system.

And so they each have their own perspective on the world, but then they can't, they can send messages to each other.

But they can't actually collaborate in 1 place.

So, and so use the, the diagram from Wikipedia, which more, you know, easily, I think, demonstrates it where you've, so the definition of a Byzantine fault is a condition of a computer system, particularly a distributed computer system where components may fail, but you've got imperfect information on whether the component has failed or not.

And so when you look at this, this side, this diagram here, you've got those 6 generals around and they've got their 6 armies that are going to attack a fort, but they can't talk to each other directly, they can't gather around that table.

And so, you know, they don't, they can have the idea, we're all going to attack at dawn.

And they all know if they all attack at once, it's a positive outcome.

If they all retreat, another positive outcome, maybe, you know, no 1 gets hurt.

If some attack and some retreat, then it's going to be disaster because then the people in the fort will be able to take them on successfully and kill them all.

So the idea is of this Byzantine generals problem is being able to communicate with insufficient information in a distributed system, and also handle the fact that maybe some of those generals might have been paid off by the people in the fort to act maliciously.

Or maybe the messengers who are communicating between the generals disappear, they don't make it.

Yeah, so what happens if they're malicious?

And what happens if some of the messenger riders between the generals are captured?

So a BFT consensus is Byzantine fault tolerant.

So it can handle this sort of problem where you've got potentially malicious nodes, potentially just even faulty nodes where maybe they go offline, or maybe the network connection goes offline.

And so in my experience of working with these sorts of systems, The reason why you have these failures is misconfiguration.

So 1 of the nodes, maybe hasn't upgraded to the latest fork, fork goes live, it goes off the air, or some other misconfiguration.

Network file is a really quite a common issue in a hugely distributed system.

So hard disks die, you know, the switch dies, bits happen.

Invariably though, the malicious behaviour could come down to a node, bit of software has been hacked, has been taken over by a malicious actor.

So even though you trust the company to operate their node, they might not have good operational security.

So their node might get taken over, and then it might do malicious stuff.

So when trying to understand BFT consensus protocols, it's worthwhile trying to understand the history of them.

And so we've got back in 1982, We've got Lamport and co came up with the Byzantine generals problem.

And then in 1999, Castro and Liskov produced the paper on PBFT, so Practical Byzantine Fault Tolerant.

The Bitcoin paper talked about blockchains and ideas around that and worrying about faulty nodes and malicious nodes, And so probably was inspired by those 2 papers.

And that led to Tendermint in 2014, which tried to come up with a way of having a PBFT algorithm that would work for blockchain.

Then, in 2017, early, we had Click, putting as an EIP, which is a non-BFT algorithm that works on Ethereum.

And then we had IBFT, and it sort of, it was, well, let's take the ideas from CLIC and the ideas from PBFT to create a BFT for Ethereum.

However, it had some issues and so then Roberto Saltini and others, being David Highland Wood, created IBFT2, which fixed the safety and liveness issues.

At the same time, some other people came up with an algorithm called Hot Stuff, which tried to fix some of the scaling problems that you've got with IBFT, but increased latency.

And then lots of variations have been created based on Hot Stuff.

Importantly, the second author of Hot Stuff created Hot Stuff 2 earlier this year.

The Ethereum and Enterprise Ethereum Alliance created QBFT in 2020.

And it is IBFT2 with very, very slight changes.

And so but it's also been formally verified.

And so, yeah, noting very clearly that click is not BFT.

So don't think click or click as a BFT algorithm.

So when you're trying to understand BFT algorithms, it's good to understand the commonalities.

And so for all the PBFT and anything that inherits from it, it has this 3 step approach where the block proposer is somehow rather elected.

And then it sends out a message to everyone saying, hey, here's a block.

And then all the other valid all the validators then communicate by some mechanism and say, yep, we've seen it, we've we're locked on to that block.

And then there's agreement, because everyone can see that everyone else is going to be cool with that block and they've all voted on that block.

And they say, all right, let's commit the block and then it's committed.

And so all of the algorithms have that in common that basic, here's a block, we've seen the block, let's commit it, 3 phase activity.

Where the differences come is around this trade offs between latency and messaging.

And so is it the block proposer send messages to everyone, they send messages back to the block proposer, and they do that process multiple times, which ends up being higher latency.

Do all the validators communicate with all the validators, which is PBFT, or do all the validators communicate with all the validators, which is PBFT, or do all the validators communicate with all the validators, but they also use gossip, so they don't have to be connected with, say, you had 1,000 validators, they don't need to be connected with all 1,000 directly.

And so you've got IBFT, IBFT2 and QBFT, use that all to all.

But you've got higher message complexity, which means the messages are larger, potentially.

And also, the other big difference between the different protocols is how do they handle rate round change, and that's when there's a failure.

So the another thing to think through is, well, which of them were designed for blockchain?

And so all the ones along there, Tendermint and beyond, are all designed for blockchain.

Another thing is, well, what about Ethereum?

Which ones have had Ethereum in mind when they've been developing the algorithm.

And trying to bring it down into more detail.

The hot stuff, because of their mechanism of block-proposal-to-all-nodes-and-back-again, they have a lower message complexity.

So the message size is smaller, whereas it's of n squared.

So it essentially can binds more messages together and includes messages within messages.

If there's a failure case, IBFT and IBFT had N cubed message size, whereas QBFT is N squared.

And Tendermint is FN squared, but then there are some other parts to it where a lot more messages end up getting sent.

And Hotstuff and Hotstuff 2, F is the number of faulty nodes, so it's less.

Latency, though, then is a huge difference where hot stuff, the latency is really high, whereas in QBFT, tend to mint it's lower.

Safety is, is the, you know, if you produce a block, is, you know, is that correct?

Is it have we updated to the right state?

And so we've got a yes for all the QBFT, IBFT and everything, but not the original IBFT.

Liveness is, could the blockchain get to a state where it can't produce any more blocks?

Responsiveness is around, is there a situation in which the consensus protocol could get to the point where to produce another block could take a very, very long time?

And tendermint in certain value situations can take quite a while to produce another block.

Formal verification is another important piece, which is proving that the algorithm is actually correct and doesn't contain bugs.

So QBFTs are yes for that, whereas TenderMint and HotStuff, they've got some parts of the protocol done, but not the whole protocol.

And HotStuff too is too new, so it doesn't have it.

For those people being immutable, we're using GoEthereum as our code base, And so having a consensus protocol that's Go Ethereum based, or even could work on the beacon chain client would be a real bonus.

And zk-friendly slash contractor validator set.

So that's definitely a yes for these and not so sure for these others.

And I'll explain that a little bit more later on.

Actually, I'm not going to explain it in this talk completely.

So how does QBFT work and what does that Q stand for?

And so Quorum was a blockchain client that JP Morgan created.

It was a fork of GoEthereum back from 2016-17, and it contains many of the features of modern Ethereum, but it sort of misses some, and it has a whole heap of extra features.

And is now managed and maintained by consensus.

So the protocol has the following properties.

So it gives you consistency, so you don't get forking.

So you can't have the diagram on the right there where you have alternative blocks at the same height, you always will end up assuming honest nodes with the same sets of blocks in the blockchain.

So you'll have in an append only fashion.

So you'll have honest nodes will put blocks on the end of other blocks.

And liveness, you won't get a situation where you can't add more blocks.

And all of this has to be despite there potentially being attackers who could collude to attack the system.

And so the maximum theoretical resilience of the protocol is that equation over there.

And as you can see with this table, as you end up putting more nodes in, you can handle more faulty nodes.

So with QBFT, the block proposer can be rotating, so it changes each time, or it can be sticky where it stays the same until the block proposer fails.

And this whole block proposer piece is programmable.

So potentially, you could create a POS algorithm over the top of QBFT for choosing the next validator.

And in fact, that's something that immutable with that mutable we're going to do.

So the following slides assume a rotating block proposer.

And so in the system, so imagine we've got 4 validators, and you've got the block proposer.

So you've got the block period, and then you've got a round timer.

So you do multiple rounds trying to create a block.

And so for our system, the block period is going to be 2 seconds.

And for the round timer, it's by default 10 seconds.

So I think we should probably set that to something lower like 2.1 seconds or something like that.

So the all the validators know which validator is the block proposal because there's a deterministic algorithm that selects it.

So they all know for this round, and for this block, this validator is the block proposer.

And so it sends out a pre prepare message containing the proposed block to all the nodes.

And it also virtually sends that message to itself.

So whenever you see a message being sent out to all nodes, logically think as well, even though I'm not drawing it on the diagram, that it's also being sent to itself.

So when you're trying to calculate how many messages has it had, base it on that.

So then All of the nodes then, validated nodes, then gossip to all the other nodes that there's a prepare message saying, hey, let's use this block.

You know, and that we're going to use it for this block height.

And again, reiterating, about when I say gossiping, remember that we're using devp2p, which uses Cademlia, and So each of those buckets can hold 256 nodes.

So even in the local pool, it would have 256, but then it's got 256 slots of 256.

So you're going to have to have a lot of nodes before it's not going to be a direct connect.

And so when a validator node has received a quorum of prepare messages, so remembering that it counts its own message that it's sent out, then it's ready to send out a commit message.

And so, then the, so when the validators receive a quorum of commit messages, that is 3, including the 1 it sent itself, it finalizes the block and adds it to its local blockchain.

And so all nodes send out that fully signed block to all other nodes in the network.

And so this is just a standard Ethereum message saying, hey, here's a new block.

And in that way, even if only 1 of those block validators gets everything done in time, you will still have a valid block.

So something to note about QBFT is that, say, validator v1, it's going to have a certain block with a certain set of signatures, but the other validators might have a different set of signatures.

It's going to depend on which of the other validators connected to it first, sent its message first, and it received first.

So if it received a message from V4, V3 and V2 first, then it would have that.

And so the signatures are put in the extra data field and are not covered by the actual block hash signature.

And so hence It doesn't matter which of them are there as long as there are a quorum number of them there.

And so when each node receives a quorum number of these commit messages, it sets a timer to the end of the block period.

So it sets a timer so that say if they finish all the messaging they need to, they've produced the block, and they're only say 1 second in or 1 and a half seconds in, then they'll set that for say 1 second or half a second, so that they keep up that 2 second block period.

And then each node then will have that block timeout at around about the same time.

And then Each node will set up their round timer for the next block.

And if you're the block proposer, then you'll send out that pre-prepare message again to all the other nodes.

And so if, say, not all the messages make it, for instance, and you don't receive the expected 1, then you'll do a round change.

But this round change messaging should only happen really rarely.

And so how round change works is that you have that timer.

And so say that timer goes off before all of these messages had completed.

So before we were ready to do the commit message.

Then instead, the timer goes off and then you all, all the nodes will send out a round change message.

And yeah, and so if that happens, again, then the round time, the round timer for round 1 is exponentially larger.

And then round 2 will be twice as large as round 1.

So the idea is to double the round timer each time to try and help ensure that you get a block done in time.

Yeah, and so that will just kick off the block production again.

So the code was ported from Geth in 2016, maybe or maybe it was early 2017.

And there were changes taken from upstream, but not all.

And the codebase was deemed feature completed in 2021.

So they're doing changes, but there's no major feature development.

And so the many of the features that or other, they've got a lot of different features in the code base.

So if you're trying to extract UBFT from the code base, you do need to do a bit of extraction of just the right features and not all the private transaction stuff and the node permissioning and smart empty block handling and all the other other stuff because you don't need it.

So not covered in the spec or the paper, but in QBFT, you've got the dev P2P sub protocols a part of Ethereum.

And so IBFT, which is the original, it used a DevP2P sub protocol called ID64.

Because at the time, we're running up to F63.

See all Ethereum Engineering Group transcripts on Youtube

Decentralized Sequencers & QBFT