The Fellowship of The Rollups: Rollup Framework, Shared Sequencer and RaaS

1. Introduction

The launch of new blockchain services in the form of rollups is becoming common standard these days. Even as this article is being written, there are ongoing developments where existing services are pivoting to Layer 2 (L2) or new services are launching on L2. However, there are still clear limitations to rollups becoming the foundational system for all applications. In a situation where the market penetration and expansion of rollups are sufficiently foreseeable, the development of solutions for easily deploying and operating rollups are consequently continuing. In line with the narrative of modular blockchains, a variety of protocols across different layers are being introduced. This article examines the current limitations of the rollup system and the solutions being proposed to address them.

Specifically, this addresses 1) Rollup Framework, which are currently laying the foundation for the rollup system, 2) Shared Sequencer that have emerged as protocols for the decentralization of sequencers, and finally 3) Rollup-as-a-Service(RaaS), which converts the complex and cumbersome operation process of rollups into a user(or developer) experience at the level of Web2. Each solution has its unique mechanism, but they share common elements in terms of the value they offer to users. This article aims to explore the mechanisms and features of each solution and how they might shape the future development of the rollup ecosystem.

1.1 Diverge, to Converge

Source: Polygon 2.0 Protocol Architecture

When new technologies and systems first appear, a variety of ideas are proposed, leading the system's design into a phase of divergence. During this process, experimental projects continuously emerge and disappear in cycles. However, once a certain threshold is met, the mechanisms and designs begin to converge towards a more standardized direction. The current rollup and modular ecosystem can be described as having just passed this threshold, moving towards a converging direction. The rollup ecosystem is now actively being adopted in the market, having moved beyond its nascent stage, with different projects converging towards similar approaches.

As “modular” blockchain implies, the rollup framework, shared sequencer, and RaaS are building new layers in their distinct domains and expanding upon them. Excluding the fact that they are based on the rollup itself, these are still in a diverging phase with various ideas being developed. However, similar to how Sidechain and Plasma faded into history and converged into the rollup, it's expected that these will also converge into few design space after passing through the experimental stage in the near future.

Not limited to blockchain, all solutions and businesses must build a value accrual model to construct their unique moats in the long term. To accumulate value over time, it's crucial to either achieve economies of scale or build network effects, thereby creating a sustainable flywheel. This article aims to explore how the solutions for building and operating rollups can develop their unique value accrual models.

Before delving into the main topic, it’s important to note that this is not intended to argue that one mechanism is superior to others. Blockchain is still not free from criticism of lacking practical value. It's clear that the primary challenge is transforming blockchain into a system that more users can seamlessly use, rather than competing among insiders. Moreover, most of topics covered here have just started being adopted in the market or is still in a pre-adoption state, which makes it difficult to imagine their ultimate forms. Technological development often exhibits path dependency. There is no single pre-determined way to reach the final solution, and this path is often modified due to external factors.

2. The Problems

The security of blockchain is generally determined by the economic and non-economic value possessed by the network. Therefore, establishing sufficient security is one of the biggest barriers to creating a new network or blockchain. Unlike Layer 1 blockchains, rollups inherit the security and data availability of another blockchain by recording and referring their data from it. For rollups, security and data availability can be obtained by paying fees, or using Consensus as a Service. This allows rollups to solve scalability issues without significantly sacrificing the security and censorship resistance.

Despite their potential, rollups are still in a nascent stage. As outlined in the Rollup Stage Framework by Vitalik Buterin, most rollups are currently at Stage 0. This early phase is characterized by reliance on centralized sequencers and user experiences that are less than ideal, especially when transferring assets across multiple chains. While operating a rollup may not be as complex as launching a Layer 1 blockchain, it still demands considerable effort and resources.

These challenges have been acknowledged since rollups' inception, prompting various proposed solutions. In Chapter 3, we will delve into these solutions, understanding the specific problems they aim to address and their unique characteristics. It's important to note that the issues discussed here are not exhaustive. Rollups involve numerous design considerations for optimization, and this article focuses on the primary concerns of the entities discussed

2.1 Sequencer Decentralization

Source: Starknet’s new Sequencer

The components of a rollup and their respective roles are as follows:

• Sequencer: This component collects and orders transactions submitted by users.

• Executor: Following the order provided by the Sequencer, the Executor executes transactions and derives the next state of the blockchain.

• Submitter: Transactions and the state values obtained through the execution are submitted to Layer 1 (L1) blockchain.

• Prover: Generates proofs for the finalization and verification of transactions.

Please note that each role need not to be appointed to physically separated parties. In the figure, the Sequencer includes the role of Executor and Submitter

The Sequencer, as one of the rollup nodes, collects transactions from users and then submits them in batch form to the Layer 1 blockchain. Therefore, the Sequencer has dominant authority over the inclusion and ordering of user transactions. The presence of a Sequencer is not essential for performing the core functions of a rollup. Sequencers were introduced during the evolution of rollups to provide a better user experience. By providing a soft commitment before the user's transactions are included in the Layer 1 block, the Sequencer enables rollups to achieve almost instant responsiveness.

Most rollups currently rely on a centralized sequencer for processing transactions. This sequencer, being centralized, offers operational efficiency as it bypasses the need for consensus or leader election among multiple nodes. However, this centralization presents notable risks, including reduced liveness and censorship resistance.

While rollups generally have an escape hatch mechanism allowing users to revert to Layer 1 for transaction enforcement, this process is cumbersome and labor-intensive. Furthermore, a centralized sequencer raises concerns about potential unfair transaction ordering, necessitating a high level of trust from users to avoid exploitation.

