The future of capacity expansion: multi-Rollup system design concept

Author: AndreasTzionis; Source: ethresear.ch; Compiler: Yvonne, MarsBit

For a long time, I have had the idea of solving some of the problems currently faced by Rollup through multi-Rollup (multi-Rollup) design. For about a year and a half I thought someone would build it, but never really delved into or thought about the details of such a system.

It's been a while now and there doesn't seem to be a single design that solves the problem I've described in this post, so I'm going to fill in the details of this system as best I can in the hope that someone can get some inspiration from it, or even from an existing Rollup Borrow some ideas.

introduce

One of the problems Rollup faces today is user experience. In many designs, Rollups are separate ecosystems with different characteristics. There are ways to interoperate, but connecting multiple heterogeneous systems is quite a challenge. Also, getting users to sign up for all these Rollups is difficult. They have to understand each Rollup individually, evaluate the relevant smart contracts, connect their wallets to new RPC endpoints, bridge assets onto the chain, etc.

What if there was a Rollup design that provided a unified experience for all Rollups? what will it look like?

I've been asking myself this question and have come up with the following five insights:

It should provide a unified RPC to query and call different smart contracts across Rollup. Smart contracts should have a unique address that is not dependent on the Rollup they belong to.

It should allow scaling up and down based on demand. More transactions should mean more Rollups to process them, and uneven load between Rollups should be balanced.

It should incentivize the sorters in different Rollups to stay online. The system should encourage other sorters to replace offline sorters.

It should support instant cross-chain transfers. Transactions should settle fast enough that cross-chain operations make sense.

It should maintain light client and block explorer functionality across multiple merges. Block explorers should provide a unified view of the blockchain, and lightweight clients should allow low-cost verification.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-24cc855280-dd1a6f-6d2ef1)

Taking all of this into consideration, I came up with a design consisting of a Rollup hub and a variable number of sub-Rollups. The Rollup hub is both the registration center and the load balancer of all sub-Rollups, but it does not do any smart contract processing. Smart contracts are handled in sub-Rollups.

In the next section, I'll walk you through a rough design explaining the 5 considerations I mentioned above.

Design Overview

The system has two main components: Rollup hub and sub-Rollup. The Rollup hub system has two main components: Rollup hub and sub-Rollup. A Rollup hub is a Rollup that contains all smart contract registries of all sub-Rollups and determines which Rollup is responsible for which smart contract. Additionally, the Rollup hub contains a registry of all sequencers for another child Rollup. Child chains are responsible for executing transactions for smart contracts assigned to them by the Rollup hub in the smart contract registry. The sorter registry contains two main components for each sorter system: the rollup hub and the child rollup. A Rollup hub is a Rollup that contains all smart contract registries of all sub-Rollups and determines which Rollup is responsible for which smart contract. Additionally, the Rollup hub contains a registry of all sequencers for another child Rollup. Child chains are responsible for executing transactions for smart contracts assigned to them by the Rollup hub in the smart contract registry. The sequencer registry contains each sequencer RPC endpoint and DA address.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-30f0cf6d9f-dd1a6f-6d2ef1)

Sequencers registry

The sequencer registry acts as a mapping of global smart contract addresses to smart contract addresses. This is used to route RPC calls to the specific sequencer RPC corresponding to the queried or updated smart contract.

Smart Contract Registry

The smart contract registry acts as a mapping from global smart contract addresses to smart contract addresses.

Rollup Chain

Child chains usually have a state root. This state route can be updated by calling the smart contract directly or when the Rollup hub assigns the smart contract to another Rollup. In this case, the smart contract should be deleted and replaced. It is added to other smart contracts.

Unified RPC

Goal: Not having to connect to a new chain for each rollup and making cross-rollup transactions transparent to users.

Unified RPC restores the user experience of a single chain in a multi-Rollup network, and users do not have to connect to different networks to use different Rollups.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-74756eed1e-dd1a6f-6d2ef1)

The system uses the registry of Rollup sequencers from the Rollup hub to find the RPC endpoint for the sequencer that corresponds to a specific smart contract. The request is then submitted directly to the sequencer. Multiple transactions can be completed by submitting requests to different Rollups. Check out the following sections for more details.

how to work

The Rollup hub maintains a registry of sequencers for all child chains.

When a user wants to submit a new transaction, the user wallet queries the smart contract registry to obtain the RollupID of the smart contract, and queries the sequencer registry to obtain the RPC endpoint of the sequencer in the same rollup.

The transaction is then submitted to the sequencer's RPC endpoint.

Load Balancing

Goal: Balance the cost of all Rollups

Load balancing allows load balancing in Rollup. When the system becomes clogged, new rollups can be generated to handle the load. When there is not much use, Rollup can be removed to save resources. Additionally, the system can avoid fee spikes by moving smart contracts with high demand in transactions to Rollups with more available capacity.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-632aa78015-dd1a6f-6d2ef1)

how to work

Every epoch, the Rollup hub evaluates the load of all Rollups in the system. Epochs should last a few hours (maybe 6 to 24 hours) to avoid large-scale smart contract reallocations.

The Rollup hub can decide which smart contracts to reallocate and when to generate or delete Rollups, either using governance or using the gas consumption history of different smart contracts to decide autonomously.

The Rollup hub checks if any Rollup has a transaction load that is above average (i.e. fees are high) or below average (i.e. fees are low).

If a rollup's load is higher than average, the rollup hub evaluates which smart contracts consume the most gas and reallocates them to a different rollup that can handle the extra load. The smart contract is then removed from its initial host Rollup state.

