# Microservice Thesis

## Evolution of Modular approach: Build App-specific rollups ecosystem

### The Rise of Layer2 and the Advent of App-specific Rollups

The market for Layer2 solutions utilizing Ethereum's rollup approach has been experiencing rapid growth recently. As of February 2024, there are approximately 80 Layer2 networks, and the total value locked (TVL) has grown 100% in just six months, reaching $27.15 billion. There are even Layer2 networks that have surpassed Ethereum in the number of transactions over a 30-day period, quickly becoming the choice of users. These Layer2 networks are accelerating the development of ecosystems for App-specific rollups, which can maximize the scalability provided by rollups while ensuring lower transaction fees and sovereignty for the Dapps deployed on their networks or using their tech stack. (The adoption of App-specific rollups is being actively discussed, especially in the gaming sector.)


There are three main reasons why rollups, as opposed to smart contracts, are becoming more prevalent in Dapp development. First, unlike smart contracts which are limited by the characteristics of the underlying network, Rollups guarantee scalability, flexibility, and sovereignty to Dapp projects. They inherit security from Ethereum while allowing for various attempts to improve scalability and usability without restrictions. Notably, they can offer an enhanced user experience through fast pre-confirmations compared to Ethereum's 12-second confirmation time. Second, Rollup frameworks like OP Stack, Polygon CDK, Zk Stack, and Madara have become open-source and technically stable. They have been standardized across Layer2, making it easier for anyone to build rollups. Third, Rollup as a Service (RaaS) providers are becoming more active. Providers like Altlayer and Caldera are facilitating the construction of rollups with one-click and no-code deployment options using various rollup frameworks. This maturity in the development environment is accelerating the market for App-specific rollups based on rollups.


### The Importance of Economic Sustainability

However, constructing a rollup and operating one are vastly different stories. Unlike smart contracts, operating a rollup requires sequencers to maintain their own network. These sequencers play a role similar to Ethereum's validators, receiving transactions from users, creating blocks, executing them, and then posting the final state to Ethereum. (Since the final state posted on Ethereum is verified, it can be said that rollups inherit Ethereum's security through this process.) Operating a sequencer involves deploying actual computing resources to run a node, necessitating appropriate compensation. The rewards must outweigh the operational costs to motivate the continuous operation of sequencer nodes.

Currently, most Layer2s operate with a centralized sequencer. The operational costs include the computing resources required for calculating the final state and the expenses of posting this final state to Ethereum. The rewards come from the transaction fees paid by the users. According to recent reports, the revenue of Layer2s reaches millions of dollars monthly. This suggests that the transaction fees collected from users significantly exceed the operation costs. However, I believe such profits are temporary and not sustainable. The reason is the inevitable competition in transaction fees among various upcoming Layer2 networks. Users migrate to Layer2 for lower transaction fees and faster confirmation times compared to Ethereum. Therefore, they will easily switch rollup networks in search of cheaper transaction fees, leading to potential user churn for networks that lose out in this competition. (For instance, zkSync has been redistributing the excess transaction fees back to users to reduce the perceived transaction fees.) So Layer2s cannot keep their transaction fee as high as they want for their profit to retain their users.

This concern applies equally to networks based on App-specific rollups, indicating that rollups need to find a solution for usability and economic sustainability that prevents user departure while continuously operating sequencers.

### Various Modules are Necessary for Rollup Operation

The structure of rollups in modular approach can currently be divided into three main layers : Execution, Data Availability (DA), and Settlement.

- The Execution Layer aggregates user transactions into blocks and computes the state transitions of the rollup.
- The DA Layer is used to post data proving the integrity of the final state and computations.
- The Settlement Layer verifies this data to grant finality to the final state.

To sustain the continuous operation of rollup sequencer nodes, it's essential to either increase revenues beyond user transaction fees or reduce the costs associated with computations. To achieve these goals, specific modules are needed: Builder and Prover. Maximal Extractable Value (MEV) can provide an alternative source of revenue for sequencers, with the Builder module being specialized for extracting MEV. Particularly, by extracting benign MEV, such as arbitrage or backrunning, rather than MEV that could harm users like frontrunning or sandwich attacks, additional revenue can be generated. Sequencers can allocate a portion of a block for a bundle that includes the Builder’s benign MEV and sell this space through an auction to the Builder who generates the highest revenue. The Prover module, on the other hand, focuses on reducing operational costs rather than generating revenue. Especially for validity rollups, a zk (zero-knowledge) proof is generated to prove the integrity of the final state and computations for state transsition, which the settlement layer then verifies to grant finality to the final state. However, generating this zk proof is very costly and time-consuming. The Prover is a module that optimizes this computation to generate zk proofs in a cost-efficient manner. The sequencer solicits estimates for the generation of zk proof from various Provers, receiving information on both costs and time requirements. By conducting an auction to select the Prover that best meets the predefined criteria of the rollup, cost reduction is achieved through competition. This process not only ensures that the sequencer can secure the generation of zk proof at the most efficient price but also fosters a competitive environment that encourages Provers to optimize their services in terms of cost and speed.


