Sequencer-Prover Separation in Zero-Knowledge Rollups / Toghrul Maharramov

Transcript

hello everyone my name is tall girl I work at scroll I do mostly research and should post on Twitter and today we're going to be talking about sequencer improver separation and zero knowledge roll-ups so let's start with the roles that uh zero knowledge Roll-Ups have in terms of protocol participants so we have a sequencers 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 that those transactions constructs blocks or in this case batches out of them and submits them to the base layer

so in our case there will be ethereum and you have provers the provers are responsible for constructing the Computing the validity proofs for those patches 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 approver and ethereum which is the base layer which with which the sequencers and proofers communicate and first the sequencer publishes a batch

and then after the batch is published it also propagates a batch to the proofer or the contents of the batch the blocks and the proverb 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 that because unfortunately all the current Roll-Ups and all the construction that are going to come on in the next few months are going to be completely centralized and while it might seem just fairly trivial to decentralized 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 nl2 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 we you would call a BFD consensus so tender man Hot Stuff Etc and that's it call it quit or maybe base Roll-Ups and I'll explain what bass Roll-Ups are later so advantages of a classic consensus mechanism is you have fast confirmation times which means the 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 economic off-chain economic guarantees that your transactions will be added at some point in a given order and another big advantage of using a classic consensus mechanism is that you retain the control of the Meb profits so let's say you order the transactions you extract some values with some value from them by defining a certain order and basically then you the protocol can decide how to distribute that Mev whether to burn it whether to distribute it to provers etc etc and I'll come back to that later and unfortunately there are cones 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 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 resilient 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 roll-up 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 Thunderman if there's a liveness failure on Thunderman 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 uh 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 roll ups so let me first explain what a base draw up is a base roll-up 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 one 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 two 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 or 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 uh 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 approvers are incentivized enough to to retain them and have them participate in great uh quantities so 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 used anakamoto style competition mechanism so let's say in Bitcoin you have miners they compute blocks they solve the cryptographic puzzle and the

one that solves it gets to basically propose the block uh you could do the same here where the first to compute the zero knowledge proof is the one to get the profit and to finalize the block and the second mechanism is a personal loan assignment I'll go into what it is later so uh Automotive consensus style mechanism doesn't really work and the reason why it doesn't work is because it doesn't have Randomness so zero 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 one percent of the hash rate your probability of winning the puzzle for a specific slot is roughly one percent in here if you control one percent but you have the most efficient proofer your probability of winning is almost 100 so you can see how that has a long-term centralizing effect where because all the other approvers are not are just burning energy without actually being rewarded in any way shape or form they will just fall out fall off and you'll end up having two or one Mega proofers that compute the proofs for every uh for every batch and while it's okay from the safety perspective because

it doesn't really affect your safety of your phones Etc but it's not great from protocol resilience because let's say if the approver goes offline or they're attacked by a government or something else a regular 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 personal order assignment is something similar to how Gaspar works so in ethereum's Gasper you have the time is divided in slots and every slot you have a new proposer the 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 one 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 as as 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 you you would not be able to verify those batches without dispatch 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 proven time and let's assume that we oh sorry let's assume that we have a design we picked the design we use a classic consensus mechanism and we use a personal assignment for approvers so now the question is yeah you have two decentralized roles within one protocol but the question is how do you make sure that the incentives are aligned because in this design the problem is that uh because the sequencer gets the ordering rights they get to keep all the MAV and

because they get to keep all the Mev there is a possibility that MAV is a big percentage of your profits of the protocol profits and therefore there's no incentive for someone to become approver and essentially people will become sequencers and not perverse 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 two 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 proposal and Builder roles are so a proposer is a slow 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 to for them to vote and a builder is a is an entity that actually constructs the blocks and the builders compete with one another in an auction for their blog 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 blogs in a 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 now ethereum on a 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 blog themselves but there's not much incentive on doing that because the proposer is unlikely to extract as much value as Builders and so there's much more incentive to actually build one of the build on top of one 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 a proposers and Builders we have sequencers improvers so it's a sequencer improver 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 where they extract optimal value compete in an auction where the proverb selects the block with the highest pay etc etc so the same logic basically and proofers emulate the role of the sequencers uh actually it's it's not correct the previous emulate the role of of the proposers but yeah uh so in the initial

stage so they would pick the highest bidding blog 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 three sequencers they compute some blocks each of them and propagate the bids the bids as comprised of the amount that they're willing to pay and the hash of the blog because if they reveal the block the proverb can just steal that block it doesn't really there's no disincentive from doing that and so they propagate the bits with the hash of the block the prover selects the highest bid and basically propagates the the the the signature that it selected the highest

bid so let's say if in this case six sequencer one is the one 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 uh that I committed to and the consensus would proceed working as usual and the advantage here is twofold so one 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 itch 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 sequence or improver separation and uh all of us have the same goal is to build a protocol that is succinct universal gas efficient off-chain neutral

decentralized Network yeah thank you for listening and if you have any questions feel free to ask [Applause] hey thank you for the talk uh I wanted to ask about the the provers uh how does the the whole prover game work like do you have a centralized prover at the beginning um basically how do you ensure that the approver can create a proof in time what is what are the incentives there or how do you think about it if this is like an

on the roadmap for the future to have some redundancy or decentralization there uh you mean uh to ensure when how the prover submits once it's decentralized uh I mean you described how to make sure that the uh you would automatable sequencer proverb but then the proof needs to generate the proof for the chain to progress so how do you think about it so we don't have just one centralized prover or three or so it's the question of incentives first uh the prover only in 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 and in the other time they're basically Idaho and so the costs are not high and because you share the incentives Mev incentive profits with the previous there's actually quite a big incentive to become approver and as I describe the way we'll 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 than anybody else can submit the proof for that particular batch and just steal their reward

and that way you ensure that even if the assigned prover for a specific slot fails for one reason or another you always have a fallback where others are incentivized to actually steal the reward from them okay but the prover is somehow pre-selected not like nobody else can submit the proof just the one prover for a specific blog or is there like a race of multiple provers to submit a proof for the certain model so initially it would be one 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 can are free to compete and submit the first one 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 approvers later on like oh yeah for sure five or what do you think like is is a reasonable number like obviously one if its performance should be enough but you won't have more really so the problem here is if you have if because if you have one 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 uh 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 personal design that I describe you can assign different provers to different slots and they can compute those proofs in parallel and basically instead of having one perverse a compute proof and then the next prover wait until the first one computes and then compute the second date 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 proofers

the number is not going to be 5x but you can see how it will grow maybe a bit sibling early but but like it will roughly follow the number of Brewers okay yeah thanks a lot thank you hey girl thank you for your speech and notice there's one design that you didn't mention in this I scrolled considering becoming a DN roll up or not for now no not for now all right all right thank you and the uh design sounds a bit like Casper style actually with uh the

ability to submit and proofs without waiting for the predecessor for the parent where exactly do you see the difference uh so the main difference is that essentially you can submit the proofs on chain and not verify them because in my there might be a scenario where let's say the parent proof has not been submitted yet so what you do there are two benefits here one it allows the system to work and to it's much more gas efficient this way so you would aggregate the proof Zone chain like keep all of them without actually verifying them and then assign another prover to aggregate them compute one aggregate proof from let's say the 100

proofs that were submitted for 100 slots and then verify one proof on change so in this case instead of paying roughly 350 000 gas per proof verification you're just paying 300 150 000 gas for the batch of aggregate proofs they use computed any more questions thank you [Applause] [Music]