If the average load of all Rollups is higher than average, the Rollup hub will create a new Rollup and assign some smart contracts to the new Rollup. Similarly, if the average load of all Rollups is below the average, the Rollup hub will delete a Rollup and reassign its smart contracts to other Rollups.

Rollup chains should look at the Rollup hub every epoch, download the storage for any new smart contracts assigned to them, and delete any smart contracts that are no longer responsible for them.

Note: Downloading the storage for some smart contracts may not be a trivial matter. First, the state is not available at the DA layer and is quite large in size. This limits the minimum epoch time and requires a grace period to prepare smart contract storage.

Sorting Incentives

Goal: Use a portion of the rewards in the native token to incentivize backup sequencers.

Most rollups today are built on a single chain, managed by one or very few orderers, with the goal of maximizing rollup uptime. In contrast, in a multi-rollup system, there are multiple independent sub-rollups, each of which must be online to remain active in the overall system.

Sorters will naturally be incentivized to join Rollup to collect MEV, but it is better to provide appropriate rewards to these sorters as they are more consistent and do not misalign incentives like MEV. These rewards should come from the Rollup hub monetary policy.

In addition, it is good to have several orderers on standby and ready to enter, these orderers can join the system when transaction demand increases, and leave the system when there are no computing resources.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-02c28a977e-dd1a6f-6d2ef1)

The standby sequencer will remain in the sequencer queue and receive a small availability commitment reward. When they are exchanged in Rollup, they receive the full reward. Rewards will come from the Rollup hub’s fee burning mechanism.

how to use

Orderers can join the Rollup hub's orderer queue by submitting a financial bond (similar to the current Rollup system).

Sorters in the queue need to provide DA proofs that they have Rollup hub status and can read at any time to join the Rollup.

When they submit evidence, they will receive part of the reward, which is the system’s native tokens. This token is a handle on the Rollup hub.

If the Rollup hub decides a new Rollup is needed, they will be assigned and receive the full reward. This reward is determined by the total amount of fees consumed in the system.

Cross Rollup Transactions

Goal: Rollup transactions should be instant and transparent to users.

The cross-Rollup transaction between Rollup A and Rollup B needs to have 2 parts: 1) The transaction on Rollup A 2) The transaction on Rollup B, which will only happen when the transaction on Rollup A is successful and final.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6899964b00-dd1a6f-6d2ef1)

For quick confirmation, user wallets can check if the transaction was submitted to the underlying DA layer and prove it is valid using ZK. If the transaction is included and valid, then the sequencer must reach the same conclusion for that particular transaction.

Credit for the idea goes to Mustafa Al-Bassam and Sovereign Labs.

how to use

A user submits a transaction that includes three Rollups, say RollupA, B, and C.

Let's think about a specific example, Rollup A has a stablecoin smart contract, Rollup B has a DEX, and Rollup C has a lending protocol. In this example, the user wants to exchange his stablecoin for a different token and its Deposit loan agreement.

Users must first submit a Rollup A transaction to transfer stablecoins to the DEX on Rollup B.

They can then submit a Rollup B DEX transaction that exchanges the stablecoin for the desired token on Rollup B.

In turn, the token was supposed to be transferred to RollupC, so the user submitted a third transaction, which did exactly that.

Finally, the user submits the 4th and final transaction, depositing tokens into the lending protocol.

Light Node and Block Explorer

Goal: Light nodes should be able to verify smart contracts across Rollup, and block explorers should provide a unified view of the chain.

A blockchain system should allow anyone to run a node and verify the chain itself. In this multi-rollup design, where smart contracts are constantly being reassigned to different sub-rollups, there should be a way to track these specific smart contracts. This is a mind shift from validating one or more chains to validating one or more smart contracts. Light nodes can utilize ZK proofs to verify all sub-Rollups at low cost.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-69f308abb1-dd1a6f-6d2ef1)

How it works (light client)

Rollup nodes should support a validation mode, along the lines of the sorter mode.

The verification mode verifies the state of a single smart contract, unlike the sequencer mode, which submits transaction batches to the DA layer.

If a smart contract changes a subcluster, validators only need to update the subcluster they are listening on since they already owned the smart contract storage until the reallocation.

Smart contracts should be processed in one rollup at a time. Since they are restricted to a rollup, validating nodes with the same specifications should be able to track and verify them.

Light nodes can use ZK proofs to cheaply verify the state of the chain.

Block explorers are an integral part of the blockchain system. They facilitate balance queries for native assets, smart contract queries, and maintain transaction history from the first block to the current block. In this multi-rollup system, the block explorer should provide a unified view of all sub-rollups.

! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-217876ee66-dd1a6f-6d2ef1)

How it works (Block Explorer)

The block explorer should support querying the balance of the Rollup hub (for native assets) and the transaction history of all sub-Rollups.

Similar to a single rollup system, block explorers use indexes to achieve this. A multi-rollup system must index all rollups in order to provide query services for any smart contract in the system.

If the rollup hub decides to expand the number of sub-rollups, the block explorer should be ready to handle it. They should provide more sub-rollup capacity, or have a container orchestration system (such as Kubernetes) to automatically scale up sub-rollups.

They should use block numbers from the DA layer for consistency across all rollups.

in conclusion

The above design is just an idea at the moment and I may never implement it further, but I hope the idea interests you. If the design is approved, I expect it can be used in the Rollup project and approach the expansion capabilities of EIP-4844, Celestia or Avail.