Based sequencing
As the name implies, the Based Stack includes a based sequencer election mechanism developed by Spire.
Based sequencer election is used to determine the "based sequencer" of an appchain. The elected based sequencer has the exclusive ability to sequence and propose appchain blocks, and therefore to give preconfirmations and other proposer commitments. The sequencer election mechanism used by appchains may differ, appchains may choose to optimize for MEV capture, composability, decentralization, etc. Some sequencer election mechanisms are more valuable when other appchains are using the same one, building a network effect.
Terminology
Before we start, some quick terminology:
Based Sequencer: The entity that has permission to propose an appchain block on L1. Is the winner of the based sequencer election mechanism.
Total Anarchy Based Sequencing: The design that Taiko uses. A block proposal on L1 is made completely permissionless. While the L1 proposer is elected ahead of time, a specific based sequencer (L2 block proposer) is not elected ahead of time.
Vanilla Based Sequencing: Originally introduced by Limechain, Vanilla Based Sequencing describes a simple sequencer election mechanism: elect the current L1 proposers if they have opted-in and if not, run a random lottery to choose another L1 proposer that has. Note that opting-in may require some amount of preconfirmation collateral.
Sequencer election
The sequencer election design that the Based Stack supports is maximally configurable to support the requirements that different applications have. Here are a few tradeoff spaces we have identified:
Sequencer Revenue (MEV) Retention vs Sequencing with L1: To retain sequencer revenue with an auction, there must be more than one participant in that auction. There is only one active Ethereum proposer at a time, so tradeoffs must be made.
Preconfirmation Availability vs Sequencing with L1: A similar tradeoff to the above: to get sequencing with the L1, the based sequencer must be the active Ethereum proposer. If this proposer has not opted in to provide preconfs, preconfs will not be available during this proposer’s slot. Using a sequencer-includer design, we can elect based sequencers that are present in the Ethereum lookahead that have preconfirmation collateral and avoid this issue.
Gas Efficiency vs Interop with L1: Whenever an L2 block is proposed, L1 gas costs must be paid. As Ethereum gas is expensive, we want to minimize the amount of gas used in block proposals and also minimize the quantity of blocks proposed. In practice, this might mean setting the block time of an appchain to X*12 seconds where X>1. These longer block times can be abstracted from users with preconf designs like multi-round MEV-boost.
Construction
We will divide this section into two primary elements of the Based Stack's sequencing construction: based sequencer election and sequence constraints. The based sequencer election component outputs an elected entity with permission to propose an appchain block, while the sequence constraints component imposes constraints on the contents of the proposed block.
Based sequencer election
An L1 election contract periodically runs a dutch auction to distribute tickets (implemented as NFTs). This market is permissionless and anyone can participate. The number of tickets distributed must equal the period of the auction, so if the auction begins every 10 blocks, 10 tickets must be distributed to the auction winner. Some genesis tickets may be minted. Additional details about the auction process (such as complex bids for multiple appchains) will be explored further in future content.
As soon as the Ethereum lookahead for the current epoch is available, based sequencers can be deterministically calculated for the entire epoch through the following (configurable) rules: a. First, proposers in the lookahead are determined for eligibility if they control at least one ticket and follow any and all additional configurable constraints that the appchain chooses (such as some minimum preconfirmation collateral posted). Proposers that meet these criteria (referred to as eligible proposers) will always be elected as the based sequencer unless no proposers meet this criteria. b. Once the subset of eligible proposers has been identified, sequencer election takes place starting at the end of the epoch, with the 32nd slot. The following algorithm is used to determine the elected sequencer: c. If the proposer being tested is an eligible proposer, they are elected as the based sequencer. One ticket that they hold is burned. d. If the proposer being tested is not an eligible proposer, the last eligible proposer tested (so the next eligible proposer in the lookahead) is elected if they still have a nonzero ticket balance. One ticket that this elected sequencer holds is burned. If no eligible proposer has been tested yet, a random eligible proposer is elected. If the last tested eligible proposer does not have a nonzero ticket balance (has 0 tickets), a random eligible proposer is elected. If no eligible proposers exist, a random ticket holder is elected. If no ticket holders exist, block proposal is permissionless. These fallback rules can be configured.
Sequence constraints
We introduce two special sequence constraints:
Forward Based Sequencing: An additional set of actors, called “forward sequencers” are chosen. Forward sequencers have the special ability to submit “forward sets” to the L1 rollup contract. The forward sequencers can be chosen in multiple ways: a whitelist, token-gated, for a fee, or completely permissionless. An appchain can choose how this election works and may even choose to elect no forward sequencers. Forward sets are comparable to Inclusion Lists, and they constrain the next based sequencer - all transactions in the forward set must be included in the block that the based sequencer proposes. This design has strong similarities to various proposed MCP gadgets such as FOCIL.
CR Committee: An additional set of actors, called “CR Committee Members” are also given the ability to influence block production: every block proposed must include signed data from at least K CR Committee Members, where K is a certain number of Committee Members. The message that is signed must be (a hash of) a list of transaction hashes, where each transaction hash present must also be included in the block. This design is somewhat analogous to the “Censorship-Resistance Committee” introduced by Quintus, although implementation details differ. Note that while the mechanism to elect Committee Members is easily configurable by the appchain, we believe whitelisting makes the most sense (as at least K CR Committee Members must be live to produce a block). As with forward based sequencing, an appchain can choose to elect 0 CR Committee Members (and set K=0) to opt out of this feature.
Explanation
Ticket distribution is done with a descending dutch auction for two main reasons: it is a relatively well-understood simple auction mechanism and it is friendly to combinatorial auction designs. Also important is that manipulation from weak censorship on Ethereum has minimal effect.
The sequencer election mechanism described is designed to prioritize ticket holders with multiple tickets and sufficient preconfirmation collateral - but these can both be parametrized. We recognize that some applications may need to prioritize different sequencer election properties (maybe liveness over censorship resistance) and believe this design can be configured to this end.
The final two components listed above are included to support and inherit the censorship resistance of Ethereum. A CR Committee, if implemented correctly, may even lead to an appchain with better censorship resistance than Ethereum itself.
These design decisions are also made to support lightweight applications: appchains that may not have many users or frequent transactions. We continue to research how certain tradeoffs can be made to enable the true tail end of applications.
Last updated