Source: L2 MEV wat, Taiko Labs

Unlike other rollup components, the sequencer does not inherit Layer 1's security. Operating independently with its own set of security assumptions, it lacks the deterministic nature of executors or provers. This highlights the need for a decentralized network of nodes specifically designed for sequencer operations.

There are various ways rollups can choose to operate a sequencer. Including the option of continuing with centralized node operation as it is now, there are possibilities such as building one's own decentralized sequencer network, using a Shared Sequencer, or leveraging Layer 1 to delegate the role of a sequencer to an external network. The alternatives frequently discussed for the decentralization of roll-up sequencers are as follows.

Source: Decentralized and Shared Sequencer Architecture, Elizabeth

2.1.1 Centralized Sequencer

Apparently, one viable option could be continuing to operate with a centralized node, as is currently used. This can provide users with sufficient security and fairness, while allowing a company or foundation to maintain sovereignty over node operation. Especially for relatively conservative groups like large corporations or institutions, this might be a much more attractive option compared to Enterprise or Private blockchains.

2.1.2 Establish Own Decentralized Sequencer Network

The development of decentralized sequencers for rollups presents a variety of approaches, ranging from Proof of Authority and Leader-based Proof of Stake to Committee configurations. However, each rollup constructing its own network could lead to inefficiencies within the broader ecosystem and create high barriers for newcomers. This approach potentially limits the value proposition of rollups, which inherently differ from Layer 1 blockchains in that they do not require building their own validator network.

A more feasible solution might be to decentralize sequencers at higher level of aggregation, rather than individually for each rollup. This collective approach is currently under consideration by many in the rollup community. The implications and details will be explored further in the following sections

2.1.3 Shared Sequencer

The 'Shared Sequencer' concept introduces a system where a decentralized sequencer layer is shared among multiple rollups. This setup allows rollups to achieve sequencer decentralization without the necessity of building and maintaining their own sequencer nodes or networks. In this model, a rollup's role is primarily limited to transmitting user transactions and executing the transaction order set by the Shared Sequencer, thereby deriving state values.

From the perspective of a rollup, this approach significantly reduces the complexity and effort required in deploying and operating their network. However, it's not without its challenges. Sharing transaction fees and Miner Extractable Value (MEV) with another entity, as well as giving up a degree of control over node operations, are considerable trade-offs.

The concept of a 'Based Rollup,' which employs a Layer 1 blockchain for transaction ordering, is another innovative proposal not mentioned here. By assigning the sequencer role to Layer 1 blockchain validators, this approach could potentially offer enhanced Liveness and Censorship Resistance compared to either building a dedicated sequencer network or utilizing a Shared Sequencer network.

However, practical challenges exist with this model. Rollup users generally expect near-instantaneous (~1s) transaction finality, a standard set by the Soft Commitment at the sequencer level before recording the block on Layer 1. Relying on a Layer 1 blockchain as a sequencer would extend transaction times significantly, with a minimum wait of about 12 seconds and often stretching to several minutes. Thus, while the Based Rollup concept is intriguing, its application might be limited to specific scenarios, such as during a sequencer malfunction, rather than as a standard operational model.

2.2 Economics of Rollup Operation

Source: Understanding rollup economics from first principles, BARNABÉ MONNOT

First, let's examine the basic economic structure of a rollup. The revenue of a rollup consists of transaction fees paid by users and the MEV revenue extracted from these transactions. Optionally, the rollup's congestion fee can be considered here. So far, transaction fees have been the dominant source of revenue for most rollups. Although there are currently no rollups directly collecting MEV revenue, it's expected to constitute a significant portion of rollup revenue in modular systems with PBS (Proposer-Builder Separation) applied. Presently, about 5-10% of total Ethereum revenue is generated from MEV.

The costs associated with operating a rollup can be categorized into two main types: the indirect operating costs of running a sequencer or RPC node, and the direct costs of submitting data to Layer 1. The latter varies significantly based on the ability to efficiently generate and compress proofs. For optimistic rollups, cost variations are largely dependent on the extent of data compression achieved. In the case of ZK rollups, the focus shifts to minimizing the expenses involved in proof generation and verification. The impending implementation of EIP-4844 is poised to substantially lower the costs related to Layer 1 data submission. On the other hand, the costs of managing a sequencer or RPC node, which are independent of chain operations, can vary widely. This variation is often contingent on the operational team's expertise and experience. In essence, the profitability of a rollup can be summarized by the formula: Transaction Fee + MEV Revenue - Operation Cost - Layer 1 Submission Fee

As rollups evolve towards modularization, a key emerging challenge is the lack of clear criteria for allocating revenues and costs among various components. It's expected that new layers and systems, which are still in the conceptual or discussion stages, will become integral to the rollup ecosystem. However, the specific mechanisms for rewarding these new elements, among other details, are yet to be determined. These aspects remain as open questions.

1) Horizontal Distribution

First, consider the distribution of revenue among various rollups. Transaction fees can be relatively simply allocated based on each rollup’s contribution. However, for profits like Cross-Domain MEV revenue that generated from a combination of multiple rollups, there’s no straightforward method to determine the distribution ratio to each rollup. With the application of Proposer-Builder Separation (PBS), profits are expected to be returned to rollups or their users in the form of order-flow auctions(OFA). However, the same problem remains equally challenging for individual MEV searchers to precisely calculate bid for each rollup.

2) Vertical Distribution

