---
# System prepended metadata

title: '[WIP] Ethrex roadmap for becoming based'

---

# [WIP] Ethrex roadmap for becoming based

> [!NOTE]
This document is still under development, and everything stated in it is subject to change.
Feedback is more than welcome.

> [!IMPORTANT]
> This initial approach is **decentralized** but not **based** yet. Although sequencing rights aren't currently guaranteed to the L1 proposer, there will be incentives for L1 proposers to eventually participate in the L2, moving toward [Justin Drake's definition](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016).

From the beginning, [ethrex](https://github.com/lambdaclass/ethrex) was conceived not just as an Ethereum L1 client, but also as an L2 (ZK Rollup). This means anyone will be able to use ethrex to deploy an EVM-equivalent, multi-prover (supporting SP1, RISC Zero, and TEEs) based rollup with just one command.

The purpose of this document is to provide a high-level overview of how ethrex will implement its based rollup feature.

## State of the Art

While Ethereum Foundation members are actively discussing and proposing EIPs to integrate based sequencing into Ethereum and efforts to coordinate and standardize various components needed for based rollups- like [FABRIC](https://ethresear.ch/t/fabric-fabric-to-accelerate-based-rollup-infrastructure-connectivity/21640) proposes. The following table offers a high-level comparison of the based sequencing approaches before we present our proposal.

> [!NOTE]
> This table compares the different based rollups in the ecosystem based on their current development state, not their final form.


| Based Rollup       | Protocol       | Sequencer Election | Proof System                    | Preconfs                |  Additional Context  |
| ------------------ | -------------- | ------------------ | ------------------------------- | ----------------------- | --- |
| Taiko Alethia      | Permissioned | -      | Multi-proof (sgxGeth (TEE), and sgxReth (ZK/TEE)) | Yes |  -  |
| Based OP (Gattaca) | Permissioned   | Round Robin        | Single Proof (optimistic)       | Yes                     |   For phase 1, the Sequencer/Gateway is centrilized. For phase 2 (current phase) the Sequencer/Gateway is permissioned.  |
| Spire              | Permissionless | Dutch Auction      | Single Proof (optimistic)       | Yes                     |  -   |
| R1                | Permissionless | Total Anarchy      | Multi-proof (ZK, TEE, Guardian) | No                      |  R1 is yet to be specified but planned to be built on top of Surge and Taiko's Stack. They're waiting until Taiko is mature enough to have preconfs   |
| Surge            | Permissionless | Total Anarchy      | Multi-proof (ZK, TEE, Guardian) | No                      |  Surge is built on top of Taiko Alethia but it's tuned enough to be a Stage 2 rollup. They're waiting until Taiko is mature enough to have preconfs. |

Other based rollups not mentioned will be added later.

## Ethrex proposal for based sequencing

After researching existing approaches, we concluded that a decentralized, permissionless ticket auction is the most practical initial step for ethrex’s based sequencing solution.

This initial approach will not fully align with [Justin Drake's definition](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) of "based" rollups but is "based enough" to serve as a starting point. Although the protocol cannot guarantee that sequencing rights are assigned exclusively to the L1 proposer for each slot, it establishes a foundation to move toward that goal. Ultimately, we aim to align with [Gattaca's model for based sequencing](https://ethresear.ch/t/becoming-based-a-path-towards-decentralised-sequencing/21733) and collaborate with [FABRIC](https://ethresear.ch/t/fabric-fabric-to-accelerate-based-rollup-infrastructure-connectivity/21640) efforts to standarize based rollups and  helping interoperability.

[Rogue](https://x.com/fede_intern/status/1846035499799978475) and many upcoming rollups will be using this solution from the beginning.

## Key Points

### Terminology

* **L2 batch:** A collection of L2 blocks submitted to L1 in a single transaction.
* **Commit Transaction:** An L1 transaction submitted by the Lead Sequencer to commit to an L2 batch execution.
* **Sequencer:** An L2 node registered in the designated L1 contract.
* **Lead Sequencer:** The Sequencer currently authorized to build L2 blocks and post L2 batches during a specific L1 block.
* **Follower:** Non-Lead Sequencer nodes, which may be Sequencers awaiting leadership or passive nodes.

### How it will work

As outlined earlier, sequencing rights will be acquired through a ticket auction. Sequencers must register and provide collateral before the auction period to participate. Auctions occur periodically for a defined block range, referred to as a "period". Each auction takes place n blocks before the first block of the period being auctioned.

> [!NOTE]
> The following steps aim to explain the life cycle of an auction period and its sequencing, taking into account the following caveats:
> * The numbers of the slots are set to help the example, this could happen at any part of the chain.
> * In this example the distance between an auction period and the sequencing period for that auction is 3 epochs (this will be configurable).

![image](https://hackmd.io/_uploads/HJEA4ga-el.png)

1. Sequencers individually opt in before auction period n ends, providing collateral via an L1 contract. This registration is a one-time process per Sequencer.
2. Registered Sequencers purchase sequencing rights for period n during the auction.
3. At the auction’s conclusion, sequencing rights for each block in period n are assigned among the ticket holders.
4. Finally, Sequencers submit L2 batch transactions to L1 during their assigned L1 blocks (note: this step does not immediately follow step 3, as additional auctions and sequencing occur in between).

To ensure L2 liveness in this decentralized protocol, Sequencers must participate in a peer-to-peer (P2P) network. The diagram below illustrates this process:

![image](https://hackmd.io/_uploads/HyqcJ7p-ee.png)

1. A User: sends a transaction to the network.
2. Any node: Gossips in the P2P a received transaction. So every transaction lives in a public distributed mempool
3. The Lead Sequencer: Produces an L2 block including that transaction.
4. The Lead Sequencer: Broadcasts the L2 block, including the transaction, to the network via P2P.
5. Any node: Executes the block, gossips it, and keeps its state up to date.
6. The Lead Sequencer: Seals the batch in L2.
7. The Lead Sequencer: Posts the batch to the L1 in a single transaction.
8. The Lead Sequencer: Broadcasts the "batch sealed" message to the network via P2P.
9. Any node: Seals the batch locally and gossips the message.
10. A User: Receives a non-null receipt for the transaction.

Lead Sequencers will follow the following pipeline for L2 block building and batch commitment:

![image](https://hackmd.io/_uploads/BJj2qmpbxg.png)

## Protocol Details

### Network Participants

* Sequencer Nodes: Nodes that have opted in to serve as Sequencers.
* Follower Nodes: State or RPC Nodes.

By default, every Ethrex L2 node begins as a Follower Node. A process will periodically query the L1 smart contract registry for the Lead Sequencer’s address and update each node’s state accordingly.

### Sequencers Registry

* An L1 smart contract will manage Sequencer registration and ticket auctions for sequencing rights.
* Sequencers can register permissionlessly by providing a minimum ETH collateral.
* Sequencers may opt out of a sequencing round by not purchasing tickets for that period.
* Sequencers can unregister and withdraw their collateral after a cooldown period.

### Lead Sequencer Election

* Aspiring Lead Sequencers must secure sequencing rights through a Dutch auction in advance, enabling them to post L2 batches to L1.
* Sequencing rights are tied to tickets: one ticket grants the right to sequence and post batches during a specific L1 slot.
* For each L1 slot, sequencing rights are randomly assigned from the pool of ticket holders.
* Each auction round determines tickets for the nth epoch ahead (configurable).
* Once Ethereum incorporates deterministic lookahead (e.g., [EIP-7917](https://eips.ethereum.org/EIPS/eip-7917)), the Lead Sequencer for a given L1 slot will be the current proposer, provided they hold a ticket.

### Lead Sequencers

* Build L2 blocks and post L2 batches to the L1 within the batch post window (corresponding L1 slot).
* Broadcast to the network:
    * Transactions.
    * Sequenced blocks as they are built.
    * Batch seal messages to prompt the network to seal the batch locally.
* Serve state.

### Non-Lead Sequencers (Follower Nodes)

* Broadcast to the network:
    * Transactions.
    * Sequenced blocks.
    * Batch seal messages.
* Store incoming blocks sequentially.
* Seal batches upon receiveng batch seal messages (after storing all batch blocks).
* Serve state.
* Monitor the L1 contract for batch updates and reorgs.

### Batch Commitment/Proposal

* Only batch commitments from the Lead Sequencer are valid.
* A batch commitment consists of a list of L2 transactions posted to the L1.

### Batch Verification

* Anyone can verify a committed batch.
* A single valid verification is sufficient to advance the chain.
* In the initial version, the Lead Sequencer faces penalties if their posted batches are not verified within the batch verification window (the time limit for L1 to accept an L2 batch verification).

### P2P

* Ethrex’s L1 P2P network will be used to gossip transactions.
* A new capability will be added for gossipping L2 blocks and batch seal messages (`NewBlock` and `BatchSealed`).
* The `NewBlock` message includes an RLP-encoded list of transactions in the block, along with metadata for re-execution and validation. It is signed, and receivers must verify the signature (additional data may be required in practice).
* The `SealedBatch` message specifies the batch number and the number of blocks it contains (additional data may be needed in practice).
* Follower Nodes must validate all messages. They add `NewBlock`s to storage sequentially and seal the batch when the `SealedBatch` message arrives. If a node’s current block is `n` and it receives block `n + 2`, it queues `n + 2`, waits for `n + 1`, adds it, then processes `n + 2`. Similarly, a SealedBatch message includes block numbers, and the node delays sealing until all listed blocks are stored.

### Syncing

Nodes that join a live network will need to sync up to the latest state.

For this we have 2 mechanism:

- **P2P Syncing:** Default for up-to-date nodes missing only the next batch.
- **L1 Syncing:** Used by provers to prove blocks individually and when a Sequencer performs its duties without sharing data over the network.

## L1 Sequencing

Eventually, there'll be enough incentives for L1 proposers to either run their own L2 Sequencers or delegate their L1 rights to an external Sequencer. At that stage, the auction and assignment of L2 sequencing rights will be linked to the current L1 proposer (or their delegated Sequencer). Periods may also adjust as lookahead tables, such as the [Deterministic Lookahead Proposal](https://eips.ethereum.org/EIPS/eip-7917) or [RAID](https://eth-fabric.github.io/website/research/raid), become viable.

This proposal is intentionally minimalistic and adaptable for future refinements.

## Further considerations

* Bonding.
* Ticket pricing strategies.
* L1 reorgs handling.
* Delegations processes.
* Preconfirmations.

## Open Questions 

* Dutch Auction Ticket Pricing (a method where the price decreases until a buyer is found): 
    * What should the initial ticket price be?
    * How frequently and by how much should the price decrease?
    * What is the minimum acceptable price?
* **Worst-Case Scenario:** If no Sequencers are available in the lookahead, should we: 
    * Enable temporary "total anarchy" until order is restored? 
    * Halt the network until new Sequencers emerge?
    *Note: We currently favor total anarchy for this scenario.*

## References and acknowledgements

The following links, repos, and projects have been important in the development of this document, we have learned a lot from them and want to thank and acknowledge them.

**Context**

- [Stages of a Rollup](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe)
- [PBS](https://ethereum.org/en/roadmap/pbs/)
- [Total Anarchy](https://vitalik.eth.limo/general/2021/01/05/rollup.html)
- [FABRIC](https://ethresear.ch/t/fabric-fabric-to-accelerate-based-rollup-infrastructure-connectivity/21640)

**Intro to Based Rollups**

- [Based Rollups by Justin Drake (current accepted definition)](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016)
- [Based Rollups by Spire](https://docs.spire.dev/education-hub/what-is-a-based-rollup)
- [Based Rollups by Taiko](https://docs.taiko.xyz/taiko-alethia-protocol/protocol-design/based-rollups/)
- [Based Rollups by Gattaca](https://ethresear.ch/t/becoming-based-a-path-towards-decentralised-sequencing/21733)
    - [Analysis on Gattaca's Based Rollup Approach by Spire](https://docs.spire.dev/education-hub/based-rollups-overview)

**Based Rollups Benefits**

- [Based Preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353)

**Based Rollups + extra steps**

- [Based Ticketing Rollup by George Spasov](https://hackmd.io/@Perseverance/Syk2oQU36)
- [Based Contestable Rollup by Taiko (Taiko Alethia)](https://docs.taiko.xyz/taiko-alethia-protocol/protocol-design/contestable-rollup)
- [Native Based Rollup by Taiko (Taiko Gwyneth)](https://docs.taiko.xyz/taiko-gwyneth-protocol/what-is-taiko-gwyneth/)

**Misc**

- [Why Total Anarchy Doesn't Pay the Bills](https://ethresear.ch/t/understanding-based-rollups-pga-challenges-total-anarchy-and-potential-solutions/21320)
- [Based Espresso: Based Sequencing for all L2s](https://hackmd.io/@EspressoSystems/BasedEspresso)

**Execution Tickets**

- [Execution Tickets](https://ethresear.ch/t/execution-tickets/17944)
- [Execution Tickets vs Execution Auctions](https://ethresear.ch/t/execution-auctions-as-an-alternative-to-execution-tickets/19894)
- [Economic Analysis of Execution Tickets](https://ethresear.ch/t/economic-analysis-of-execution-tickets/18894)
- [Beyond the Stars: An Introduction to Execution Tickets on Ethereum](https://www.ephema.io/blog/beyond-the-stars-an-introduction-to-execution-tickets-on-ethereum)

**Current Based Rollups**

- [Rogue](https://x.com/fede_intern/status/1846035499799978475)
- [Surge (Nethermind)](https://github.com/NethermindEth/surge)
- [Taiko Alethia](https://github.com/taikoxyz/taiko-mono)
- [Based OP (Gattaca + Lambdaclass)](https://github.com/gattaca-com/based-op)
- [R1](https://ethereumr1.org/)
- [Minimal Rollup (OpenZeppelin)](https://github.com/OpenZeppelin/minimal-rollup)

**Educational Sources**

- [FABRIC's list](https://eth-fabric.github.io/website/education)
- [Spire's list](https://docs.spire.dev/education-hub/based-resources)