See all Parallel Polis transcripts on Youtube

Hello, everyone. My name is Toggl. I work at Scroll. I do mostly research and shitpost on Twitter. And today we're going to be talking about sequencer and prover separation in 0 knowledge rollups.

So, let's start with the roles that zero-knowledge rollups have in terms of protocol participants. So we have a sequencer and we have provers. So what is a sequencer? A sequencer is an entity in the network that is responsible for ordering transactions. So you can imagine if you're a user, you generate a transaction, you send it through your wallet, the sequencer picks up those transactions, constructs blocks, or in this case, batches out of them, and submits them to the base layer.

So in our case, it will be Ethereum. And you have provers. The provers are responsible for computing the validity proofs for those batches that were committed by the sequencers. And basically, what those validity proofs allow us to do is they allow us to prove that the transactions that were added were correctly executed and the state that was derived from them was correct. And this allows us to have the communication with the underlying base layer.

And the way it works is this. As you can see, you have a sequencer, a prover, and Ethereum, which is the base layer with which the sequencers and provers communicate. And first, the sequencer publishes a batch. And then after the batch is published, it also propagates a batch to the prover or the contents of the batch, the blocks. And the prover computes the proof and publishes the validity proof on chain.

And that's it, you have the finalized batch. Another question is, it's all good, but how do we decentralize it? Because unfortunately, all the current roll-ups and all the construction that are going to come in the next few months are going to be completely centralized. And While it might seem just fairly trivial to decentralize things, it's actually quite complicated and there are things that you need to consider. It's actually paradoxically, it's difficult, it's more difficult to decentralize an L2 than an L1.

And let's start with the sequencers. So how do you decentralize a sequencer? Well, an obvious answer would be slap some classic consensus mechanism, so what you would call a BFT consensus, So Tendermint, hot stuff, et cetera. And that's it. Call it quits.

Or maybe base rollups. And I'll explain what base rollups are later. So advantages of a classic consensus mechanism is you have fast confirmation times, which means, let's say, if you're submitting a batch to the base layer, if you don't have an external consensus or some kind of economic confirmation, you have to wait for Ethereum to finalize, which is usually quite slow. And using a classic consensus mechanism allows you to have off-chain economic guarantees that your transactions will be added at some point in a given order. And another big advantage of using a consensus mechanism is that you retain the control of the MEV profits.

So let's say you order the transactions, you extract some value from them by defining a certain order, and basically then the protocol can decide how to distribute that MEV, whether to burn it, whether to distribute it to provers, et cetera, et cetera. And I'll come back to that later. And unfortunately, there are cons to this approach. And the main con is that it's non-trivial to implement. So the problem is that for an L1 if you add a classic consensus it has some certain properties that are guarantees but for an L2 we don't really need those guarantees because the L1 that we connect to already provides those guarantees So it's more of a mechanism that adds resilience and stronger real-time censorship resistance guarantees.

And therefore, it's more complex to add, and it also adds a lot of overhead. And plus, you need a fallback. So because a rollup needs a way for users to either continue with transacting or allow the users to exit, even if the sequencers fail, you need to have a fallback mechanism. So let's say you use something like Tendermint. If there's a liveness failure on Tendermint and there's no fallback mechanism, you're basically stuck.

Your transactions are stuck. And you either have to go through governance or some way, but it's not trivial. And the fallback mechanism would work in a fashion where you have, let's say, I don't know, 10 minutes for the consensus to produce a batch. And if no batch is produced, then anyone can submit a batch and continue. And that adds even more complexity to the bridge.

And now, base rollups. So let me first explain what a base rollup is. A base rollup construction was proposed by Justin Drake a few months ago. I think it was in the winter. And basically, it uses the infrastructure of L1 searchers that would specifically listen to L2 transactions, construct batches, and submit them to the L1.

And there are a few pros to it. So 1, it's quite trivial to design. It doesn't really affect the protocol that much. All the complexity is passed on to the searchers. And 2, there is quite a tight integration with Ethereum, and therefore you have quite strong real-time censorship resistance guarantees and quite strong liveness guarantees.

And you don't need to add any fallbacks or anything like that to your bridge. But there are cons, unfortunately, as well. And the first con is the confirmation times are very slow, or not very slow, but slow, and equivalent to Ethereum. So let's say, because the searcher cannot provide any economic guarantees that the ordering will be exactly the same when the transactions are finalized. You essentially have to wait for Ethereum to finalize that ordering before you can transact any further.

And that takes around 12 minutes on Ethereum currently even more sometimes and the second downside from the perspective of a roll-up is all the MAV profits are redirected to Ethereum or more specifically to the searchers and basically the problem here is that the provers are the main cost for zero-knowledge roll ups. And how do you ensure that the provers are incentivized enough to retain them and have them participate in great quantities. And this doesn't really help because it basically redirects the large chunk of the protocol profits to the L1. And So now let's switch to prover decentralization. So an obvious solution would be use an Akamoto-style competition mechanism.