The complexities of revenue and cost distribution in vertically integrated rollup systems, where various entities contribute to the ecosystem, indeed present a significant challenge. When each component of a rollup, such as execution nodes, sequencers, and provers, operates as an independent layer, the need for a robust framework or methodology to fairly allocate costs becomes paramount.

Further complications arise when different layers in the system use distinct tokens. For instance, if a rollup and a Shared Sequencer each require fees in their respective tokens, users would face the inconvenience of needing to hold and pay in two different types of tokens to submit a transaction. This not only adds a layer of complexity for users but also raises questions about the efficiency and user-friendliness of such a system.

The cost implications of operating a rollup, particularly for small and medium-sized long-tail services, are substantial and varied. There is clear limitation of rollups not be a feasible solution for every application. Even in a minimized form, the foundational requirements for setting up a rollup are considerable. These include a sequencer, nodes for executing and verifying transactions, a Submitter for updating the rollup's state on Layer 1, and RPC providers. Utilizing pre-built open-source solutions, such as the OP Stack, doesn't significantly reduce the complexity; integrating and managing each component within an existing infrastructure demands substantial technical expertise and ongoing maintenance. The complexity and costs escalate further with the addition of unique execution environments or reward/punishment mechanisms. While it might be theoretically ideal for each project to have an execution environment tailored to its specific needs, the reality is that this requires advanced technical capabilities and can result in operational inefficiencies.

Setting aside the considerable operational demands previously discussed, an additional challenge for new projects in the rollup space is the ongoing fixed cost required to maintain the system's liveness. To remain functional, a rollup must consistently submit proofs of transactions and state values to the Layer 1 blockchain. In the current OP Stack, for example, there is a requirement to regularly submit blocks to Layer 1, even in periods of inactivity. This may be relieved in future updates. This requirement incurs gas costs ranging from approximately $20K to $30K per month just for data submission on an optimistic chain.

Furthermore, the cost-efficiency of generating proofs in most rollups decreases with fewer transactions, which puts more financial burden for smaller projects. Unlike well-established projects with a substantial user base and regular fee collection, early-stage projects must absorb these expenses as a fixed cost. Thus, for a newly launched rollup, enduring the fixed costs of chain becomes a critical and often daunting aspect of their development and sustainability strategy.

2.3 Compatibility

Currently, there are about 30 rollups listed on L2Beat, and this number is rapidly increasing. New rollups not included in this list are continuously being launched. It is expected that an unenumerable number of rollups will emerge in the market in the near future. However, a major challenge with the current state of rollups is their isolated ecosystems. Users who interact with multiple chains often are forced to cumbersome and inefficient bridging methods to move assets between these chains. This results in a fragmentation of liquidity and a disjointed user experience. For applications prioritizing seamless and user-friendly experiences, the compatibility of different chains is becoming increasingly crucial. In an ideal scenario, akin to the ease of use in Web2 environments, users should be able to transact and exchange assets across multiple chains seamlessly, without the need to be aware of the specific chain their assets are on. As the rollup and modular ecosystem evolves, the necessity for a layer that ensures reliable compatibility becomes significant.

Compatibility of blockchain can be broadly categorized into two properties: Composability and Interoperability, each playing a distinct role in the context of rollups. Composability, in the context of rollups, involves different blockchains sharing a common layer while ensuring atomicity in transaction ordering and execution. Atomicity, in this sense, means that transactions submitted across different chains are executed in an all-or-nothing manner — they are either all executed or none are executed. Interoperability, on the other hand, refers to the capacity for different blockchains to exchange data. The integrity of the data within a blockchain is maintained only within a single chain that adheres to the same state transition function. However, to facilitate the transfer of assets or data from one chain to another, an additional layer should be involved. The interoperability layer, which connects different chains, provides guarantee on the state of each rollup through trust assumption for third party, or cryptographic verification

It's important to note that the semantics of these concepts can vary. For instance, in some discussions, composability is sometimes described in the context of transferring transactions between different rollups. However, in this article, composability and interoperability are distinctly defined, to clearly present how the roles of sequencers and execution nodes are differentiated in rollups.

To facilitate seamless asset exchanges and application compatibility across multiple chains, both composability and interoperability are required. Achieving this necessitates an aggregation layer where multiple rollups are interconnected, either for transaction ordering or state synchronization.

For composability, which focuses on achieving consensus on the transaction order among various rollups, a sequencer of each rollup need to be aligned in a single layer. This layer would manage the sequencing of transactions from multiple rollups, ensuring that they are ordered in a consistent and atomic manner across different chains. This approach would guarantee that transactions either complete across all chains or not at all, maintaining the integrity and reliability of multi-chain transactions.

On the other hand, interoperability involves the verification of states across different chains. Thus, a layer that facilitates the execution of transactions (Executor) or the verification of these states (Prover) is needed. This layer would not only allow different rollups to execute transactions based on a mutually understood state of each chain but also provide a mechanism for verifying the accuracy and consistency of these states across the rollups.

To understand the difference between composability and interoperability, consider a scenario where a flashloan is used to execute arbitrage between different chains. The process of the arbitrage transaction goes as follows:

1. Borrow 1000 USDC through a Flashloan smart contract located on Rollup A.

2. Exchange 1000 USDC for 1 ETH in the WETH-USDC Pair on Rollup A.

3. Send 1 ETH to Rollup A's bridge, and withdraw it from Rollup B's bridge.

4. Exchange 1 ETH for 1001 USDC in the WETH-USDC Pool on Rollup B.