In addition to reducing operational costs, it's crucial to offer a better user experience (UX) to prevent users from leaving. As mentioned earlier, a significant reason users opt for Layer2 solutions is the diminished UX due to Ethereum's 12-second confirmation time. Although this design was intended to ensure strong security, rollups, which are granted flexibility, can offer fast pre-confirmations through a consensus among their own sequencers, albeit with weaker security. To achieve this, the execution and sequencing are separated, with each function being handled by its distinct module; Sequencer and Executor. The Sequencer's role is to order user transactions and build blocks without executing them. Once block building is complete, the Sequencer can provide users with pre-confirmation. Since there is no overhead from transaction execution simulation during block building, it enables the issuance of fast pre-confirmations. The Executor, akin to a full node, maintains the latest state and is responsible for simulating execution of transactions.

An intriguing aspect is that by separately delineating Sequencer and Execution modules, additional revenue streams can be generated, specifically through cross-rollup transaction fees and cross-rollup MEV. To support cross-rollup functionality, a bundle must include transactions that need to be executed across different rollups, ensuring the atomicity of the bundle execution—that is, all transactions within the bundle either succeed together, or if one fails, none are executed. Since Sequencers do not have execution overhead, a single Sequencer can simultaneously manage block building for multiple rollups. This means that a Sequencer can guarantee the atomic "inclusion" of transactions for each rollup in a cross-rollup bundle. However, since transaction inclusion does not ensure the success of transaction execution, the Sequencer module alone cannot fulfill the atomicity of cross-rollup functionality. To guarantee atomic "execution", the Sequencer can simulate the execution of transactions within the cross-rollup bundle through communication with the Executor during block building. The Executor provides validity of the simulation results to the Sequencer, who can then proceed with block building for the connected rollups accordingly. (Communication with the Executor only occurs in the presence of cross-rollup transactions, thereby minimizing the overhead associated with execution for the Sequencer.) This entire process occurs without interaction with the underlying network (like Ethereum), ensuring "synchronous" composability. (In contrast, using traditional bridges would provide "asynchronous" composability through the underlying network, making efficient support for cross-rollup transactions practically challenging.)


### From Modular to Microservice: Orchestration is Key

Until now, we have explored why additional modules such as Builder, Prover, Sequencer, and Executor are necessary for the economic sustainability of rollup operation. However, the issue is that the more modules and communications there are, the more complex the system becomes. To solve this complexity and ultimately achieve scalability, an evolution from the traditional Modular architecture is necessary. The solution can be found in software engineering principles, specifically in the Microservice architecture.


The Microservice architecture distinguishes itself from Modular architecture by featuring a greater number of micro-modules, where each module demonstrates strong cohesion and weak coupling. This means that while each module maintains its independence, they can communicate efficiently when necessary for specific functionalities, allowing them to operate seamlessly as a single system. A notable example is in cloud computing, where Microservice architecture has been applied to enhance service scalability. For instance, Amazon AWS employs modularization for various functions such as databases, API gateways, and load balancing, allowing these components to be combined as needed to optimize efficiency. However, the increased complexity due to the multitude of modules is a recognized disadvantage. To address this, an orchestration module capable of coordinating these modules is essential. This involves managing the communication and processing flow of each module to ensure the system's safety (consistency) without issues.


Let's consider applying the Microservice architecture to the structure of rollups for efficient operation. Essential modules such as the DA Layer, Settlement Layer, along with Sequencer, Executor, Builder, and Prover modules, are needed. These modules must work organically together from the moment a user's transaction enters the Rollup until finality is granted by Ethereum.

- User transactions are aggregated by the Sequencer into a single block.
- Spaces within this block are pre-allocated for Builder modules for benign MEV transactions, which are then sold via auction.
- Based on this completed block, the Executor applies the transactions to the current latest state to compute a new latest state (State transition).
- To verify the integrity of the new latest state and computation, the Prover generates zkp (It can be done via auction among multiple provers to optimize cost.)
- The block, the latest state, and the zk proof are stored in the DA Layer and verified in the Settlement Layer, granting finality to the rollup's latest state.

This approach, inspired by the principles of Microservice architecture, ensures that each component or module operates with a high degree of independence while maintaining efficient communication for the collective goal. The orchestration of these modules, crucial for managing their interactions and ensuring system coherence and safety, embodies the dynamic and scalable nature of Microservices in the context of rollups. This modular yet integrated system design can lead to more scalable, flexible, and efficient rollup operations, addressing both the technical challenges of blockchain scalability and the economic sustainability of rollup-based networks.