So let's say in Bitcoin, you have miners. They compute blocks. They solve the cryptographic puzzle. And the 1 that solves it gets to basically propose the block. You could do the same here, where the first to compute the 0 knowledge proof is the 1 to get the profit and to finalize the block.

And the second mechanism is a personal assignment. I'll go into what it is later. So a commodity consensus style mechanism doesn't really work. And the reason why it doesn't work is because it doesn't have randomness. So 0 knowledge proofs are not really random.

So they're deterministic. So if you and I compete the same statement, the proof of the same statement, it's going to be the same proof. And therefore, the most efficient prover is always going to win. There's no randomness. So for example, in Bitcoin, if you control 1% of the hash rate, your probability of winning the puzzle for a specific slot is roughly 1%.

In here, if you control 1% but you have the most efficient prover, your probability of winning is almost 100%. So you can see how that has a long-term centralizing effect, where because all the other provers are just burning energy without actually being rewarded in any way, shape, or form, they will just fall off and you'll end up having 2 or 1 mega-provers that compute the proofs for every batch. And while it's okay from the safety perspective, because it doesn't really affect your safety of your funds, et cetera. But it's not great from protocol resilience, because let's say that prover goes offline, or they're attacked by a government, or something else, some form of a regulatory attack, or something like that. You're basically stuck.

Your rollup is stuck. And the second approach is per-slot assignment. So what I mean by per-slot assignment is something similar to how Gasper works. So in the theorems Gasper, you have the time is divided in slots. And every slot, you have a new proposer that is selected as a leader to propose a block.

And so essentially you have some pseudo-random function that applies the validators, the existing validator set and selects 1 of the validators as the proposers for that block. And the only difference here is that we need a timer with a permissionless fallback, again, the same with the sequencer. And the reason for that is because in Gasper, if you miss the slot, nothing really changed. The only thing that is changed is the fact that your chain grows slowly. Whereas for us, if you miss your slot and don't submit a proof, then essentially no other person can submit proofs for batches that are built on top of it, because essentially what happens is you would not be able to verify those batches without this batch being finalized.

So you need some form of a fallback that allows you to basically have a permissionless system where anyone can submit a proof in case the selected leader does not submit a proof in time. And let's assume that we, oh, sorry. Let's assume that we have a design, we picked a design. We use a classic consensus mechanism and we use a per-slot assignment for approvers. So now the question is, yeah you have 2 decentralized roles within 1 protocol, but the question is how do you make sure that the incentives are aligned?

Because in this design the problem is that because the sequencer gets the ordering rights, they get to keep all the MEV. And because they get to keep all the MEV, there is a possibility that MEV is a big percentage of your profits, of the protocol profits. And therefore, there is no incentive for someone to become a prover. And essentially people will become sequencers and not provers, when in reality we need both provers and sequencers to actively participate. So the solution is Fairly simple.

You might have heard Proposer-Builder Separation before, or PBS. It's a system in Ethereum where you have 2 roles. It can be in protocol or out of protocol. Currently, Ethereum uses out-of-protocol PBS, but at some point, the plan is to add PBS to the protocol. I'll abstract from the complexities of the design differences, but let's look at what a proposer and builder roles are.

So a proposer is a slot leader. So what I described before, It's responsible for proposing a block and propagating it to the rest of validators for them or the community for them to vote. And a builder is an entity that actually constructs the blocks, And the builders compete with 1 another in an auction for their block to be selected as the winning block by the proposer. And what that allows you to do is to outsource the complex job of constructing blocks in an optimal way where you can extract as much value to certain specialized builders and have all the rest of the nodes, validator nodes relatively lightweight. So you can essentially run a validator node on Ethereum or Raspberry Pi, But with a builder, it's a bit more complex.

And the proposer have an option to just ignore all the builder blocks and submit the block themselves. But there's not much incentive in doing that because the proposer is unlikely to extract as much value as builders. And so there's much more incentive to actually build on top of 1 of the builder blocks. And now we have the design for zero-knowledge roll-ups. So we essentially follow the same pattern, but instead of having proposers and builders, we have sequencers and provers.

So it's a sequencer and prover separation design. So a sequencer would emulate the role of the builders in PBS in the initial stage of the slot. So they would pick up some transactions, construct blocks in a way where they extract optimal value, compete in an auction where the prover selects the block with the highest pay, et cetera, et cetera. So the same logic, basically. And provers emulate the role of the sequencers.

Actually, it's not correct. The provers emulate the role of the proposers. But yeah. So in the initial stage, so they would pick the highest bidding block and basically select it and allow the consensus to build on top of it. So how it will work is, In this example, let's say we have 3 sequencers.

They compute some blocks, each of them, and propagate the bids. The bids are comprised of the amount that they're willing to pay and the hash of the block. Because if they reveal the block, the prover can just steal that block. There's no disincentive from doing that. And so they propagate the bits with the hash of the block.

