• TL;DR

• Introduction

• The Roads Not Taken

  • Fast L1

    • EIP-7782

  • Better L1 Block Building

    • Quick Summary of Current Architecture

    • Based Rollup Perspective

    • Inclusion Lists (ILs)

    • Execution Tickets (ETs)

• Other Needed Improvements?

Thanks to Dani and Arixon for the review.

TL;DR

Based rollups constrained by the L1 due to slow slot times. This can be bypassed with based preconfirmations using opt-in L1 validators to provide preconfirmations to based rollup users. That's great, but we have an important problem; validators have no way of forcing builders to include a transaction. With some protocol upgrades in Ethereum, like inclusion lists and execution tickets, L1 validators can force builders to include any transaction.

Introduction

Rollups have three modules (assuming they're already settled on Ethereum); DA, Execution and Sequencing. Current rollups only use Ethereum for one of these modules, DA. Unlike other rollups, based rollups also use Ethereum for sequencing. All blocks of the based rollup are part of the L1 block building pipeline, and therefore, they are completely intertwined with the base layer. As a result of this intertwining, based rollups are also constrained by the current Ethereum model. All the drawbacks of the L1 block building mechanism are reflected in based rollups, such as slow slot times, centralization in relays-builders and lack of censorship resistance. With the mentioned constraints of based rollups in mind, let's explore the potential solutions being researched and developed to address these challenges.

The Roads Not Taken

Fast L1

Fast base layer is the most useful scenario for based rollups. L1 block times are the main obstacle to being a based rollup. This can be overcome with based preconfirmations, but this introduces a new level of complexity, which we'll mention briefly in the next section. Faster L1 blocks mean faster based rollup blocks. What are the current initiatives to make L1 faster?

EIP-7782

Increasing the blob capacity or gas limit is one way to scale the L1, but has the disadvantage of increasing peak bandwidth requirements. Another option, faster block times, is another way to scale the system by spreading bandwidth usage more evenly and avoiding sudden peaks in network load.

EIP-7782 proposes to reduce L1 block times from 12 seconds to 8 seconds. As well as providing the initial spark to gradually reduce Ethereum's block times, it also increases network throughput by 33% while making DEX operations 1.22x more efficient. The only disadvantage of this proposal is that it makes timing games critical and reduces the slot-to-ping ratio, as Justin Drake said.

However, there are concerns that this proposal could make the transition to Verkle trees more difficult by accelerating the growth rate of the state. Also, changes to slot time could have a negative impact on active research initiatives such as enshrined propose builder separation (ePBS) and inclusion lists. (Galaxy, Pectra Upgrade, 2024)

While accelerating L1 block times offers one avenue for improvement, enhancing the block building mechanism itself presents another crucial opportunity for optimizing based rollup performance.

Better L1 Block Building

Quick Summary of Current Architecture

Ethereum's block building pipeline has evolved with the introduction of Proposer-Builder Separation (PBS) through MEV-boost. In this architecture, builders build blocks and compete through an auction mechanism to have their blocks proposed by validators. The main purpose of this separation was to improve block production efficiency and distribute MEV more widely across the network.

Currently, two builders control 90% of block production. This concentration of power has led to observable censorship patterns, with 50-60% of blocks being produced by builders who actively filter transactions based on various criteria, including OFAC sanctions.

The economic dynamics of PBS have created a significant dilemma for validators. They must choose between selling their building rights to builders for MEV rewards (yielding 3-4 times more value) or building blocks natively to maintain censorship resistance. This economic pressure has resulted in approximately 90% of validators opting for PBS, effectively centralizing transaction inclusion power in the hands of two builders.

Based Rollup Perspective

The current block building mechanism has a direct impact on based rollups that rely on Ethereum's validator set for sequencing. At this point, we need to mention based preconfirmations to understand the true correlation between them.

Based Preconfirmations

Based preconfirmations allow L1 validators to provide preconfirmation to based rollup users through a system of economic commitments and slashing conditions. For based rollups, this means achieving transaction speeds and better economics comparable to centralized sequencers. We don't want to go into detail for preconfirmations here, please see our previous classification details of preconfirmations here.

The core conflict here is that these same validators typically delegate their block building rights to a few builders through MEV Boost, because of the aforementioned reward efficiency. This creates a potential mismatch between preconfirmation promises and actual block inclusion capability. This is because validators do not have the ability to force builders to include for an exact transaction. This begs the question: how can we bring forced inclusion capabilities into the validators?

Inclusion Lists (ILs)

Inclusion Lists (ILs) operate as a committee-based protocol enhancement to Ethereum's consensus layer, where selected validators form an IL committee for each slot. These committee members independently create and broadcast local inclusion lists containing transactions from the mempool, each signed and distributed across the network. The block builder must then aggregate these local lists into a unified inclusion list, which becomes a mandatory component of the block alongside the regular payload. This aggregation process uses a deterministic method to combine the local lists, with a bitfield tracking which committee members supported each transaction.

The validation of blocks with inclusion lists introduces additional consensus requirements where attesters must evaluate both traditional block validity and proper IL incorporation. They compare the block's aggregated IL against their own view of the available local lists using a threshold-based evaluation function. The protocol integrates with PBS, providing builders with clear requirements for block construction while maintaining their ability to optimize transaction ordering within these constraints.

How do ILs affect based rollups? It's basically that the validators who have opted in to the preconf gateway can force any preconfed txs from based rollups to builders. It's important to note that the logic of the transaction type can vary. Each transaction type (it can be SEND, SWAP etc.) requires a different type of inclusion logic.

The figure below illustrates the workflow. Preconfirmations without inclusion lists will always tend to be meaningless, because otherwise validators have no power to make the commitment a reality.

Execution Tickets (ETs)

Execution tickets proposes creating two distinct roles: beacon block proposers and execution block proposers. The system establishes an in-protocol market where participants can purchase tickets that grant future block proposal rights. These tickets are priced through a dynamic 1559-style mechanism, where the protocol targets a specific number of tickets in circulation and adjusts prices based on market demand.

During the beacon round, a validator selected through the existing Proof of Stake mechanism proposes a beacon block that includes consensus information and an inclusion list (ETs require implemented ILs) specifying required transactions. This beacon block receives attestations from the beacon committee, maintaining the current security for chain progression. In the execution round, a randomly selected ticket holder produces the execution payload, which must respect the constraints specified in the beacon block's inclusion list. This execution block then receives attestations from a separate execution committee, creating a dual validation structure that maintains the same security while allowing for specialisation in block production.

Concerns

The question is, if we separate execution and beacon block proposers, there is nothing technically preventing execution proposers from still outsourcing their rights to PBS like sidecars. It looks like there is no change here from the current PBS pipeline. What can prevent execution proposers from outsourcing their rights to PBS?

• Economic Pressure: As ticket holders have paid for the right to execute, they have a greater incentive to capture the full value of MEV themselves. Outsourcing would mean sharing revenue after already paying for the right.

• Technical Capability: Ticket holders are assumed to be sophisticated actors who don't need to outsource. But this is an assumption that may not be true, these sophisticated actors can still delegate their rights.

Based Rollups?

The key benefit comes from the precommitment aspect: when based rollup users needs to submit a preconf request, it can coordinate directly with ticket holders who already have guaranteed rights to execute specific future transactions. This enables better preconfirmation mechanisms for based rollups, as ticket holders can provide credible promises about inclusion and EXECUTION at specific times.

Other Needed Improvements?

Better Revert Protection

In based rollups that use the "anarchy" approach, where anyone can propose blocks, multiple proposers may try to propose blocks simultaneously. Without revert protection this could lead to:

• Wasted gas fees from failed proposals

• Front-running of block proposals (see the analysis of total anarchy problems in Taiko's case by Davide from PBS Foundation).

• Parallel efforts where only one proposal succeeds while others revert

The solution involves having builders implement logic to reject multiple proposeBlock calls for the same slot; however, this requires trusting the builder to properly implement this protection. It doesn't solve the fundamental coordination problem of who should propose next, and can still lead to inefficiencies in block proposing.

Join us 💗

Explore open positions on our job board.

Follow us 🥁

Get the latest from Taiko:

• Website: https://taiko.xyz.

• Discord: https://discord.gg/taikoxyz.

• GitHub: https://github.com/taikoxyz.

• Twitter: https://twitter.com/taikoxyz.

• Community forum: https://community.taiko.xyz.

• Youtube: https://www.youtube.com/@taikoxyz.

• Warpcast: https://warpcast.com/taikoxyz.

Contribute 🤓

Contribute to Taiko on GitHub and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing manual.