After years of research and development, L2 Rollup has emerged as the most widely adopted scaling solution for enhancing the performance of Ethereum's world computer. As an additional layer built on top of Ethereum, L2 Rollup offers significant benefits and has been embraced by the community.
L2 (Secured/Smart Contract) Rollup can be explained in various ways:
From the perspective of Validating Bridge: An L2 Rollup’s core is an optimistic or pessimistic validating bridge that bridges assets from Ethereum L1 to off-Ethereum L2 for faster transaction processing. The bridge is secured by fault/fraud or validity proof.
From the perspective of Rollup itself: An L2 rollup is simply about performing state transitions on inputted transactions with data availability on L1 to generate outputs with compression by sequencer. The system requires some forms of proofs (authority, fault/validity proof) to convince the base layer Ethereum blockchain or other networks.
From the perspective of Verifier (my version, more on L2 only): An L2 is based on the verifier contract for proofs on Ethereum. Any off-chain computation with all composable innovations can be settled on Ethereum, as long as the final proof passes.
In my version, L2 Rollup is a network that has:
On-chain data availability and settlement: public accessibility of historical state or input transactions data, and verification of commitment on Ethereum.
Off-chain execution: single state transition of transaction on L2 layer itself.
However, the off-chain execution actually involves not only single transaction state transitions, but also the sorting of transactions. In most cases, L2 sequencers do the sorting, while L2 validators compute for the new state.
Firstly, it can be argued that L2 Rollups do, in fact, enhance the performance of computers worldwide. However, a key issue with L2 Rollups lies in their current level of decentralization, which is not quite sufficient.
The transactions within L2 Rollups actually take the form of a unique different type of L1 transaction, albeit executed, bundled, compressed, and amortized in a manner that bolsters throughput. Nonetheless, the sequencer responsible for aggregating and sorting these L2 Rollup transactions typically plays a centralized role.
A centralized sequencer may have negative implications for the following centralization properties.
Weak censorship-resistance: Unlike the near infinite number of distributed nodes on L1, a centralized sequencer may not ensure that your transactions will be included on the chain. A centralized sequencer under the control of a legal entity may be subject to regulatory resistance to culling specific transactions. Although there are additional mechanisms available to address the weak censorship-resistance problem of L2’s centralization failure problem (such as force exit, escape hatch, inclusion lists, or adding threshold encryption), we still need to accept the assumption that centralized sequencers are more likely to have weaker censorship-resistance.
Weak liveness: The design of a centralized sequencer may not be able to handle the computational processing and proof generation required to keep a system running at all times. RPC or sequencer downtime due to hardware failure, excessive spam (eg. Arbitrum Token Launch, Optimism Delay), or operational failure (eg. Arbitrum Sequencer Out-of-gas and its own explanation) from validators or bots can lead to weak liveness of L2 Rollup.
MEV capture: The current centralized sequencer of L2 Rollup usually follows the first-come-first-serve rule for transaction sequencing. Additional trust is required to ensure that they will not extract MEV from user transactions through node privileges, or that the third-party sequencing services they adopt (like Chainlink FSS) will not be malicious.
It may be suggested that shared, outsourced, or based sequencer solutions could address these issues with tradeoffs, but it is still too early for such solutions. Additionally, many decentralized sequencer solutions (such as PoA, PoS leader selection, MEV auctions, and PoE) are still in the conceptual design stage.
Currently, the decentralized sequencer is not a priority of most L2 Rollups. Arbitrum has suggested that decentralized sequencer may become an optional feature.
In addition to the centralized sequencer issue, L2 Rollup may the centralization problems from high node hardware requirements, governance risks, and the app-rollup trend.
Running a full L2 Rollup node requires running an L1 node as well. This means that the hardware requirements for L2 nodes are even greater than those for L1 Ethereum, which could lead to further centralization issues. This is not yet a concern, as most L2 Rollups are not fully permissionless.
L2 Rollup is similar to a specialized on-chain protocol. Unlike traditional protocols such as DeFi and NFT, L2 lacks a mature management mechanism and established model DAO. Governance for L2, Optimism, and Arbitrum has been difficult due to the centralized nature (even sometimes similar to a centralized exchange) of most L2 Rollups. This makes it challenging to govern L2 Rollup in the absence of prior successful decentralization cases.
There has been discussion about deploying Uniswap as an App-chain or App-rollup. There are many tools available for Rollup, including Rollup frameworks (OP Stack, Rollkit, Sovereign SDK) and RaaS (Caldera, Eclipse, Opside, AltLayer). The proliferation of these underlying tools is promising for the future, with a multitude of new Rollups on the horizon. Each of these Rollups will need to address the aforementioned centralization issues. Among these new Rollups, the Sovereign Rollup is particularly challenging to decentralize. It is essentially a different lens for interpreting the same L1, or a velvet fork, or almost a separate L1 with hard-fork as a feature. Additionally, we have L3, an L2 Rollup on L2 Rollup.
The daily transaction count in L2 now surpasses that of L1 Ethereum. However, due to a centralized sequencer and other concerns, if we view L2 Rollup as a crucial aspect of the world computer, we may not attain the ideal balance of performance and decentralization.
To create a world computer, we require more than just L2 or modular blockchain. We need performance scaling with decentralization, as opposed to incremental decentralization with performance scaling.
The main difference between modular blockchain (including L2 Rollup) and world computer architecture lies in their purpose:
Modular Blockchain: Designed for creating a new blockchain by selecting modules (consensus, DA, settlement, and execution) to put together into a modular blockchain.
World Computer: Designed to establish a global decentralized computer/network by combining networks (base layer blockchain, storage network, computation network) into a world computer.
L2 Rollup effectively achieves the following:
Modularization of World Computer (more experimentation of consensus layer with some external trust on centralized sequencer)
Throughput Enhancement of World Computer (though it is not strictly "scaling")
Open Innovation of World Computer
However, L2 Rollup is not sufficient in the following areas:
More Decentralization of World Computer
More Performance Enhancement of World Computer (the maximum TPS of rollups added up is actually not enough, and L2 cannot has faster finality than L1)
Intensive Computation of World Computer (which involves computations beyond transaction processing like machine learning and oracle)
While the world computer architecture can have L2 and modular blockchain, it does not address the fundamental issue. L2 can solve the blockchain trilemma, but not the trilemma of the world computer itself.
We need a network that solves truly general-purpose intensive computing (especially machine learning and oracle), while preserving the full decentralization of the base layer blockchain.