Rollups have been criticized as a flawed scaling solution due to their siloed landscape. However, based rollups offer new opportunities to scale Ethereum while preserving its network effect and maintaining composability.

Based rollups exist on a spectrum that is still being defined. Vitalik mentioned "total anarchy" as a sequencing and batching approach—this represents the most basic version of based rollups. As the first based rollup to embrace this approach, Taiko faces certain trade-offs, particularly inefficiencies in block proposing due to parallel efforts.

Currently, Taiko's model doesn't shield proposers from failed block proposing. To reach that point, L1 builders must implement revert protection, which requires trusting the builder. Revert protection prevents proposers from being frontrun by rejecting multiple proposeBlock calls.

The anarchy approach has another significant challenge: since the next proposer isn't defined in advance, it's impossible to build any commitment (i.e., preconfirmation) on the next proposer. This affects the level of composability (defined here as the interaction frequency between based rollup and the L1) and interoperability between Ethereum and based rollups.

There are different approaches to solve this problem:

• Auction: This involves running an on-chain auction among ticket holders to decide the next proposer. After the winner is announced, they can build the block and propose it to the L1. However, this approach only helps to determine the next L2 proposer. While it helps create a commitment with the next L2 builder, it doesn't affect composability with L1 unless the L1 validator delegates building rights to the auction winner.

• Opted-in L1 Proposers: In this approach, L1 proposers in the lookahead must opt into the based rollup through an optional gateway. This allows the next L1 proposers to build both L1 and based rollup blocks simultaneously, creating atomic composability between the two layers and simplifying the creation of commitments between users and L2 block builders (i.e., preconfirmations). L1 proposers must deposit collateral (ETH or any token) with the gateway for additional slashing conditions. If a proposer fails to include a user's transaction in the next block, their collateral will be slashed.

This is the current version of Taiko. Blocks are built locally in L2, can be proposed to L1 by anyone (anarchy approach) and accepted by the chosen L1 validator. Composability here is entirely dependent on L2 block times (block-level composability), which may vary in order to accumulate enough L2 fees to cover L1 costs. It's normal to expect longer block times. This approach lacks atomic-level composability.

All transactions and blocks of L2 are sequenced and built by L1. This is unlikely to happen and there is no logical/engineering advantage here in the context of scaling through rollups. We just put it here to define the spectrum.

To achieve a fully composable based rollup with the L1 with preconfirmations, all proposers in the L1 lookahead must be opted-in through the gateway. This gives the L1 proposers the power to control all L1 and L2 blocks at the same time and synchronous composability with the L1. This is the future of based rollups and the next version of Taiko.

Conversely, if there are no or a low number of opted-in L1 proposers in the lookahead, composability and liveness will be reduced due to the long submission time to Ethereum. The opted-in L1 proposers will have to wait their turn to submit L2 transactions to the L1. So there are two directions in this approach.

It's challenging to compare these approaches due to their practical differences, but this graph illustrates the relationship between L1 composability and user experience across different based rollup approaches. The x-axis represents composability, with L1 block time serving as the reference point (12 second). As the sameness between L1 and L2 constructors increases, composability advances toward the atomic phase. Conversely, as this sameness decreases, composability declines to intervals longer than block level.

Disclaimer*: This post doesn't propose any new terms. It just tries to help understand the composability spectrum of different based rollup approaches.*

Explore open positions on our job board.

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 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.