Decoding Rollup’s Decentralization Path: The Dilemma Between Shared Sorting and Ethereum-Based

Original author: Taiko Labs

Original translation: TechFlow

Summary of key points

The Rollup-centric roadmap has resulted in a fragmented and isolated blockchain. This fragmentation 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. But this solution inherently requires new trust assumptions, as such a layer must have its own security set.

If we want to build a shared sorting layer for Rollup, Ethereum is the most trusted neutral layer we can build or use. Ethereum-based Rollup (i.e. Based Rollup) is inherently fully composable with Ethereum and other Based Rollups. However, as a Based Rollup solution, it also faces some challenges. The most important challenge is that the block time is the same as Ethereum, limited to 12 seconds. The solution is to provide a fast confirmation mechanism, such as a centralized sorter, or to speed up Ethereums block time. In the testnet, the speed based on pre-confirmation is faster than the current centralized sorter.

crossroads

Looking back at the beginning of the article, the direction chosen by Ethereum is important. Ethereum has embraced decentralization as a top priority since day one. This priority brings some limitations to the user experience. These limitations stem from the challenges of designing decentralized distributed systems (such as handling global state, sequential execution, etc.). This is exactly what distinguishes Ethereum from other L1s. They have chosen different paths. Other L1s choose to be fast and cheap by sacrificing some decentralization. They are fast and cheap because they have historical proofs, larger block sizes, and parallel processing. These concepts allow fast and cheap transactions, but also increase the burden on validators. This is why the hardware requirements for other L1 validators are higher than Ethereum.

Until Ethereum itself scales through upgrades such as history expiration, statelessness, Verkle trees, etc., we leave the task to Rollup.

Four years ago, Ethereum took a Rollup-centric roadmap, outsourcing execution to make it a more user-friendly environment until improvements arrived. Thanks to this, we reached a daily average of 250 TPS across all of Ethereum.

rollup.wtf

As mentioned above, it has been four years since Ethereum decided to adopt a Rollup-centric roadmap. During this period, a lot of experiments have been conducted on L2 about what Ethereum itself should be. AltVM (Fuel, Fluent), zkVM (Aztec, Starknet), zkEVM (Scroll, Linea, zkSync), Parallel EVM (MegaETH), etc. These all provide ideas for the future of Ethereum. But they also create many independent blockchains that dont even have any connection to each other. This is why shared sorting layers appear to solve the fragmentation problem.

Shared Sorting Layers

Currently, Rollup has a centralized sorter. This introduces huge censorship, liveness, and MEV extraction risks. If a Rollup wants to be decentralized, it can choose a shared sorter. By using a shared sorter, Rollup can take advantage of finality, decentralization, fast transactions, and cross-chain atomicity. As Vitalik said: Decentralizing Rollup requires 90% of the effort to develop a new L1. Therefore, by choosing a shared sorter, the engineering effort of decentralization can be avoided.

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

The shared sorting layer is a sorter market where Rollups can sell their block space (and proposal rights) to higher bidders on a slot-by-slot basis. This also creates a layer that redistributes MEV between all participating Rollups.

Focus

The shared sorting layer has a network effect that creates atomic composability and shared MEV between all participating Rollups. Rollups join the network to increase the value of their blocks (while decentralizing their sorters).

However, according to the system design of the shared sorter, the number of participating Rollups should be as large as possible. If the participating Rollup X leaves the chain, this MEV distribution will be disrupted, directly affecting the network effect. Therefore, shared sorting is an endless game, and participants must always stay in the game. As Rushi said , this is a pure B2B model.

The shared sorting layer runs a protocol like BFT next to 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 are offline or dishonest, the chain may lose liveness (they can use a fallback based on ). If the BFT protocol loses liveness, participating Rollups will not be able to take advantage of fast finality because they must obtain finality certification from the BFT protocol. Withdrawals from this layer will also be suspended. But even if the BFT protocol crashes, MEV redistribution will continue because in Espresso, for example, MEV redistribution is separate from the BFT protocol. In contrast, Ethereum has always been the strongest BFT protocol in terms of cryptoeconomic security and liveness.

Additionally, if they use restaking, there is a risk of restaking. If the hardware requirements of the validator are high, this will lead to monopoly. If the restaking service fails, there may also be large-scale slashing; see Eigenlayers risk FAQ for more information. For restaking methods in shared sorters, see the joint research of Nethermind and Fourpillar.