I argue that within a Microservice architecture, the Sequencer should take on the orchestration role. That is, the Sequencer, as the central node, should coordinate the entire process from block creation, revenue generation, block verification, to necessary proof computation and verification. The Sequencer manages auctions among various Builders for maximum MEV profit and can also conduct auctions among Provers to reduce costs associated with zk proof generation. (That is, selecting the Prover who can deliver the required zk proof within the desired timeframe at the lowest cost in real-time.) Furthermore, the Sequencer must sequentially manage communication with Executors of various rollups to support cross-rollup transactions. Lastly, to ensure finality, the Sequencer could optimize costs by considering the expenses of posting to the DA and Settlement Layers, potentially employing additional zk proof aggregation of multiple rollups’ proof or transaction fee estimation. The safety (consistency) of processing a single block can be ensured when one module orchestrates, and the Sequencer is deemed optimally positioned for this role.

### Trustless Orchestration via Radius’s Shared sequencing Layer

In a Microservice architecture, the orchestration module is centralized. If this module stops, the entire system's processing halts, and the centralized control by the orchestration module also raises the potential for manipulation. Therefore, it is necessary to devise ways to minimize the side effects caused by such centralization. One approach to mitigate centralization issues is to have multiple Sequencers responsible for orchestration, with block building proceeding through consensus among them. However, since the adoption of rollups is primarily for scalability, consensus among multiple Sequencers could introduce overhead into block building.

This presents a significant challenge: finding a balance between reducing the risks of centralization and maintaining the efficiency and scalability that rollups are meant to provide. Potential solutions could include implementing fault tolerance mechanisms to ensure the system can continue operating even if the central orchestration module fails, or exploring advanced consensus algorithms that can provide the necessary coordination among Sequencers without significant overhead.

Radius has introduced encrypted mempool, leader-based sequencing liveness, and a slashing mechanism to solve issues arising from the centralization of Sequencers and to facilitate trustless orchestration:

- **Encrypted mempool**: The core content of user transactions, Builder's auction bidding, and Prover's bidding processed by the Sequencer are all encrypted, preventing the Sequencer from manipulating them. This encryption ensures that harmful MEV cannot be extracted from user transactions, offering censorship resistance. Furthermore, the bidding process for Builders and Provers remains confidential until the auction is completed, preventing any unfair intervention in the decision-making process. This effectively eliminates the side effects of centralization. We use delay (timelock puzzle) encryption rather than threshold encryption to minimize trust assumption and dependency on 3rd party for decryption. The only thing that a Sequencer need to do in order to find decryption key is to solve timelock puzzle that a user generate when submitting a encrypted transaction.

- **Leader-based sequencing liveness**: Despite the centralization of Sequencers, the encrypted mempool ensures that there is no room for manipulation, allowing a single leader to proceed with block building. This method is significantly faster than consensus-based approaches. However, to address the single point of failure concern with a single sequencer, Radius utilizes a Sequencer pool consisting of multiple Sequencers. At each Epoch, one Sequencer from the pool is randomly selected as the leader to oversee block building. Backup sequencers are also designated to sync continuously with the leader's decisions and to step in as the new leader if the current one crashes, ensuring continuous liveness.

- **Slashing mechanism**: The orchestration of communication between various modules by a single Sequencer follows a protocol defined by agreements among modules, such as block building cycles, auction decision rules, and DA posting intervals, which can be customized for each Rollup network. However, a mechanism is needed to enforce the protocol, and Radius uses slashing to ensure smooth orchestration by Sequencers. Entities that wish to become Sequencers can join the Sequencer pool through staking and receive rewards for fulfilling their role as Leader. If they fail to adhere to the given protocol, they face slashing of their stake. For instance, when a user submits an encrypted transaction, the Sequencer provides an order commitment to the user for pre-confirmation purposes. This order commitment is essentially a promise from the Sequencer to place the user's transaction at a specific position in the next block. Once the next block is posted to the DA Layer, the user can verify whether this commitment has been honored. If the commitment is broken (i.e., the transaction is not in the promised position), the user can make a claim. If the claim is successful, the Sequencer faces slashing, which serves as an incentive for the Sequencer to adhere to the pre-confirmation commitments. This mechanism ensures accountability and trust in the sequencing process, enhancing the reliability and security of the rollup's operation.


### Closing remark

To ensure the operational sustainability of rollups, the importance of economic sustainability has been emphasized, along with the adoption of Microservice architecture as an evolved form of Modular architecture and the role of a shared sequencing layer. New modules such as Sequencer, Builder, and Prover have been added to enhance the system's safety, with the Sequencer responsible for orchestrating interactions between these modules. Radius is developing a shared sequencing layer utilizing an Encrypted mempool, Leader-based sequencing liveness, and a slashing mechanism to address centralization issues in orchestration. Collaborations are underway with various rollup frameworks and rollup as a service providers to support integration with Radius's shared sequencing layer, enabling dapp projects to easily choose Radius's layer during the rollup development phase. This initiative is expected to contribute significantly to the activation of the App-specific rollup market, fostering a more scalable, secure, and user-friendly blockchain ecosystem.