Sequencer Decentralization

[norswap]

Let's discuss how the sequencer decentralization (= multiple sequencers) should work.

I have heard preciously little about it, yet I think it has far reaching implications in our design and we should start thinking about it now rather than later.

One thing we have talked about is the idea of a sequencer auction where wannabe sequencer bid for the rights to sequencer the chain for a while.

At a high level, this seems easy enough. The big open question there is: what if the winning sequencer then goes dark? How can we preserve availability in this model?

Another question is how we can minimize cross-block MEV of the kind @saurik discusses in this issue. We might just want to give up on that, but we should be cognizant that these attack are not practically realistic on L1, but very easy for a sequencer on L2, which open a new class of attacks that devs might not be aware of.

A strawman proposal that mitigates the impact of both of these issues is to auction rights to a "sequencing period" (comprising many L2 blocks) to multiple sequencers and to perform a round-robin between them (e.g. if there are 8 sequencers per sequencing period, each sequencer creates one out of every 8 sequential L2 blocks within that period).

This only mitigates the issues, but seems robust enough. This should be complemented with a strong stance against colluding sequencers, and clear punishements against them at the "governance" layer.

[trianglesphere]

Other questions that I have:

• How to deal with sequencers that do not submit batches
• What happens if batches are invalid? What about single transactions in a batch?

One of the big things that I think about with this are that batch submission is an integral part of sequencing and a missing batch will probably also tank liveness for the next few blocks (need empty blocks to catch up again).

Also note: It will be very hard to do a sequencer change inside a single L1 block. Running a sequencer change (inside a PBFT like algo) might be possible inside a single L1 block, but still hard - there is often an exponentially increasing timer and you need several hundred ms to be able to a single round of communication.

[norswap]

There is even a more fundamental problem in the naive strawman: what to do if a sequencer does not publicize his block (that the next sequencer in line is supposed to build on)? It's really hard to prove that things were not published, in general.

An ad-hoc fix would be to allow a quorum of bonded sequencers to enact a "vote of absence" for a block, which would either skip the missing block (make it empty) or shift the round-robin one forward. There is potential for collusion & sybil here, though we could fall back on governance to police this. Not ideal, but feasible.

How to deal with sequencers that do not submit batches

To deal with this, we could require sequencers to sign their blocks / batches as they make it available on L2, so other sequencers would be able to submit them along with the signature if they're missing.

Also note: It will be very hard to do a sequencer change inside a single L1 block. Running a sequencer change (inside a PBFT like algo) might be possible inside a single L1 block, but still hard - there is often an exponentially increasing timer and you need several hundred ms to be able to a single round of communication.

I'm not entirely sure what you're saying here. If there's an assumption that every single block needs to be batch-submitted immediately, I think that's fairly harmful to scalability. Also, sequencing rights should be auctioned off in advance, so we already know in advance the sequencers that will participate in a round-robin for a range of L2 blocks.

[norswap]

I discussed this with @ben-chain a little bit and the strawman approach seems to be instead to organize the sequencers into a few-validators proof-of-stake chain. We can use something like the Tendermin consensus algorithm for the sequencers to come on agreement on blocks and determine who gets the privilege of creating the next block.

So I expect that this gives a true-and-true solution to the problem of detecting sequencers not creating a block when they should.