5. Send 1001 USDC to Rollup B's bridge, and withdraw it from Rollup A's bridge.

6. Repay the flash loan with 1000 USDC and retreive the profit of 1 USDC.

Let's examine which attributes of rollup compatibility mentioned earlier are applied at each step. First, the swap transactions (2, 4) occurring on each chain inherently assume atomicity. If the transaction occurs on only one of the chains, the arbitrage strategy fails, exposing the trader to unintended asset risk. Ensuring the ordering and atomicity of transactions across different rollups is precisely what composability refers to.

Furthermore, the arbitrageur needs to transfer the asset exchanged on one chain to another chain (3, 5). This requires interoperability between the two chains. When transferring assets from Chain A to Chain B or vice versa, it’s necessary to verify the state of opponent chain. The method for verification can involve an additional validator network, trust in a third party, or zero-knowledge proofs.

3. The Solutions

3.1 The Good: Rollup Frameworks

3.1.1 Overview

Currently, rollup frameworks hold a dominant position in the modular blockchain and rollup ecosystem. For clarity, rollup frameworks are referred to as a project building base code and system for rollup, which are distinct from the general concept of the rollup itself. Well-known examples include Arbitrum, Optimism, zkSync, and Starknet. The goal of these rollup frameworks is to expand their ecosystems. However, the difference between Alt-L1s lies in the scope of their ecosystems. The scope extends not just to their own chain but also to other chains that use the same framework and share resources. Most rollup frameworks are actively working to integrate other chains based on their respective structures, or 'stacks.' Optimism's Superchain, Polygon 2.0, and Starknet's SHARP, these frameworks share fundamentally similar structures except few details.

The common design adopted for these frameworks are shared components among multiple rollups (or network of chains). Establishing a rollup involves the complex task of building and managing various components, demanding substantial effort and resources. Just as rollups inherit security and consensus mechanisms from Layer 1, other rollups can also utilize components from established rollups. The shared components can include the executor, the prover or a validating bridge located in Layer 1. The consolidated rollups connected with the shared component now forms an integrated layer to operate in an interoperable way.

The structure of the stack, or networks of chains, provided by rollup frameworks generally has the following characteristics:

3.1.2 Shared Bridge

Source: zkSynz Docs

The concept of utilizing a rollup framework often includes a shared bridge on Layer 1. This method is frequently observed in configurations where multiple Layer 2 or Layer 3 chains constitute a fractal or balanced structure. This design facilitates fast and seamless mutual verification among rollups interconnected via the same bridge. Now the bridge connected with multiple rollups acts not only as a custodian for the assets it holds, but also as a medium for verifying and relaying messages between rollups. This setup's most significant advantage is the ability of rollups within the network to offload the execution of transactions to underlying rollup’s executor. The rollup project’s only requirement is reduced to collect and sequence transaction from the user, and then submit it to other executor.

Source: zkSync Docs

To grasp concrete understand, let's examine the structure of zkSync’s Hyperchain. The Hyperchain has a fractal structure sharing a bridge (Executor + Prover) located on Layer 1. Rollups within the Hyperchain are connected to the Hyperbridge, allowing them to transfer assets under trustless conditions with other chains in the system. The Hyperbridge uses the transaction and Merkle root of the withdrawal chain to validate the transaction and its state at the shared bridge. The receiving chain then compares the verified root from L1 and the transaction relayed from the withdrawing chain to execute the transaction.

Even when a user calls a smart contract on another chain, there is no need to transfer assets directly through the bridge; the transfer of assets to the execution of the transaction on that chain happens through a relayer. Excluding the time taken for proof generation (about 1-15 minutes), the user experience and gas costs are minimally different from transactions within a single chain.

3.1.3 Proof Aggregation

Source: Joining Forces: SHARP, Starknet

The proofs submitted by rollups to Layer 1 (L1) generally incur less variable costs associated with the size of the data but rather influenced by fixed costs. As a result, the marginal cost usually decreases with the inclusion of more data in a single proof. For Optimistic rollups, employing Shared Batch Posting can reduce costs, while ZK rollups can gain even greater efficiency through Shared Provers, which is more cost-effective than generating proofs for individual chains. Quite intuitively, the cost-saving effects are usually more significant in ZK rollups than in Optimistic rollups.

An example of proof aggregation can be seen in Starknet’s SHARP structure. SHARP is a system designed for efficiently generating proof by bundling several transactions into a single proof and verifying them as one. As the costs of processing proofs on Layer 1 are shared across all rollups using the shared prover, it offers greater cost efficiency, especially for smaller applications with fewer transactions. SHARP uses recursive proofs to process and verify multiple STARK proofs in parallel. Rather than waiting for all batches to be submitted, SHARP generates proofs as soon as statements from each rollup are received, enhancing overall efficiency.

3.1.4 Layer 3

Source: Arbitrum Docs

Much like how rollups rely on Layer 1 blockchains for settlement, Layer 3 (L3) rollups use Layer 2 rollups for the same purpose. This structure enables L3 rollups to achieve scalability and cost efficiency. By leveraging the infrastructure of Layer 2, L3 rollups can either utilize existing services or modify them to develop unique functionalities or specialized execution environments. L3 model is particularly advantageous for new services or Web2 companies, allowing them to maintain Ethereum as the settlement layer while adopting more cost-effective Data Availability solutions like Validium. It can be used in services where security demands are not as high, but require faster user acquisition, such as games, social networks, and NFT-related products.

