Examining the Based Sequencing Spectrum

Thanks to Artem Kotelskiy, Drew Van der Werff, Mamy Ratsimbazafy, Mads Mathiesen, Justin Drake, and members of the Chainbound team (Nicolas, Francesco, Paul and Lorenzo) for the review. Review ≠ endorsement :)

Table of Contents

Before we get into based sequencing, let’s quickly discuss sequencing, as a whole, without diving into too much detail. In short, with the trend towards state fragmentation, the value of both atomic composability between rollup/application-specific state and the sovereignty over proprietary state is both clear and not mutually exclusive. Effective shared sequencing designs understand this and attempt to marry the two properties, but it does come with a major drawback: a shared sequencing layer has to rely on its own consensus for transaction ordering and updating the rollup contract. This completely delegates liveness to the committee operating the shared sequencer. If one is to delegate liveness for the goal of shared sequencing, the natural question is now to whom? Now let’s talk about ‘based’.

Based sequencing is a form of shared sequencing whereby the sequencing of L2 transactions is handled by a subset of the L1 proposers. In its most basic form, any L1 proposer can sequence and include an L2 batch of transactions along with their L1 block proposal. Based sequencing improves upon the external shared sequencing model by allowing sequencing between all registered rollups and the layer 1, without requiring extra consensus. We simply - or as we will come to find, not so simply - rely on the L1 proposer or based sequencer to sequence and settle rollup batches. For example, in an Ethereum context, its hardened and geographically diverse validator set is now your rollups’ sequencer set.

Having the L1 proposer as the sequencer gives us some other nice properties:

That said, relying on the L1 proposer to also propose L2 blocks introduces a core UX problem: users experience a minimum 12-second transaction confirmation time.

Rollups currently work around this problem via preconfirmations, a property unlocked by centralized sequencers that as the sole L2 to L1 batch posters, can guarantee an order on state. This is not the case when L1 proposers (or based sequencers) are rotated, given the L1 proposer only has a finite window to settle L2 batches. Then the question becomes: can we do the same in a decentralized context? How about in a based setting? If yes, how does this impact the role of the proposer? We tackle these questions and more while seeking to understand the full extensibility of the role of a proposer within a preconfirmation network.

Let’s go over those requirements individually:

Based Preconfirmations

In a based sequencing system, we rely on the L1 proposer to preconfirm transactions, as they are the sequencer. In this model, the first two requirements can be met through (re)staking:

Faults & Slashing

Collateral can only serve as a mechanism for credibility insofar as it can be slashed. [5] A preconfirmation commitment can act as a slashing device for the issuer’s collateral in case it was not honored on-chain (a fault). As in the original proposal, we outline 2 types of faults:

In a world where block building is outsourced to third parties, we require a second modification to hold based sequencers responsible for not including a certain transaction. This modification requires some type of forced inclusion mechanism that the based sequencer can rely on to include any transactions they committed to. If we don’t have this, proposers opting into this system would have to build their own blocks, which is often not economical. This forced inclusion mechanism could potentially be implemented out-of-protocol through a modified MEV-boost sidecar.

The actual mechanics of the slashing device are left as an exercise to the reader. A good starting point could be using protocols like Axiom or Relic to generate and submit fault proofs and the preconfirmation commitment. For example, in the implementation by @cairoeth, they leverage a challenging mechanism where the sequencer can address any challenges by submitting a Relic transaction inclusion proof. This mechanism addresses slashing for liveness faults. Proving safety faults will be more complex because they involve state, but they should be achievable through similar mechanisms.

Based Sequencer Election

Before discussing sequencer elections, let's recap the responsibilities of the based sequencer offering preconfirmations:

The sequencer election rule within a based context is quite simple:

With an understanding of based sequencing and preconfirmations, let us backtrack a little bit and address how based sequencing actually works right now. To do that, we can examine Taiko.

In the based sequencing model of Taiko, the L1 proposer is primarily unaware of L2 and does not construct L2 batches. Taiko has a separate L2 mempool, where searchers compete in a just-in-time (JIT) auction to build the most valuable L2 batch. This process resembles how PBS on L1 works. These searchers bid for the inclusion of their batch to an L1 block builder, who then selects the most valuable L2 batch to include in their block. This approach maintains compatibility with existing infrastructure since we leverage the sophistication of the MEV supply chain while keeping the involvement & sophistication of L1 proposers relatively low.

What we can learn from this is two-fold:

Incompatibilities

Before continuing, we’d like to clarify preconfirmations' incompatibilities with how based sequencing works in reality. A system that supports preconfirmations needs the following: a single sequencer or preconfirmer known ahead of time, that has a lock over the L2 state. This is fundamentally at odds with how based sequencing works in the Taiko model: the “sequencer” auction is just-in-time, and anyone can participate, meaning no one has a lock on L2 state until the auction winner is determined at block proposal time.

Introducing preconfirmations to a based rollup requires moving away from a JIT auction model and necessitates heavy involvement from the L1 proposer. They go from being a passive monopolist to being an active monopolist, albeit at a cost - sophistication:

To get more specific, generating priced preconfirmations from diverse search spaces is a non-trivial task. This requires the proposer to have high computational resources and technical sophistication. In addition, the preconfirmation commitments only carry credibility up to the restaked amount of the proposer issuing it. They need to deposit more collateral if they want to put more economic weight behind their commitments. The sequencing value (yield) has to compensate for both the capital cost of stake and technical sophistication. In reality, only a small subset of L1 proposers are likely up for this task.

