Taiko Labs Analyzes the Decentralized Path of Rollup: Shared Ordering and the Dilemma Based on Ethereum

Original Title: “To Be Based or Not To Be Based”

Written by: Taiko Labs

Compiled by: Shenchao TechFlow

Key Points Summary

The Rollup-centric roadmap has led to fragmentation and isolation in the blockchain space. This division has resulted in a lack of value transfer between Rollups. To address this issue, shared ordering mechanisms have emerged, such as Espresso, Astria, and Radius. However, this solution inherently requires new trust assumptions, as such layers must have their own security set.

If we want to build a shared ordering layer for Rollups, Ethereum is the most trusted neutral layer we can build or use. Ethereum-based Rollups (i.e., Based Rollups) are inherently compatible with Ethereum and other Based Rollups. However, solutions as Based Rollups also face some challenges. The most significant challenge is that the block time must be the same as Ethereum's, limited to 12 seconds. The solution is to provide a fast confirmation mechanism, such as a centralized sorter, or to speed up Ethereum's block time. In the testnet, the speed based on pre-confirmation is faster than the current centralized sorters.

Crossroads

Looking back at the beginning of the article, the direction chosen by Ethereum is crucial. Ethereum has embraced decentralization from day one, which is a top priority. This priority has imposed some limitations on user experience. These limitations stem from the challenges of designing decentralized distributed systems (e.g., handling global state, sequential execution, etc.). This is precisely what distinguishes Ethereum from other L1s. They have chosen different paths. Other L1s have opted for speed and low cost at the expense of some decentralization. They are fast and cheap because they have historical proof, larger block sizes, and parallel processing. These concepts allow for fast and cheap transactions but also increase the burden on validators. This is why the hardware requirements for validators on other L1s are higher than those on Ethereum.

Before Ethereum itself scales through upgrades like historical expiry, statelessness, Verkle trees, etc., we have delegated the task to Rollups.

Four years ago, Ethereum adopted a Rollup-centric roadmap, outsourcing execution to create a more user-friendly environment until improvements arrive. Thanks to this, we have achieved an average of 250 TPS daily across all Ethereum.

rollup.wtf

As mentioned above, it has been four years since Ethereum decided to adopt a Rollup-centric roadmap. During this period, numerous experiments on "what Ethereum itself should be" have taken place on L2. AltVM (Fuel, Fluent), zkVM (Aztec, Starknet), zkEVM (Scroll, Linea, zkSync), parallel EVM (MegaETH), and so on. These have provided ideas for Ethereum's future. However, they have also created many independent blockchains that have no connection to each other. This is why shared ordering layers have emerged to address the fragmentation issue.

Shared Ordering Layer

Currently, Rollups have centralized sorters. This introduces significant risks of censorship, liveness, and MEV extraction. If Rollups wish to decentralize, they can opt for shared sorters. By using shared sorters, Rollups can leverage finality, decentralization, fast transactions, and cross-chain atomicity. As Vitalik stated, "Decentralized Rollups require 90% of the effort to develop a new L1." Therefore, by choosing shared sorters, the engineering effort for decentralization can be avoided.

The shared ordering layer is essentially a layer that connects the sorting rights of participating Rollups to a single sorting network. This layer runs a consensus protocol, such as BFT, which anyone can participate in (within the design constraints of the consensus protocol). Thus, multiple Rollups have a common mechanism for determining the order of transactions. This mechanism also provides fast L2 finality and composability among all participating Rollups.

The shared ordering layer operates a sorting market. In this market, Rollups can sell their block space (and proposal rights) to higher bidders slot by slot. This also creates a layer for redistributing MEV among all participating Rollups.

Points of Concern

The shared ordering layer has network effects that can create atomic composability and shared MEV among all participating Rollups. Rollups join the network to increase the value of their blocks (while decentralizing their sorters).

However, depending on the system design of the shared sorter, as many participating Rollups as possible should be involved. If a participating Rollup X leaves the chain, this MEV distribution will be disrupted, directly affecting the network effects. Therefore, shared ordering is an endless game, and participants must always remain in the game. As Rushi said, this is a purely B2B model.

The shared ordering layer runs a protocol like BFT alongside the shared sorter market to achieve fast L2 finality and introduces an honesty assumption. It assumes that half of the validators are honest. If, for some reason, half of the validators go offline or are dishonest, the chain may lose liveness (they can use a based fallback). If the BFT protocol loses liveness, participating Rollups will not be able to leverage fast finality, as they must obtain finality certification from the BFT protocol. Withdrawals from that layer will also be paused. But even if the BFT protocol collapses, MEV redistribution will continue, as in Espresso, for example, MEV redistribution is separate from the BFT protocol. In contrast, Ethereum has always had the strongest BFT protocol in terms of cryptoeconomic security and liveness.

Additionally, if they use re-staking, there is also the risk of re-staking. If the hardware requirements for validators are high, this will lead to monopolies. If the re-staking service fails, large-scale slashing may also occur; for more information, see the Eigenlayer risk FAQ. For methods of re-staking in shared sorters, refer to the joint research by Nethermind and Fourpillar.

It is worth noting that, given that shared sorters use pre-confirmation, this process can be done on L1 (i.e., based on pre-confirmation), thus eliminating the need for a new layer. It should also be noted that shared sorters still need to go through the L1 pipeline. Therefore, "fast finality" does not make sense here.

