Exactly 2 years ago, I wrote a showerthought post (to be fair, most of my posts are that, except for the rare researched one like Games & Blockchain) about decentralized sequencing. A year after that post, and one year ago from this post, we had a brief discussion on Optimism governance forums. This is not a topic I’ve talked about much because it just isn’t that important - battle-tested provers and contract upgradability are much more so.

First, unlike monolithic L1s, you only need one honest sequencer live. As L1s upgrade to PBS type mechanisms, their builders will also have this honest-minority requirement - the same is true of rollups. Either way, please do not conflate L1 validators with rollup sequencers - it’s more of an equivalence with L1 builders. A lot of app-rollups, or rollups by smaller communities, non-financial oriented rollups etc. will be best served by a single sequencer. For many of the types of rollups mentioned above, there really isn’t much incentive for the sequencer to go offline or short-term censor - doing so will tarnish their app’s or community’s and all that’ll happen is they’ll lose users to competitors. Still, mostly by incompetence and less by malice (proofs take care of that) sequencers could fail.

From there, we can build on that by a mechanism for reserve sequencers. For the most part, the lead sequencer handles all sequencing duties. But if it goes offline or censors (see: crLists) a different sequencer can come offline. There are many ways to elect these reserve sequencers, it can even be a self-sequence free-for-all, but the best option is for governance to simple whitelist a few.

The drawback in the above system could be short downtimes between the sequencer switch, and there needs to be some mechanism for addressing reversed transactions. Once again, for some types of usecases this is not a big deal. However, for financial applications and such this is unacceptable.

By the way, slashable bonds and slashing penalties can apply for all sequencers.

General-purpose rollups like Arbitrum One, zkSync Era or OP Mainnet with financial ecosystems have stricter requirements. Currently, Arbitrum One does kind of have a reserve sequencer mechanism, but it comes with a delay. Longer term, for these types of chains, a single sequencer is not going to cut it.

The next step is for governance to elect a sequencer set. Graphene-derived chains like Steem and EOS, and later Tron, set an interesting precedent - they had 20-28 validators, and a long tail of reserves. For an L1 this was sketchy, but for a rollup it’s more than enough. We also have plenty of data from Lido - there’s no shortage of reliable, well-behaved, non-malicious operators out there. So, the governance elects 20 sequencers, and rotates between them every X period of time, or some minimal BFT consensus (though less efficient than simple rotation, could be a requirement for big chains like Arbitrum One) where they are all live at all times. There can be reserves beyond that, though it’s unclear to me how many are actually required - maybe 20 more? Over time, as historical data accumulates, this can reduce over time.

There can be an intermediate step, particularly for rollups without governance, where whoever is operating the lead sequencer can outsource to multiple sequencers.

My preferred option remains what I mentioned 2 years ago - algorithmic sequencer selection. Start with governance electing a starting set, but from there, it’s automatically selected by objective performance. Sequencers with the best uptime, best transaction inclusion etc - all objectively measurable - are given more frequent rotations. This will also incentivize sequencer operators to keep improving their processes, rather than resting on their laurels of being voted in by some whales. As mentioned, a couple of years ago, there are certainly some subjective criterion - for example, a sequencer operator can be very efficient, but indulge in all kinds of dodgy MEV - for which there can be a governance override. Another potential scenario is that one operator builds a proprietary sequencer client that’s more efficient. It’ll depend on the governance, of course - some rollups may be fine with MEV, while others may be stricter about it. Either way, I believe this method minimizes governance and only requires intervention in worst-case scenarios.

How is this different from sequencer auctions? The difference is the system may select a higher quality sequencer than a more profitable one. Again, it depends on the rollup’s governance for how important either of those characteristics are.

Contrasting with proof-of-stake - in proof-of-stake, you run a plutocratic election at all times. In the above situation, you run a meritocratic method for the most part, but with plutocratic fallbacks in worst-case scenarios.

But here’s where things get interesting - governance need not be purely plutocratic. Optimism Collective, in particular, is experimenting with Citizen House - a more democratic approach to governance. If successful, and that’s a big IF, even the fallbacks will now not be purely plutocratic. Over the long term, as these mature, I’m confident we’ll reach a state where rollup sequencing will be purely automated, with very rare intervention required by governance - which looks a lot less plutocratic than today’s proof-of-stake or token governance systems.

PS: Of course, once an L1 moves to PBS, like on Ethereum’s roadmap, intertwining L1 builders with rollup sequencing feels like an obvious outcome. Still a bit early to consider that,