The prover selects the highest bit and basically propagates the signature that it selected the highest bit. So let's say if, in this case, sequencer 1 is the 1 that was picked, it would sign the hash of that block and propagate it back to the sequencer. And then the sequencer would reveal the contents of that block that are committed to, and the consensus would proceed working as usual. And the advantage here is twofold. So 1, it ensures that the distribution of the protocol incentive is somewhat done in a fair way.

And also, it's defined by the free market. So essentially, you can think of it as we don't actually define what the incentives are to age, but the market decides what the incentives are. And because in an auction you're incentivized to bid as much as you can afford to bid, it's likely that in most scenarios most of the profits are going to go to the provers the way it should be because the provers are actually much more costly to run. So yeah, this is the general idea. Bear in mind that I don't think anyone actually implemented it and things might change, but that's the direction where I think we should go in terms of sequencer and prover separation.

And all of us have the same goal, is to build a protocol that is synced, universal, gas-efficient, off-chain, neutral, decentralized network. Yeah. Thank you for listening. And if you have any questions feel free to ask.

Hey, thank you for the talk. I wanted to ask about the provers. How does the whole prover game work? Do you have a centralized prover at the beginning? Basically, how do you ensure that the prover can create a proof in time, what are the incentives there, or how do you think about it if this is like on the roadmap for the future to have some redundancy or decentralization there?

You mean to ensure how the prover submits once it's decentralized?

I mean, you described how to make sure that the... You were talking about a sequencer prover, But then the prover needs to generate the proof for the chain to progress. So how do you think about it so we don't have just 1 centralized prover or 3 or?

So it's the question of incentives. First, The prover only, in the design that I described, the second decentralization model, the prover only needs to compute the proof when they're actually selected. So they don't really waste any energy unless they're actually computing the proof and the other time they're basically idle. And so the costs are not high, and because you share the incentives, MEV incentive profits with the provers, there's actually quite a big incentive to become a prover. And as I described, the way it will work is, let's say if you, the prover time for you is, I don't know, 5, 10 minutes, you create a slot that is 15 minutes just to allow some leeway.

And the prover has those 15 minutes to submit their proof. And if the proof is not submitted, then anybody else can submit the proof for that particular batch and just steal their reward. And that way you ensure that even if the unsigned prover for a specific slot fails for 1 reason or another, you always have a fallback where others are incentivized to actually steal their reward from them.

Okay, but the prover is somehow preselected, like nobody else can submit the proof, just the 1 prover for a specific block? Or is there like a race of multiple provers to submit a proof for the certain block?

So initially, it would be 1, because it's inefficient, and also it's quite centralizing to have multiple. And then in case the prover fails to submit the proof within a certain period of time, then people are free to compete and submit. The first 1 who submits wins, Because then it's more time critical, whereas in the first slot, you have a certain given amount of time. So there's no reason to let people compete and waste resources and create a centralizing vector.

And do you want to have like more provers later on?

Like 4 or 5?

0 yeah, for sure. What do you think is a reasonable number? Like obviously 1 if it's performance should be enough, but you want to have more?

Not really. So the problem here is if you have, because if you have 1, you need to compute the proof sequentially. And currently, the proof times are higher than the block times. So you can see if you compute the proof sequentially, the finality times grow super linearly to your block numbers. And basically, you end up with a system that in a few months might have a finality time of, I don't know, a few weeks, which is not great.

And so the idea is that if you use the per-slot design that I described, you can assign different provers to different slots, and they can compute those proofs in parallel. And basically, instead of having 1 prover compute proof and then the next prover wait until the first 1 computes and then compute the second, they compute all of them in parallel and then just submit them all at once. And that allows us, Assuming that there are no other bottlenecks, your throughput essentially linearly grows with the number of provers that you have in the network. So let's say if you have 20 provers, you can compute a certain number of proofs and therefore you can have a certain number of TPS. And then if you have 100 provers, the number is not gonna be 5x, but you can see how it will grow.

Maybe a bit sub-linearly, but it will roughly follow the number of provers.

Yeah, thanks a lot. Thank you.

Hey, Tugrul, thank you for your speech. I noticed there's 1 design that you didn't mention in this. Is Scrawl considering becoming a DN rollup?

Not for now, no.

Not for now. All right. Thank you.

And the design sounds a bit like Gaspa style, actually, with the ability to submit proofs without waiting for the predecessor, for the parent. Where exactly do you see the difference?

So the main difference is that essentially you can submit the proofs on chain and not verify them because there might be a scenario where, let's say, the parent proof has not been submitted yet. So what you do, there are 2 benefits here. 1, it allows the system to work. And 2, it's much more gas efficient this way. So you would aggregate the proofs on chain, like keep all of them without actually verifying them, and then assign another prover to aggregate them, compute 1 aggregate proof from let's say the hundred proofs that were submitted for hundred slots, and then verify 1 proof on chain.

So in this case instead of paying roughly 350, 000 gas per proof verification, you're just paying 350, 000 gas for the batch of aggregate proofs that you've computed. Thank you. Thanks.

Thank you. Thank you. Thank you.