A prominent example of an L3 service is Arbitrum Orbit. Arbitrum Orbit is a platform for deploying L3 rollups on Arbitrum L2. Rollups deployed using Orbit can leverage Arbitrum’s infrastructure, such as Fault Proof and Account Abstraction, while configuring customized execution environment, such as Stylus, alt DA layer, gas tokens, etc. To deploy a rollup on Orbit’s Portal, all that is needed is Docker and a wallet with more than 1.5 ETH on the testnet. Furthermore, chains built using Orbit are not isolated but can transfer assets and interoperate through interchain functionalities, providing advantages over standalone rollups. (Note that this feature is still under development).

Source: Rollups are Real, Davide Crapis

Different projects are intentionally cited as examples for each structure to emphasize the relative differences and similarities. In summary, although each frameworks may have slightly different methods or keywords, the value that the structure aims to achieve is generally similar. By leveraging the shared economy model, these rollups enhance cost efficiency in the common elements and improve compatibility between them.

3.1.5 Value of Rollup Framework

1) Interoperability

The function of a rollup's bridge is not limited to merely transferring assets. It also facilitates the operations of transactions within each rollup, serving as an off-chain oracle for others. This bridge organizes and validates transactions from each rollup, ensuring the integrity of their operations. By verifying the sequence and the execution of all transactions through a single bridge, it establishes a unified layer for sequencing and verification across all rollups. Transactions processed via this shared bridge can function as a Global Sequencing Layer, allowing for the integration of transactions from distinct chains into a single total ordering. Additionally, the bridge's role in verifying each rollup's state enables it to support the transfer of messages between different rollups, further enhancing interoperability.

2) Efficiency Through Shared Economic Model

Rollups that are constructed using a same rollup stack often share nearly identical components. Rather than creating these elements from the ground up, utilizing the infrastructure of an existing Layer 2 network can effectively address the initial setup challenges for new chains being launched. Furthermore, the strategy of sharing bridges, executor or provers within the same ecosystem introduces a collective economic model for components that require significant fixed capital investment. This makes the continuous process of proof generation and submitting blocks to Layer 1 both efficient and cost-effective for operating the rollup.

3) Customization

Rollups can have the option to select specialized execution environments or to utilize more cost-effective Data Availability layers, albeit at a potential compromise in security. This approach can be particularly appealing for new projects that are cost-conscious and have less demanding security needs. Conversely, projects that require specialized environment may choose to invest in developing a custom environment without building it from scratch. The special environement might include enhanced privacy or high computational demands. Despite the customization, they can still maintain compatibility within the broader existing ecosystem, allowing for a balance between specialized needs and ecosystem integration.

3.1.6 Limitation & Risks

The choice of a specific rollup framework, while offering high efficiency and compatibility within a network, presents a degree of risk for projects, particularly concerning their long-term viability and flexibility. The rollup ecosystem is entering a phase of intense competition, marked by rapid change and significant development. Similar to the dynamics observed in the Alt-L1 confrontations, it is expected that over time, the market will coalesce around a few dominant players, likely 2-3 key ecosystems. Those networks that don't succeed in building substantial network effects may gradually diminish in relevance and presence.

In this context, projects face uncertainty about which ecosystems will thrive in the long run. Deep integration with a single ecosystem can thus be seen as a significant risk, given the dynamic and competitive nature of the space.

Taking zkSync's Hyperchain as an example, chains interconnected through this system share a uniform security level due to their connection to the Layer 1 bridge. This architecture means that once a chain is launched within this framework, it lacks the flexibility for potential hard forks. In other words, individual projects cannot independently upgrade their rollup chain. A collective hard fork of all zkSync rollups would be necessary for such an upgrade, an event unlikely to occur unless prompted by a severe security threat.

While individual projects could theoretically launch a new chain and transition to it through social consensus, this process would likely be daunting and challenging. This scenario underscores the importance of carefully considering the long-term implications and potential constraints of committing to a particular rollup framework in the rapidly evolving and competitive landscape of rollup ecosystems.

3.2 The Bad: Shared Sequencers

3.2.1 Overview

Source: Sharing a Sequencer Set by Separating Execution from Aggregation

The core principle of the Shared Sequencer model is the separation between sequencing and execution in the functioning of rollups. This approach involves assigning the role of sequencer to an external entity, effectively transforming rollups into more minimized versions of blockchain. This strategy is similar to the concept of lazy evaluation in computer science and thus is termed 'Lazy Rollup'. By adopting this model, newly initiated rollups can alleviate the complexities involved in setting up their own sequencers, establishing transaction ordering protocols, and managing mempool. Rollups simply delegate the sequencing process to the shared sequencer, allowing them to concentrate exclusively on executing the incoming transactions.

The shared sequencer is a network specialized solely in transaction ordering, excluding the task of executing transactions and computing the state. It collects transactions from various rollups and orders them for submission to Layer 1 without verifying their content. This statelessness allows the shared sequencer to provide horizontal scalability to multiple rollups by removing the computational requirements needed for execution and proof generation.

The shared sequencer's design is agnostic to the specific type of underlying rollup, allowing it to integrate transactions from diverse rollups into a unified sequencer block. This approach of utilizing a collective set of sequencers ensures that transactions maintain atomicity across multiple rollups. However, it's important to note that the shared sequencer's assurance of atomicity is restricted to the inclusion of transactions within a block. It does not guarantee on the actual execution of these transactions within the rollup itself. Consequently, the responsibility for the final execution and completion of transactions rests with the individual rollup's nodes.

3.2.2 When PBS meets Shared Sequencer