Exactly 2 years ago, I wrote a showerthought post (to be fair, most of my posts are that, except for the rare researched one like Games & Blockchain) about decentralized sequencing. A year after that post, and one year ago from this post, we had a brief discussion on Optimism governance forums. This is not a topic I’ve talked about much because it just isn’t that important - battle-tested provers and contract upgradability are much more so.

First, unlike monolithic L1s, you only need one honest sequencer live. As L1s upgrade to PBS type mechanisms, their builders will also have this honest-minority requirement - the same is true of rollups. Either way, please do not conflate L1 validators with rollup sequencers - it’s more of an equivalence with L1 builders. A lot of app-rollups, or rollups by smaller communities, non-financial oriented rollups etc. will be best served by a single sequencer. For many of the types of rollups mentioned above, there really isn’t much incentive for the sequencer to go offline or short-term censor - doing so will tarnish their app’s or community’s and all that’ll happen is they’ll lose users to competitors. Still, mostly by incompetence and less by malice (proofs take care of that) sequencers could fail.

From there, we can build on that by a mechanism for reserve sequencers. For the most part, the lead sequencer handles all sequencing duties. But if it goes offline or censors (see: crLists) a different sequencer can come offline. There are many ways to elect these reserve sequencers, it can even be a self-sequence free-for-all, but the best option is for governance to simple whitelist a few.

The drawback in the above system could be short downtimes between the sequencer switch, and there needs to be some mechanism for addressing reversed transactions. Once again, for some types of usecases this is not a big deal. However, for financial applications and such this is unacceptable.

By the way, slashable bonds and slashing penalties can apply for all sequencers.

General-purpose rollups like Arbitrum One, zkSync Era or OP Mainnet with financial ecosystems have stricter requirements. Currently, Arbitrum One does kind of have a reserve sequencer mechanism, but it comes with a delay. Longer term, for these types of chains, a single sequencer is not going to cut it.

The next step is for governance to elect a sequencer set. Graphene-derived chains like Steem and EOS, and later Tron, set an interesting precedent - they had 20-28 validators, and a long tail of reserves. For an L1 this was sketchy, but for a rollup it’s more than enough. We also have plenty of data from Lido - there’s no shortage of reliable, well-behaved, non-malicious operators out there. So, the governance elects 20 sequencers, and rotates between them every X period of time, or some minimal BFT consensus (though less efficient than simple rotation, could be a requirement for big chains like Arbitrum One) where they are all live at all times. There can be reserves beyond that, though it’s unclear to me how many are actually required - maybe 20 more? Over time, as historical data accumulates, this can reduce over time.

There can be an intermediate step, particularly for rollups without governance, where whoever is operating the lead sequencer can outsource to multiple sequencers.

My preferred option remains what I mentioned 2 years ago - algorithmic sequencer selection. Start with governance electing a starting set, but from there, it’s automatically selected by objective performance. Sequencers with the best uptime, best transaction inclusion etc - all objectively measurable - are given more frequent rotations. This will also incentivize sequencer operators to keep improving their processes, rather than resting on their laurels of being voted in by some whales. As mentioned, a couple of years ago, there are certainly some subjective criterion - for example, a sequencer operator can be very efficient, but indulge in all kinds of dodgy MEV - for which there can be a governance override. Another potential scenario is that one operator builds a proprietary sequencer client that’s more efficient. It’ll depend on the governance, of course - some rollups may be fine with MEV, while others may be stricter about it. Either way, I believe this method minimizes governance and only requires intervention in worst-case scenarios.

How is this different from sequencer auctions? The difference is the system may select a higher quality sequencer than a more profitable one. Again, it depends on the rollup’s governance for how important either of those characteristics are.

Contrasting with proof-of-stake - in proof-of-stake, you run a plutocratic election at all times. In the above situation, you run a meritocratic method for the most part, but with plutocratic fallbacks in worst-case scenarios.

But here’s where things get interesting - governance need not be purely plutocratic. Optimism Collective, in particular, is experimenting with Citizen House - a more democratic approach to governance. If successful, and that’s a big IF, even the fallbacks will now not be purely plutocratic. Over the long term, as these mature, I’m confident we’ll reach a state where rollup sequencing will be purely automated, with very rare intervention required by governance - which looks a lot less plutocratic than today’s proof-of-stake or token governance systems.

PS: Of course, once an L1 moves to PBS, like on Ethereum’s roadmap, intertwining L1 builders with rollup sequencing feels like an obvious outcome. Still a bit early to consider that,