I long had this idea about a multi-rollup design that aims to solve some of the problems rollups face today. For about a year and a half I though someone would build it and never really dug into it or considered the specifics of such a system.
It's been a while now and it seems that there isn't a design that solves the problems I will describe in this post. So, I will try to flesh out as much details as I can about the system in the hope that someone takes inspiration from this or even existing rollups borrow a few ideas.
One of the problems rollups face today is user experience. In many designs, rollups come as isolate ecosystems with very different traits. There are some ways to interoperate but with multiple heterogeneous systems wiring them up it's quite a challenge. Moreover, getting users to sign up for all these rollups is hard. They have to learn about each one of them individually, assess the relevant smart contracts, connect their wallet to a new RPC endpoint, bridge assets to the chain etc.
What if there was a rollup design that can provide a unified experience across the rollups? How would it look like?
I was asking this question to myself and came to five realizations:
With all this in mind, I came up with a design that involves a rollup hub and a variable number of child rollups. The rollup hub acts as both the registry and the load balancer of all the child rollups but does not do any smart contract processing. Smart contracts are processed in the child rollups instead.
In the following sections I'll go through a draft design that deals with 5 considerations I mentioned above.
The system has two main components: the rollup hub and the child rollups. The rollup hub is a rollup that contains a registry of all smart contracts for all child rollups and is the one that decides which rollups are responsible for which smart contracts. Moreover, the rollup hub contains another registry of all sequencers for the child rollups. Child chains are responsible for executing transactions for the smart contracts the rollup hub assigned them in the smart contract registry. The sequencer registry contains each sequencer RPC endpoint and DA address.
The sequencers registry acts as a mapping from the global smart contract addresses to the smart contract addresses. This is used to route RPC calls to the specific sequencer RPCs that correspond to the smart contract that is queried or updated.
Smart contract registry:
The smart contract registry acts as a mapping from the global smart contract addresses to the smart contract addresses.
The child chains have a state root as they normally do. This state route can be update by calling the smart contract directly but can also be updated when the rollup hub assigns the smart contract to a different rollup. In that case, the smart contract should be removed and should be added to the other smart contract.
Goal: To not have to connect to a new chain for every rollup and have transparent to the user cross-rollup transactions
The system uses the registry of the rollup sequencers from the rollup hub to find out the RPC endpoint of a sequencer that corresponds to a specific smart contract. The request is then submitted directly to that sequencer. Multiple transactions can be done by submitting requests to different rollups. Check the section below for more details.
Goal: To have balanced out fees across all rollups
Load balancing allows to balances the load across the rollups. When the system is jammed, new rollups can be spawned to handle the load. When there's no much usage rollups can be removed to save resources. Moreover the system could avoid fee spikes by moving smart contracts with high demand in transactions to rollups that more available capacity.
Note: Downloading the storage of some smart contracts might not be a trivial task. At first the state is not available on the DA layer and is quite large in size. This puts bounds on the minimum epoch time that would need a grace period to prepare that smart contract storage.
Goal: Having standby sequencers that are incentivize with partial rewards in the native token
Most rollups today are built on a single chain and have a single or very few sequencers to manage with the goal of maximizing rollup uptime. In contrast, in a multi rollup system, there multiple standalone child rollups that each have to be online to have liveness across the whole system.
Sequencers are naturally incentivized to join rollups to collect MEV but it's better to have proper rewards for these sequencers since they are more consistent and don't miss-aligned incentive as MEV does. These rewards should come from the rollup hub monetary policy.
Moreover, it's better to have a few sequncers on standby and ready to be enter. These sequencers can join when there's an increase in transaction demand and leave the system when there's not to save computational resources.
The standby sequencers will stay in a sequencer queue and get a small amount of rewards for there availability commitment. When they are swapped in in a rollup they will get the full amount. Rewards will come from a fee burning mechanism in the rollup hub.
Goal: Cross-rollup transactions should be instant and transparent to the user
A cross-rollup transaction between rollup A and rollup B needs to have 2 parts: 1) a transaction on rollup A and 2) a transaction on rollup B that only happens if the transaction on rollup A has succeeded and is final.
To get fast confirmations the user wallet can check whether the transaction is both submitted to the underlying DA layer and is valid using ZK proofs. If a transaction is both included and valid then the sequencers have to reach the same conclusion about that particular transaction.
Goal: Light nodes should be able to validate a smart contract across rollups 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 themselves. In this multi-rollup design, smart contracts are constantly reassigned to different child rollups and there should be a way to follow these specific smart contracts across. That's a mental shift from validating one or more chains to validating one or more smart contracts. Light nodes can utilize ZK proofs to cheaply validate all child rollups.
Block explorers are an integral part of a blockchain system. They facilitate balance queries for the native asset, smart contract queries and maintain transaction history from the first block to the current one. In this multi-rollup system, a block explorer should provide a unified view across all child rollups.
Right now this design is just an idea and I might never pursue it further, yet, I hope you found it interesting. If the design check out, I'm looking forward to rollup project utilize it and approach EIP-4844, Celestia or Avail capacity.
If you think there's a flaw somewhere or the design is problematic feel free to let me know.