Source: SUAVE, Anoma, Shared Sequencers, & Super Builders

The lack of transaction execution capabilities, can be mitigated through the implementation of Proposer-Builder Separation (PBS). The design of shared sequencer stems from the separation of rollup sequencers and execution nodes. Going further, transaction ordering and block creation within the sequencer can be exported to external entities, or builders. Consequently, the role of the shared sequencer is again reduced to primarily focus on signing and submitting blocks. This is analogous to how MEV-Boost in Ethereum operates currently.

In the PBS applied model, the traditional approach to transaction ordering is replaced by a decentralized block generation network, such as SUAVE. Within this framework, the shared sequencer and SUAVE play complementary roles, collectively enhancing the finality and reliability of rollups. SUAVE aggregate transactions from various chains and submit them as a block or bundle, fulfilling the builder role. However, SUAVE do not participate in the block proposal process on the according chains. In contrast, the state-agnostic shared sequencer is not involved in the block creation process or in the extracting value from it. Rather, shared sequencer operate as a proposer in Layer 1, which collect submitted block and then submit to elongate the chain.

The synergy between the shared sequencer and PBS model establish greater confidence in the blocks they submit. This approach is in line with the principles of Optimistic Relay, as currently employed in Ethereum's MEV supply chain. Optimistic Relay operates by transferring blocks created by builders to proposers without executing them. This system relies on the assumption that block builders are economically incentivized to not submit incorrect blocks. Such a setup aims to maintain efficiency while not substantially compromising the security of the overall system.

3.2.3 Value of Shared Sequencer

In summary, advantages of which shared sequencers provide to rollups can be described as follows:

1) Sequencer Decentralization and Pooled Security

Shared sequencers play a crucial role in aiding rollups to decentralize their sequencer without the necessity of creating their own networks. If each rollup were to establish its own network, it would lead to inevitable fragmentation of liquidity and security. By utilizing a unified sequencer layer that serves multiple chains, rollups can avoid the inefficiencies associated with developing their own networks.

The pooled security, where multiple chains are protected under a unified framework, typically provides a higher level of security and stability than what could be achieved by individual networks created by separate rollups. The inherent design of shared sequencers, which focuses solely on the aggregation and ordering of transactions, facilitates high horizontal scalability. This means that as new rollups are integrated, the system can expand without compromising on performance or security, effectively enhancing the overall throughput.

2) Economic Utility and Reduced Operation Complexity

Shared sequencers provide economic efficiency by enabling connected rollups to utilize shared resources. This approach is more cost-effective compared to each rollup independently managing transaction ordering and block submission to Layer 1. The expenses associated with building and maintaining the sequencer network are distributed across multiple parties. This collective strategy results in a more economically efficient system that benefits all the rollups involved.

Moreover, the use of a shared sequencer substantially reduces the technical and operational burdens for individual rollups. The sequencer constitutes a significant part of the deployment and operation of rollups. Rollups are relieved from the complexities of developing their own sequencers or networks, allowing them to concentrate more on their core business and product development.

3) Composability and Cross Domain MEV

The shared sequencer functions as a global sequencing layer for interconnected rollups. This integration enables atomic transactions across different rollups. The atomicity achieved by the sequencing layer not only provide compatibility, but also additional revenue via cross domain MEV. In the previous example presented at Chapter 2.3, the revenue generated by the arbitrage trader will also be distributed to the rollup as a bid of an Order Flow Auction(OFA).

3.2.4 Limitation & Risks

When rollups opt for a shared sequencer, they benefit from reduced costs and efforts associated with managing their own sequencer. However, this comes at the cost of giving up control over the transactions submitted to their rollup. Handing over sequencer authority to an external entity significantly diminishes the control that the projects operating the rollup would otherwise have. This is in contrast to a model where rollup frameworks share bridges, but maintain individual control over their sequencers. Given that the decentralization of sequencers is yet not a primary concern for either consumers or providers, delegating sequencer authority can be perceived as a substantial compromise of control over their blockchain.

For rollups that are actively operating today, like Optimism and Arbitrum, there seems little incentive to abandon their own sequencers in favor of external ones. In the short term, there is no sign of sequencer decentralization to become a priority concern for them. Should the need for decentralization become more pronounced in the future, developing their own network might be a more logical choice. It is true that having separate networks for each rollup may seem inefficient from a wholistic perspective. However, from the viewpoint of individual projects, it can be a viable justification for issuing their tokens. Given that many rollups issued tokens with minimal utility, establishing their own sequencer network could serve as a reasonable execuse.

While shared sequencers are often depicted as a means to enhance compatibility among rollups, their scope of compatibility is somewhat limited. They primarily ensure that transactions from different rollups can be forged into a single block. However, for users to seamlessly interact between different rollups, not only transaction atomicity but also verification of each other's states (bridging) are necessary. The limitation of shared sequencers lies in their inability to execute or verify the transactions or the state of each rollup. Consequently, achieving true interoperability between rollups necessitates a connection with an additional layer, such as a bridge network or a relay system.

3.3 The Ugly: Rollup-as-a-Service(RaaS)

Rollup-as-a-Service (RaaS) is a turnkey solution that simplifies the deployment of a rollup, making it accessible to anyone. This service elevates the user(or developer) experience to a level of convenience comparable to Web2 services. With RaaS, deploying a rollup chain becomes as trivial as a few clicks, without writing a single line of code. It also typically includes auxiliary features to operate a chain, such as an Explorer, Faucet, and Wallet Integration. RaaS can be describe as an AWS or Stripe for rollups and modular blockchains, in terms of convenience and functionality. While the rollup frameworks provide significant benefits in terms of deployment and operational efficiency, they may not quite reach the level of customer success offered by RaaS.

