Based vs Non Based Sequencing: Converging Paths by Toghrul Maharramov
ETHDubai 2024 · 21 Apr 2024 · 15:53
Toghrul Maharramov compares based and non-based rollup sequencing, examining why their long-term designs may converge.
Speakers
Topics
From ETHDubai 2024, hosted by DeFi Dubai.
Transcript
um hello everyone my name is togl it says contributor but I actually just complain about things on Twitter I don't really do much at scroll so uh today we're going to be talking about based versus non-base sequencing and the converging Paths of them well actually there's a bit of a rock pull I'm actually going to talk about why roll up decentralization matters first I think I was just a bit too tired and I was like base sequencing is a bit too complex so I'll just write something about decentralization so yeah let's start with the obvious decentralization is important why though like why do we even care about
decentralization because a lot of people are just using that term to virtal signal and say oh yeah we're aligning with the values but why should we care about decentral ization I mean is decentralization the end goal or just the means to an end and I would actually argue that it's the latter it's the former it's actually means to an end because we if we can achieve the properties that we desire from De centralization otherwise we don't need decentralization because decentralization introduces overheads Etc and it's not very useful if we already have those properties so what are those properties properties one is
realtime sensorship resistance so what that means is we're trying to maximize realtime inclusion guarantees so for example if a user sends a transaction what would be the probability of that transaction being immediately included or included as soon as possible and with decentralization we try to maximize that property and to maximize the probability of that transaction being included as fast as possible the second one is livess so what is liveness liveness is um the maximization of the guarantees that the protocol will continue functioning as expected so for example if you expect the protocol to be producing blocks on average once every 12 seconds liveness guarantees basically ensure that we
maximize that property of producing those blocks every 12 seconds but you might have noticed that I didn't really talk about safety much don't we really care about safety well we do but decentralization doesn't really help with that and I'll explain why so if you're run a full node you actually don't need safety guarantees from the protocol and the reason was why that's the case if let's say a leader for a certain uh slot in ethereum proposes a block with an invalid transaction in it or proposes a block that has an invalid State transition the full not will just rejected so there's no reason why you should care whether the protocol guarantees the security or
or not the safety or not because even if you the honest majority votes for that invalid block your note will still reject it as long as it's honest so it doesn't really matter what the rest of the community or the rest of the consensus thinks about that particular block or a transaction so protocols safety guarantees are only relevant to light nodes or light clients which means that for example if you run a client that only verifies the headers or the consensus correctness you kind of rely on the consensus to ensure that the transactions were validly processed and so you need the safety guarantees there so I'm not sure if you want to say that decentralization safety is necessary for de decentralization is necessary for
safety or not but like it's a judgment call whether you want to see it from the view of full nodes or any user whatsoever but as you might rightly point out is people including myself have been shouting that rollups inherit sensorship resistance and liveness guarantees from the base layer why are we talking about this right now well it's it's a bit of an iffy subject it's a yes and a no answer so rollups inherit inventional censal sensorship resistance and livess guarantees from the Bas layer and basically that means that there's certain timeline so I don't know like
let's say let's say you allow for a period of one day within which you guarantee that that transaction is going to be included but you cannot guarantee that it will be included immediately so there's no way by theault for rollups to maximize that property there are certain tricks how you can improve that but I'll I'll delve into that a bit in a bit so for example in ethereum thatt is typically very large so the period within which you guarantee it's either 12 or 24 hours and that might be useful for certain applications or certain types of use use cases but that's not actually useful for a lot of applications so for example what if the sequencer censoring an oracle price
update so let's say there's a lending protocol that wants to liquidate a position because the price dropped below the margin rate and basically you're waiting for the price update to come in for you to liquidate that position but let's say that the person whose position is about to be liquidated is has paid the sequencer to censor them to censor the price of the transaction so what happens now well you have to wait for the 12 or 24 hours to be included actually and by that time it might be the case that the price dropped very low and basically the liquidation Point has passed and now the lending
protocol is left with a lot of bad depth and so I don't think it's a really good approach if if when it comes for for these kinds of use cases so how does decentralization help in this case well in this case uh we can say that rollup decentralization means sequencer decentralization I'll ignore the complexities of like ZK rollups having improver decentralization or Challenger decentralization in the case of optimistic rollups Etc is too long and too boring to explain and so uh decentralization enables rollups to drastically improve real time sensorship resistance guarantees and liveness
guarantees so now I'm going to unrug and get back to the original subject base versus non-base sequencing why what is that and why are they converging paths so B sequencing was originally proposed by just and Drake about a year ago maybe a bit long a bit earlier than that um basically the idea of Bas sequencing is you de deprecate the role of a sequencer specifically for rollups and instead what you do is you have roll up specific Searchers which are basically entities similar to how ethereum has Searchers who look for certain profitable transactions and construct uh batches or
sometimes blocks out of them to be produced similar would happen here where you have L2 specific Searchers that would basically scour the L2 mempo and look for the transactions to be included in a batch and produce that batch and basically the The Searchers are expected to construct those orderings or batches and then submit them to the base layer and by base layer in this case I mean ethereum uh and there are certain benefits that this brings so one it basically means that you have negligible overhead over just operating in L1 because you don't really have a Special Consensus you don't have staking you don't need anything like that you just have a certain number of dedicated Searchers for are picking transactions
and submitting them to the L1 and another uh benefit from the perspective of ethereum is that some of the value ACW by the rollup through M or fees Etc it sh is shared with the base layer because by default there's no reason for the rollup to share to maximize the value shared with the Bas layer it just wants to share as much as is necessary to have the data published and to have any necessary execution done but this allows you to actually have a bit of a fair system in which the value is shared in a more fair way from the perspective of ethereum again I think with a lot of rollup operators they would actually think say that it's not really fair but
let's just ignore it for now um and additionally Justin Drake himself and also quite a few people claim that base sequencing in aable rollups to inh inherit the base layers guarantees for for Real Time sensorship resistance and liveness uh unfortunately that's not quite true and the reason why it's not quite true is because the L1 doesn't really have access to the L2 mle by default and so unlike the situation in an L1 where let's say the builders in a PBS scenario the way theorum works right now if the builders are censoring for a long time a certain at a certain point the leader for a slot can just ignore the block proposed by the Builder and
say oh yeah I'm seeing a lot of transactions being censored and I'm just going to propose a block with all those censor transactions this is not the case here there's no way you can do that because the L1 validators don't have access to the mempo so you rely on special entities to basically pick up those transactions and retranslate them to the L1 and so the properties for censorship resistance and also liveness are quite different in this case and there are also disadvantages to the vanilla Bay sequencing and notice how I added the the word vanilla because there are certain modifications that can be done to either alleviate or improve those
disadvantages and what the first disadvantage is that you by default you don't have any fast pre-confirmation so the way centralized rollups Works work and also rollups with their own San sequencing works is that they can give you really fast confirmations within like millisecond seconds or seconds and not wait for ethereum you can still wait for it if you want to maximize your security but for a lot of use cases you're fine with just the pre-confirmation and you can get the same property once you decentralize in a non- based way but with base there's no way you can actually do it by default because you just have some entities submitting batches on the L1 so there's
no way to ensure that those confirmations can hold and then the second problem Again by the vanilla you can kind of solve it I'm still skeptical about the solution to this problem but uh certain people claim that they can uh the the value aced uh by the L2 is not shared with the role of specific actors so in this case it would be provs or challengers because all the value is given back to the L1 or to the Searchers who are constructing the block by default there's no way you can share it and it's a bit problem atic especially for ZK rollups because in ZK rollups the majority of the value uh of the cost is borne by the Prov rather than the s
sequencers or in this case Searchers and so it kind of acts like a disincentive because think of it this way uh Z rups at the moment need a lot more provs that they need Searchers or sequencers and so if the majority of the profits go to the sequencers rather than the provs you basically create a natural disincentive for people to become provs and therefore you decrease the pool of provs that are operating in the network so I think I've talked enough about base sequencing let me just cover an on-based sequencing a bit so non-base sequencing is basically any sequencing
that is not based there are multiple approaches you can take but in most cases it just means that you have a sovereign classic consensus and what I mean by Sovereign classic consensus is a BFD style consensus say tenderman or hot stuff or any other classic consensus that is not Nakamoto and by Sovereign I mean it's it functions independently from the Bas layer consensus so in this case for example take scroll in theory if scroll adopts this approach you would have the sequencer uh uh the sequencing basically run an independent consensus from the ethereum consensus and unfortunately there are certain disadvantages here as well and basically
they miror the advantages of uh the base uh base sequencing so the main one is uh you get worse real time sensorship resistance and liveness guarantees versus base sequencing uh vanilla base sequencing and so why is the title saying that they will converge because they seem quite different p to the to in an attempt to solve the same problem so why am I saying that they'll converge so simple questions how do you improve confirmation times of Base sequence rollups well you just add a sovereign classic
consensus which means that you're essentially emulating what non-base rollups do sequence rollups do but for base sequence rollups so how it will work is essentially it would act as a finality Gadget so you would have the happy path where it's just base sequencing and then on top of that you would have this finality Gadget to basically finalize it for you so basically you it's and to a certain degree emulates what ethereum does where you have an EB and flow protocol which has the happy path of an Alon consensus and then a classic consensus that adds finality on top of it and how do you improve real-time sensorship resistance guarantees and liveness guarantees for
non Bas sequence rollups yeah guess you get should have guessed the answers by now based on what I was implying before is you introduced the base sequence fullback and what I mean by a b base sequence fallback essentially if no batches are produced within a short period of time let's say a minute or two minutes then you make the batch publication permissionless which means that you essentially emulate base sequencing and this allows you to improve the realtime sensorship resistance guarantees and also lightness guarantees quite drastically it's still going to be a bit worse than base sequencing but uh but other advantages still stand so I think it it can stand on its own legs
and I don't see how this is much worse than uh an upgraded base sequencing approach so I think uh I what I described before and I can go further into the detail I just don't have enough time uh basically an ideal base sequence roll up look similar to a non-base sequence rollup and an ideal non-base sequence rollup looks like a Bas sequence rollup and that's the end game for both thank you very much and if you have any questions feel free to ask