The UX of a based preconfirmation system heavily relies on the number of opted-in proposers, making the aforementioned based preconfirmation design somewhat untenable. This becomes more evident in scenarios where preconfirmation transactions involve both L1 and L2 states, which are only possible if the sequencer has a lock over both states (i.e., only the proposer proposing the next L1 block) [6]. Here, you need an even greater percentage of proposer opt-in.

The high-level issue of proposer sophistication results in some subset of sophisticated L1 proposers earning outsized returns, which becomes a centralization vector. This is precisely why proposer-builder separation was initially introduced. We once again find friction between the L1 proposer having a full monopoly over advancing the state of the chain and needing to keep their requirements low enough to support a decentralized validator set.

Proposers are the only entity with full credibility over state lock, yet based preconfirmations are fundamentally a ‘big-node’ job. So where does that leave us, and how do we build both an effective and viable preconfirmation solution?

Fortunately, this problem has been recognized, and a line of research has surfaced to address it. In general, most directions focus on separating validation, a task with low requirements, and state progression, a task with high requirements (this is in line with Vitalik’s endgame vision).

Execution tickets introduce an in-protocol market for purchasing block proposal rights in the form of a lottery. Essentially, the role of the L1 validator is split into 2 distinct roles: the execution proposer and the beacon proposer. Execution proposers are responsible for proposing the L1 block payload and participating in a lottery to win these rights. They are overseen by beacon proposers and attesters, who vote on block validity and somewhat constrain the execution proposer through mechanisms like inclusion lists. This guarantees a reasonable amount of censorship resistance, even in likely centralized block production.

One important concept to note is that this lottery assigns proposal rights for future slots, which means that the execution proposers are known beforehand. This satisfies one of the requirements of a preconfirmation system: a leader that’s known in advance!

Another requirement was credibility. The execution proposer deposits some collateral for the block they intend to propose, which can be slashed when they violate consensus rules. Additionally, this collateral can be re-used for preconfirmation credibility through some form of restaking, or perhaps by then, they will be able to use some manifestation of PEPC.

Execution tickets are a form of attester-proposer separation (APS). There are other designs as well, like the ones outlined in this article by @barnabemonnot or this one by @ConorMcMenamin9.

However, even though execution tickets fulfil all the requirements for based preconfirmations, we don’t know when (and if) they will be implemented in-protocol.

Can we achieve the same out-of-protocol for external sequencers?

In our opinion, the path forward here would be to re-use the pattern that PBS introduced by allowing based sequencers to outsource sequencing to a sophisticated third party by fully selling or delegating their sequencing rights. A basic but easy-to-overlook property is that the proposer would still be involved in the process: including a sequenced batch of transactions will be a joint effort between the sequencer and the L1 proposer. So we’re merely “downgrading” their role to just being a proposer of the sequenced block, which we believe to be more aligned.

There are a couple of properties that are very important when discussing rollups and (based) sequencing. We will limit ourselves to these two: liveness and finality.

Liveness

Someone always ensures liveness: for rollups today, it’s mostly the centralized sequencer. However, fallback mechanisms, like escape hatches, are in place, in which case the liveness falls back to the L1.

When we consider decentralizing the sequencer, we must consider its liveness properties.

Finality

One would think that finality on Ethereum-secured rollups would be the same as Ethereum (+ whatever time the proving mechanism introduces), but this is rarely the case in practice. Rollup sequencers can ensure faster finality if you, as a user, trust them not to equivocate on their preconfirmations. If the Ethereum L1 reorgs, the sequencer will guarantee the same settlement order, thereby providing a trusted finality gadget for L2 transactions.

However, based rollups do share finality with the Ethereum L1. For example, Taiko references the previous Ethereum L1 block hash, meaning they must reorg with the L1. We can say that Taiko inherits finality from the L1. This is a pattern that we will see with any form of L1 <> L2 composability: if an L2 transaction is conditional on some L1 state, it cannot be considered final until that L1 state is finalized.

As mentioned before, shared sequencing layers run their own consensus protocols, which may also include a finality gadget. This means they can offer faster finality than the L1 the rollup settles on, but the liveness is delegated to a committee.

Tradeoff space

An inherent benefit of vanilla-based sequencing is that L1 guarantees liveness.

In this article, we argued that L1 proposers are not sophisticated enough to offer preconfirmations today and proposed outsourcing this to a third party. This third party can either be a monopolistic sequencer for a time window (no consensus) or a BFT committee running a consensus protocol.

Let’s take a look at the tradeoff space of each:

With this in mind, we think examining the property of ‘based-ness’ on a spectrum is better. A system that outsources sequencing and validation (external consensus) is less “based” than one that outsources just sequencing. For example, a rollup that relies on an external consensus set for finality is less based than a rollup that re-orgs with the L1. With that said, we subscribe to the belief that it is still fair to view the former system as based, as the L1 proposers still have agency on whether or not to sell their block space.

Given that the L2 here relies on the L1 for canonical ordering & finality, the sequencer needs guarantees from the proposer that their batch will be included (especially at the end of a sequencing window). If this was not the case, it would be trivial for the subsequent sequencer to reorg the unsafe L2 state of the previous sequencer because that state was not yet settled on the L1. This would result in the previous sequencer being slashed for a safety fault. In practice, this will look like a credible proposer commitment about inclusion.

We are actively working on this problem and are excited to share more on it soon. As always, if this is of interest to any builders or researchers, please reach out!