3.3.1 Value of RaaS

The advantages provided by RaaS for launching rollups include:

1) Stable Scalability and Performance

The sequencer is pivotal for collecting and processing the transaction from users. Any instability or failure in the sequencer can result in catastrophic financial and non-financial damage for both the project. Rollup-as-a-Service (RaaS) addresses this critical need by providing a sequencer that offers flexible scalability and high availability. This capability allows rollups to adapt efficiently to fluctuations in network traffic, ensuring consistent performance. The stability and reliability offered by RaaS are essential for maintaining and building trust with its project and users.

2) Comprehensive Infrastructure and Services

For an optimal user experience, it's required to focus not only on the deployment of rollup, but also on the integration of additional features. RaaS extends its offerings beyond just the sequencer, encompassing essential components required for operating a chain. This includes tools like bridges for cross-chain interactions, explorers for transparency, and other components.

Such comprehensive provision not only streamlines the deployment process for individual projects but also ensures a seamless and user-friendly experience for both the operators and users of the rollup. This holistic approach by RaaS significantly contributes to the overall functionality of rollup projects

3) Customer Success and Maintenance

The cost and effort of operating a self-hosted rollup chain do not end with the deployment process. Like many technical products, it requires technical support and ongoing maintenance. RaaS platforms include educational and technical support for rollup operators, providing assistance for long-term success of a customer.

These features underscore RaaS's value proposition, offering not just a deployment solution but a comprehensive ecosystem that supports the entire lifecycle of a rollup project, from launch to sustained operation. This makes RaaS an attractive option for entities looking to leverage blockchain technology without the overhead of managing complex infrastructure.

3.3.2 Limitation & Risks

1) Lack of a Shared Economy Model

In contrast to other solutions discussed in this article, such as integrating within a rollup stack or connecting to a shared sequencer, rollups launched using a RaaS platform exist in isolation, sharing no components with other rollups, except for Layer 1. Therefore, they may not benefit from cost savings through a shared economy model as much as solutions utilizing shared sequencers or bridges. This also implies potential compatibility issues with a shared bridge model in the rollup stack. While interoperability solutions between rollups are still largely under development, increasingly integrated rollup stacks could leave isolated chains missing out on network effect benefits.

2) Lock-In

Deploying a rollup using a Rollup-as-a-Service (RaaS) platform is similar to handing over the management of your rollup to an external agency. This approach inevitably leads to a degree of reliance on the service provider. Generally, launching a new chain requires much higher standard than operating projects using smart contracts. Given this, the high level of reliance and trust can affect as a non-trivial risk for both operators and users.

Additionally, multiple factors could lead to a change of the original service provider in the future. The factors could include unstable operation, changes in pricing policies, market dynamics in the rollup ecosystem, or the emergence of a superior RaaS platform. However, the transition to a different service provider might be daunting and challenging. The reason is that RaaS services, with their Web2-level comprehensiveness, integrate not just the rollup chain but also the associated infrastructure and additional components into their offering. This deep integration with the RaaS package could significantly complicate the process of moving away from the initial service provider.

3) Conflict of Interest

Source: Value accrual for Rollup frameworks and RaaS

The potential conflict of interest between Rollup-as-a-Service (RaaS) providers and rollup frameworks is an important factor to consider in their long-term relationship. RaaS services often use open-source developments from rollup frameworks, taking publicly available resources and repackaging them for their clients. They generate revenue by charging for the construction and operation of rollups and sequencers, but this revenue is typically not shared with the creators of the rollup frameworks.

From the perspective of projects operating as a rollup, there is little motivation to share revenue with rollup frameworks when utilizing their open-source code. Consequently, rollup frameworks must explore alternative ways to attract and retain customers beyond just issuing tokens. As mentioned earlier in the section "3.1 Rollup Frameworks", one effective approach could be to build network effects through a shared economy model or by enhancing interoperability between rollups. This strategy involves enhancing cost efficiency or compatibility features between rollups to create network effects, thereby drawing in more customers.

3.4 The Comparison

Each solution has its unique characteristics and offers different approaches to address the limitations of the rollup system. Consequently, each solution has its strengths and weaknesses, as well as trade-offs. Let's briefly summarize the content discussed so far and compare each solution here.

3.4.1 Sequencer Decentralization

Many rollup frameworks have recognized the importance of sequencer decentralization, and aim to include it in their development plans. However, the practical implementation of decentralized sequencers is often procrastinated by other priorities such as establishing a market presence and ensuring operational stability.

On the other hand, shared sequencer projects like Espresso and Astria provide an alternative by allowing rollups to connect to an existing decentralized network. This approach offers high security and trust levels without the individual burden of constructing and maintaining a decentralized infrastructure.

RaaS has no direct relationship with sequencer decentralization by itself. However, compatibility of modular blockchain can mitigate their limitation. For example, Caldera, one of a prominent RaaS provider, claimed its partnership with Espresso. This implies that rollups deploying using the service can be offered benefits from both service and protocol.

3.4.2 Cost Efficiency

Rollup frameworks and shared sequencers both aim to achieve cost efficiency via shared economy model, but they do so in different ways. Rollup frameworks typically share components like bridges and provers among multiple rollups, reducing the need for each rollup to develop and maintain its own infrastructure. This sharing of resources leads to significant cost savings. Meanwhile, shared sequencers provide a network of sequencers to multiple rollups, allowing them to avoid the costs and technical challenges of building and operating their own sequencers.