In summary, we believe that if the shared sorter layer lacks decentralization and robustness, they become single points of failure. They will be the weakest link for all Rollups that choose to join.

Neutral Composability Is No Longer a Joke: Be Based

As we mentioned, Ethereum is the most trusted neutral layer for building various applications. Rollups achieve this by sending their batches and proofs to Ethereum, leveraging it as a data availability layer. Currently, most Rollups are managed by centralized sorters, with all transactions sorted by the Rollup teams. Some of these teams are still working on designs to decentralize their networks, such as Aztec's Fernet. There is another way to achieve network decentralization without expending a lot of engineering resources: a sorting-based approach.

Taiko is the first Based Rollup to use Ethereum as a sorting layer. Block construction relies entirely on Ethereum. Anyone can propose a block, and this process is completely permissionless. Each Rollup can achieve composability based on Ethereum without adding a new layer. Since the slots of Ethereum and Based Rollups move in sync, they are fully compatible with each other. This means that flash loans can be conducted on L1 and certain activities can occur on Based Rollups in the same slot (thanks to our BBR design; see details here). However, the Ethereum-based approach also comes with some costs.

Source: L2Beat

We mentioned this issue in the article "Considering Based Preconfirmations for Rollup," but let’s summarize it briefly. As we said, the block time for Based Rollups is the same as Ethereum's, which is 12 seconds. This means Based Rollups need to send their data to L1 via blobs (or calldata) every 12 seconds. If you cannot fill the blob with enough L2 transactions to cover the L1 fees, you will face losses. To avoid passing this cost onto our users, we initially absorbed this cost ourselves and spent a significant amount of money. Nowadays, the proposer’s block time has exceeded 12 seconds (around 20 seconds) to achieve profitability.

These are examples of the difficulties faced by Based Rollups through Taiko. In summary, the main issue is that block time and revenue constraints are based on fees rather than centralized sorters. You sacrifice revenue because sorting is completely permissionless, and your MEV flows entirely to Ethereum, capturing no value from transactions (Spire Labs is developing a framework to improve the revenue model of Based Rollups).

To address user experience and block time issues, we have two options:

• Based Preconfirmations
• Faster block times on L1

Based Preconfirmations

Based Preconfirmations simply use a subset of L1 validators to provide pre-confirmations for L2 users. Currently, Based Preconfirmations are successfully running on the Helder testnet, allowing for lightning-fast transactions on Taiko (20 milliseconds in Gattaca's demo, about 260 milliseconds in Arbitrum).

Based Titan Preconfirmation Demo

In Based Preconfirmations, you do not inherit all the liveness and security of Ethereum. You only trust a subset of the Ethereum validator set. However, it is worth mentioning that we are obtaining trustworthy commitments from the current Ethereum proposers. Anyone can become a pre-confirmation provider by staking a certain amount of ETH on the registration contract. We have detailed the specifics of Based Preconfirmations in previous blog posts; see here.

The space for Based Preconfirmations is still in its early and evolving stages. It faces some threats, just like the centralization of Ethereum block construction, but new methods and research will lead to more reasonable architectures. We will soon share our pre-confirmation design.

Faster Blocks?

No one would refuse to make Ethereum more user-friendly. Faster final confirmations, faster block times, and faster transaction processing are the most favorable scenarios for Based Rollups. As we mentioned, the block time on L1 is the only obstacle to becoming a Based Rollup. Faster L1 blocks mean faster blocks for Based Rollups.

The main idea behind faster L1 is to adopt a consensus mechanism that can essentially reduce slot time. Single Slot Finality (SSF) is a consensus mechanism being considered, specifically Orbit SSF, where each slot can achieve final confirmation within seconds. In the current Gasper protocol, the final confirmation time is 2 epochs, or 13 minutes. However, the downside of SSF is that it is susceptible to 33% inactive leakage.

The main question here is why, if a faster L1 is always necessary, the four years spent on engineering efforts for Rollups were not used to accelerate L1 itself. We have invested a significant amount of R&D effort into Rollups, achieving many different approaches. Even if a shorter block time is achieved today, development would take at least 2-3 years.

Ethereum has chosen a very clear path. This path means no compromise on decentralization and does not touch "individual home stakers." Clearly, faster blocks would require changes to Ethereum's consensus, which would lead to a distribution of validators that is less than it is now. This is an important decision that the Ethereum community needs to make.

Conclusion

As Rollups evolve and gain popularity, fragmentation and isolation have become serious issues. Therefore, becoming a Based Rollup and joining a shared ordering layer is an important distinction. The shared ordering layer can be used for fast finality and cross-chain composability, but they require new trust assumptions and may fail, losing network effects. Based Rollups leverage Ethereum's existing infrastructure for block construction but face challenges in block time and revenue models. Nevertheless, it does provide a solution to liquidity fragmentation and full composability with L1 through its features.

The way forward may lie in new solutions like Based Preconfirmations and faster L1 block times to overcome the shortcomings of Based Rollups. These goals aim to improve user experience without compromising Ethereum alignment. Our aim is to create a scalable, decentralized, and user-friendly ecosystem that stays true to Ethereum's vision.

Choosing whether to be Based on Ethereum is not just a technical decision; it concerns the direction of the decentralized Rollup "framework."