It is important to note that given that the shared sorter uses pre-confirmations, this process can be done on L1 (i.e. based on pre-confirmations), thus eliminating the need for a new layer. It should also be noted that the shared sorter still has to go through the L1 pipeline. Therefore, fast finality does not make sense here.

In summary, we believe that if the shared orderer layer is not decentralized and robust, they are a single point of failure. They will become the weakest link for all opt-in rollups.

Neutral composability is no longer a joke: Based on

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

Taiko is the first Based Rollup to use Ethereum as a sorting layer. Block construction is completely dependent on Ethereum. Anyone can propose a block, and the process is completely permissionless. Each Rollup can achieve composability by being based on Ethereum instead of adding a new layer. Since the slots of Ethereum and Based Rollup move synchronously, they are fully compatible with each other. This means that flash loans can be conducted on L1 and certain activities can be carried out on Based Rollup in the same slot (thanks to our BBR design, see here for details). But the Ethereum-based approach also comes with some costs.

Source: L2 Beat

We touched on this issue in the post “Central Considerations for Pre-Confirmed Based Rollups” , but let’s briefly summarize. As we said, Based Rollup has the same block time as Ethereum, 12 seconds. This means that Based Rollup needs to send its data to L1 via blobs (or calldata) every 12 seconds. If you can’t fill up the blobs with enough L2 transactions to cover the L1 fees, you will face a loss. In order not to pass this on to our users, we initially ate this fee ourselves and spent a lot of money. Today, proposers have block times of more than 12 seconds (about 20 seconds) in order to be profitable.

These are examples of the difficulties that Based Rollup goes through through the example of Taiko . In summary, the main problem is that block time and revenue limits are based on fees, not centralized sorters. You sacrifice revenue because sorting is completely permissionless and your MEV flows entirely to Ethereum, unable to capture any value from transactions ( Spire Labs is developing a framework to improve the revenue model of Based Rollup).

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

• Based on pre-confirmation

• Faster block times on L1

Based on Preconfirmations

Preconfirmation-based transactions simply use some L1 validators to provide preconfirmations for L2 users. Currently, preconfirmation-based transactions are running successfully on the Helder testnet, and lightning-fast transactions are now possible on Taiko (20ms in Gattaca’s demo and ~ 260ms on Arbitrum).

Titan-based pre-confirmation demo

In preconfirmation based, you do not inherit all the liveness and safety of Ethereum. You only trust a subset of Ethereum validator set. But it is worth mentioning here that we are getting trusted commitments from current Ethereum proposers. Anyone can become a preconfirmation provider by staking a certain amount of ETH on the registry contract. We explained the details of preconfirmation based in detail in a previous blog post, which can be found here .

The pre-confirmation based space is still in its early and evolving stages. It faces some threats, like the centralization of Ethereum blockchain construction, but with new approaches and research, more reasonable architectures will be designed. We will share our pre-confirmation design soon.

Faster blocks?

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

The main idea of a faster L1 is to adopt a consensus mechanism that can substantially reduce slot time. Single Slot Finality (SSF) is a consensus mechanism under consideration, specifically Orbit SSF , where each slot can be finalized in a few seconds. In the current Gasper protocol, the finalization time is 2 cycles, or 13 minutes. However, the disadvantage of SSF is that it is susceptible to 33% inactivity leaks.

The main question here is why if a faster L1 was always necessary, four years of engineering effort on Rollup was not spent on speeding up L1 itself. We put a lot of RD effort into Rollup, with many different approaches. Even if a shorter block time was achieved today, it would take at most 2-3 years to develop.

Ethereum has chosen a very clear path. This path means no compromise on decentralization and no touching of single household stakers. Obviously, faster blocks require changes to Ethereums consensus, and such changes will result in a smaller distribution of validators than is currently the case. This is an important decision that the Ethereum community needs to make.

in conclusion

As Rollup grows and becomes more popular, fragmentation and isolation become serious problems. Therefore, becoming a Based Rollup and joining a shared sorter layer is an important distinction. Shared sorting layers can be used for fast final confirmation and cross-chain composability, but they require new trust assumptions and may fail and lose network effects. Based Rollup leverages Ethereums existing infrastructure for block construction, but faces challenges in block time and revenue model. 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 pre-confirmation and faster L1 block times to overcome the shortcomings of Based Rollup. These aim to improve the user experience without compromising Ethereum alignment. Our goal is to create a scalable, decentralized, and user-friendly ecosystem that stays true to the Ethereum vision.

Choosing whether to base it on Ethereum is not just a technical decision, it is about the direction of the decentralized Rollup framework.