The Rollup-as-a-Service (RaaS) model offers a different approach, catering to teams that might not have the capacity or interest in building and operating their own rollup infrastructure. RaaS platforms take on the operational complexities, allowing client projects to focus on their core activities.

3.4.3 Compatibility

In rollup frameworks using a shared bridge approach, individual rollups collect and arrange transactions by running their own sequencer. Thereafter, these transactions are ordered and verified at a shared Layer 1 bridge. This setup allows for interoperability and verification of states between rollups within the same framework.

Shared sequencers, on the other hand, focus on determining the order of transactions without executing or verifying them. Shared sequencer ensure that transactions are included in a block with atomicity across different rollups. However, shared sequencers alone cannot facilitate the actual transfer of tokens or data between chains, indicating a need for additional layers or mechanisms to achieve full interoperability.

Again RaaS cannot offer interoperability inherently. However, it can be achieved via connecting with external solutions. The solution can include rollup frameworks or other trusted third parties. The openness and neutrality can be beneficiary, especially when the market is highly segmented and there is no single party that can be fully aligned with a project.

4. What’s Next?

Rollup frameworks, shared sequencers, and RaaS (Rollup as a Service) each present distinct systems and value propositions, catering to different customer needs and use cases. However, they operate in a competitive landscape where some degree of competition is inevitable. For example, the Layer 3 or shared bridge solutions that rollup frameworks offer have considerable overlap with the functionalities provided by RaaS. This is particularly noticeable in the process of rollup deployment, such as Arbitrum's Orbit Portal and Conduit. Such overlaps hint at the possibility of vertical integration within these services, especially if one begins to accumulate significant value over the others.

Certainly, the customer value offered by RaaS, particularly in the context of ongoing operation of sequencer, uniquely position themselves from what rollup frameworks provide. This differentiation is akin to the diverse array of solutions available in Web2 for building data pipelines or websites. Various solutions can coexist, each offering different levels of abstraction and specialization. Given this landscape, it's unlikely that any single solution will completely dominate or render the others obsolete. Instead, these solutions are more likely to continue coexisting, each serving its niche and contributing to the broader ecosystem in its own way. This diversity not only fosters innovation but also ensures that customers have access to a range of options tailored to their specific needs and technical capabilities.

The shared sequencer model, by its nature, operates independent of the individual rollups, allowing it to serve as a unifying aggregator for multiple rollups. As competition among rollup frameworks intensifies, their market may remain fragmented, potentially necessiating to a convergence into a more unified layer. In this scenario, the shared sequencer, not being restricted to any single rollup framework, could emerge as a central, platform-like layer to unite them. This arrangement offer a cohesive user experience across different frameworks and thereby enhancing their collective network effects.

On the other hand, a more cautious scenario is also plausible. One significant challenge for the widespread adoption of shared sequencers is the indifference of successful Layer 2 projects, like Optimism and Arbitrum, to move away from their centralized sequencers. This reluctance could be particularly strong if these projects do not perceive a high demand for decentralization or if they prioritize maintaining control over their sequencer revenue. The prospect of cross domain MEV as an additional revenue stream for rollups is noteworthy. However, it remains uncertain whether this potential revenue would sufficiently incentivize rollups to switch to shared sequencers, especially sacrificing a portion of their fee income.

Source: EthCC, Vitalik Buterin

In 2022, Vitalik Buterin predicted at EthCC that the current protocol development is approaching its most radical phase of advancement. Since his presentation, we have witnessed blockchain infrastructure evolve at a pace unprecedented before. It might be premature to conclude which direction this will converge towards at this stage. What is certain is that the solutions introduced in this article will continuously influence each other, driving the expansion of the rollup ecosystem. In the future, the market and system development may involve a degree of competition and integration. But more importantly, mutual growth to expand the overall market will likely be the most effective approach.

A key premise in the advancement of rollup infrastructure is that the demand for user and block space must increase to a level incomparable to the current demand. Unfortunately, the growth of actual use cases lags behind the pace of infrastructure development. Few services demonstrate substantial potential or market penetration. Notably, those achieving notable user engagement often do so through token releases rather than by offering genuine customer value. The problem is, there aren't enough apps out there that make people want or need more block space. In the future, the kind of apps that become popular and really need more blockchain space will probably help decide how this technology will grow and change.

5. Conclusion

Rollups are now moving beyond their early stages and are increasingly being used in the real world. There's a growing trend of new services launching as a rollup, even while writing this piece. This has led to a growing interest among users and builders in what solutions will emerge as the foundation for deploying rollup systems. This article has examined the ongoing challenges for rollups and the various solutions proposed to address these challenges. Different approaches like rollup frameworks, shared sequencers, and Rollup as a Service (RaaS) offer unique features and benefits within the modular ecosystem.

While we've compared different solutions in this article, it's important to note that the future of modular blockchains may not converge on a single approach. For blockchain to become more widely adopted as open, decentralized and trustless networks, continuous experimentation and research are vital. Each solution has the potential to evolve and influence others, contributing to a more robust and efficient system. The evolution of most systems we use today has been shaped by a variety of factors and demands. The characteristics of a system alone don't always determine its future success, as it also depends on how it's used and the changing needs of its users. Therefore, while it's useful to compare different solutions, it’s important to avoid making premature judgments about the superiority of one over the others

Thanks to Kate for designing the graphics for this article.