I’m not a blockchain engineer or security researcher. These are just my showerthought rambles, and they could be nonsense. I’d also point out that sequencers don’t necessarily come to consensus on anything with byzantine fault tolerance not a strict requirement, so it’s more of a coordination or scheduling mechanism. This is quite an in-depth topic, so I’m assuming you are already well versed with rollups and sequencers. Anyway, would love to hear your thoughts!
Now, there are many nuances to this topic, with different types of rollups with different proof systems that may or may not be coupled with sequencing. For the sake of simplicity, though, we’ll assume our task is decentralizing just the sequencer role.
Proof-of-authority
Starting with centralized sequencers, the first route that’ll lead to an improvement is a proof-of-authority system where the rollup developer selects a handful of different entities in different jurisdictions to operate sequencers. Even a dozen sequencers will significantly improve censorship resistance, and there’ll be a strong disincentive against other malicious behaviour as they’ll simply lose their contract. This can be further enhanced with requiring selected sequencers to stake a slashable bond or security deposit.
Of course, this is not ideal — we can do better.
Sequencer auction
The rollup auctions off rights to sequencing to the highest bidder. Sequencers can make money through MEV and/or a transaction fee commission. The MEV and other rewards will be redistributed back to the community in some form (e.g. DAO treasury, public goods funding, token burn, or buyback and burn etc.), with marginal overhead due to competitive pressures between sequencers.
I’m optimistic that rollups will drive rapid innovation, and in the medium term we’ll mitigate MEV at both the user and sequencer level. The rollup that figures this out will have a significant competitive advantage, so the incentive is all there. From here on, I’m assuming MEV has been mostly mitigated, particularly at the sequencer level.
Even in a post MEV world, sequencer auctions can be a simple and powerful mechanism. The most efficient sequencers will bid for sequencer slots and maximize value accrual for the rollup.
Proof-of-stake
Sequencers can stake ETH, the rollup’s token, and/or perhaps even DAI. It could even be a combination, as different staked tokens fulfill different purposes. E.g. ETH will offer greater stability, the rollup’s token will align incentives better etc. The more they stake, the more often they are randomly scheduled for sequencing. They can earn rewards from a transaction fee commission, and/or issuance in the rollup’s token. Slashing mechanisms for attacks, though how this can be implemented and for what, I don’t know.
Proof-of-stake with rotation mechanism
The drawback to a decentralized proof-of-stake mechanism is that they are very inefficient as a large number of validators are live. For L1 security, this is non-negotiable no matter the cost, but for rollups, we can start to get creative — we only need 1 good sequencer active at any given time. We need to compete with centralized sequencer rollups and minimize overheads as much as possible.
You can simply rotate active sequencers with scheduled epochs. Theoretically, you just need one sequencer live at a given time, which is clearly the most efficient option. But you could also add a few more sequencers live within an epoch, and rotate block batching / slots evenly and randomly between them for some level of redundancy. Some approaches like fair sequencing may also require byzantine fault tolerance at least within these epochs. If a sequencer is offline for X number of slots, they can simply be removed from the epoch and leaked/slashed. As before, sequencers with higher stake will get scheduled more often to be active. These rotation mechanisms can be innovated upon, of course.
Inactive sequencers can turn off their machines (though cloud providers may charge a fee for inactive storage) or use them for other purposes. With predictable schedules, they can plan accordingly, and even automate much of this. While the sequencers are inactive, they can unstake a substantial portion of their stake, or be issued a staking derivative. If they fail to restake or produce batches in time for their scheduled slot, the remaining portion could be slashed/leaked. In addition to much lower overheads, this also leads to significantly greater capital efficiency.
Combined with state management innovations like state expiry, such systems could enable uber-zk-rollups doing milions of TPS where it may be very expensive to run an individual sequencer, but you only need to be live with it for short periods of time. Users can simply verify from L1, which will be easy to run.
Sequencer auctions with multiple sequencers and rotation mechanism
Coming back to sequencer auctions, I had already discussed borrowing something from proof-of-stake: requiring winning sequencers to post up a slashable bond (in ETH and/or rollup’s token), and releasing it once a dispute period has lapsed. But we can improve it further by having multiple winning sequencers for a given epoch/period, and they can be scheduled and rotated according to their bids.
Overall, I think this might just be the most efficient solution. High capital efficiency, strong incentives for sequencers to be as efficient as possible, with most of the rewards returned back to the community. It also retains resilience by having multiple sequencers being rotated.
A disadvantage here is that incentives may not be as clearly aligned as with proof-of-stake — it’s much more like a proof-of-work system. They may be the most efficient sequencers, but they may be using some nefarious means to achieve said efficiency, like strategically censoring transactions or some bad faith MEV. Possible messy solution would be to let governance of the rollup vote to slash the sequencer on subjective grounds.
Delegated proof-of-stake
I very much dislike delegated-type proof-of-stake, which is currently used by pretty much all non-Ethereum smart contract L1s. I had previously said that it might work much better for rollups, and I still believe so. But I’m not going to talk too much about it, because this will devolve down to sequencer auctions anyway, with the sequencers bribing delegators for votes. Might as well skip the charade and have a simpler auction setup.
Automated/algorithmic rotation mechanism
So, this one’s the most out there showerthought — but what if there could be a smart algorithm that rotates and schedule sequencers for maximum liveness and efficiency?
This can start with either a sequencer auction or proof-of-stake, but implement a smarter rotation mechanism. For example, there could be a fixed (or dynamic, according to rollup transaction volumes) bond requirement, where a sequencer is first scheduled. Based on the performance of the sequencer using certain objective metrics, smart schedules can form. At first, we may need more redundancy to run such a setup, but over time, it can whittle down to very efficient frontiers while still retaining censorship resistance and redundancy. Yeah, I know all of this sounds vague.
Of course, we’ll need fallbacks like before, where governance can evict a malicious sequencer. Combined with a strong incentive for long-term performance, this will be a highly effective deterrent against subjective bad behaviour.
It’s not a big deal anyway
My apologies to the very few souls who have somehow made it up to here, but it’s actually just not that important. Even with a centralized sequencer, a rollup is secured by L1, and in a competitive environment the rollup operator is highly incentivized to be on their best behaviour otherwise, or what I’ll jokingly call proof-of-legitimacy. Decentralizing sequencing is certainly desirable as even the most benevolent can be thwarted by the-powers-that-be or unexpected technical failures, but really, any of these methods will work well enough.
Two miscellaneous topics:
1) Volition systems may use a different chain for data availability or run their own. Consensus mechanisms for data availability chains follow the same principles as L1s, and this discussion is not relevant. Such systems may end up with two consensus mechanisms — one for sequencers, the other for data availability. I believe zkSync 2.0 will be one such protocol.
2) About those L1 smart contracts for rollups… I think the only solution is to simply make it immutable, where the core contract holding funds and other critical data will be ossified forever. Ensure as far as possible that this contract never needs to be upgraded. If it does, it’ll have to be an opt-in upgrade like Uniswap V2 to V3. Compromises like multi-sig committees and governance voting are just not good enough, though a necessary one in the short term.
