It’s well agreed by now that rollups are the best way to move transaction execution out of Ethereum and therefore help scale the base chain. Moreover, with the release of different rollups SDKs such as OP Stack, Arbirum Orbit, Polygon CDK, and ZKSync’s ZK Stack, among others, it has now become easier than ever to launch application-tailored instances of a general-purpose smart contract rollup. These SDKs have made deployment of a new rollup as simple as deploying a smart contract. Additionally, with several rollups-as-a-service (RaaS) providers such as AltLayer, Conduit, and others, dApp developers do not even need to host any of the node infrastructure themselves and can have a RaaS provider run and manage rollups on their behalf making it possible to launch a fully operational rollup within minutes.
However, in a world of thousands of rollups, any deviation from the ideal design and implementation of a rollup gets amplified at scale via rollup SDKs. This post aims to highlight and address some of the key issues inherent to the world of thousands of app-specific rollups. We first discuss some of the core issues of decentralization, security, interoperability, user and dev experience that affect application-tailored rollups and then present a new rollup design called restaked rollups that aim to address them by leveraging EigenLayer’s restaking mechanism.
Restaked rollups are a set of three vertically integrated Actively Validated Services aka AVSes created on-demand for a given rollup. These AVSes in conjunction offer three key services for app rollups namely decentralized sequencing, verification of rollup’s state correctness, and faster finality which in turn helps with decentralization of rollups, better security, and interoperability across rollups while leveraging Ethereum’s trust network via restaking. Restaked rollups are designed with three modular components called:
- VITAL (AVS for decentralized verification of rollup’s state)
- MACH (AVS for fast finality)
- SQUAD (AVS for decentralized sequencing)
But, before we go further into restaked rollup, let’s dive into the issues that they aim to address in the context of application-specific rollups.
Issue 1: Verification
Optimistic rollups are secure under the assumption that there is at least one honest party that checks that the state committed by the rollup operators on Ethereum indeed corresponds to the correct execution of the state transition function on a set of transactions and the previously validated state.
Most app-specific rollups however may not have an ecosystem as mature as that of popular general-purpose rollups and as a result there may not be enough ecosystem participants with implicit incentive to act to watch the network.
Moreover, there is an emergent category of using an optimistic pattern in L1 Ethereum smart contracts — where someone commits to the output of the computation — and then can be fraud proven. Another example would be ephemeral rollups introduced by AltLayer, where rollup sequencers commit the state of the rollup to Ethereum at the time of settlement where the state represents the result of an off-chain computation on a rollup for a certain application such as a Dark Forest. With these on-demand systems, having a decentralized network of verifiers that can detect and challenge a rollup’s state becomes extremely important.
Issue 2: Slow Finality
Ethereum is the most decentralized network with almost 1M validators. It’s also the network with the most liquidity so it is not surprising that Ethereum is the settlement layer of choice for most rollups today. However, Ethereum as a network is not the fastest of all to finalize and settle transactions as it takes about 13 minutes for a transaction to be finalized.
Given the time it takes for a transaction to be finalized, app-specific rollups that are designed to serve latency-sensitive applications such as games and social apps often end up relying on the promise provided by the sequencer that at some point in the future, it will post transactions on-chain.
This could be acceptable in scenarios where the rollup sequencer is operated by a trusted party, but, the sequencer’s promise is certainly not worth a dime when it is operated by an anonymous developer with no prior reputation. Moreover, as these centralized sequencers have no economic stake, the soft finality guarantee offered by them has no economic backing.
Moreover, as the finality guarantees provided by the sequencer are not strong, the receipt generated by the sequencer is not enough for interoperability. For example, for a burn on rollup A and mint on rollup B style cross-rollup message, rollup B needs to have strong guarantees that the sequencer for rollup A has indeed burnt a certain number of tokens on the rollup A.
Issue 3: Centralized Sequencing
The first and primary issue with rollups is the centralization of the sequencer.
Most rollups today operate with centralized sequencers operated by the entity that developed the protocol. Even though it is not ideal to have a single sequencer operate a rollup, having a centralized sequencer is somewhat acceptable for a well-established general-purpose rollup as there is some trust in the entity running the sequencer to not engage in activities that would undermine its reputation. This off-protocol trust, however, cannot be extended to the long-tail of app-specific rollups potentially operated by anonymous developers with no prior reputation.
Another issue related to centralized sequencing is related to RaaS providers. Although RaaS providers offer an immensely useful service and can help save substantial financial and manpower resources for teams planning to launch a rollup. Their business model however heavily relies on the existence of centralized sequencing and execution. Most if not all RaaS providers charge a portion of the sequencing revenue and as a result, for business viability reasons, they are encouraged to lock their clients for as long as possible. Vendor locking comes with platform risks where a popular RaaS provider may unilaterally decide to dictate the fee model or extract arbitrary MEV to maximize its profits.
Moreover, the centralized sequencer/executor model in which most RaaS providers operate today is not ideal as they present a closed environment which in principle is against the ethos of openness, transparent, and decentralized web3.
Restaked Rollups Overview
Without a common and credibly neutral network to facilitate these services, many of these app-specific rollups will most likely end up creating their own siloed and rent-seeking ecosystems with very little flexibility and control over the end-user experience. Restaked rollups aim to change this.
Restaked rollups are designed with the following key desiderata:
- Modularity in the sense that they can work with any rollup stack, any alternative DA layer like EigenDA and any settlement layer, and that its components can be used independently
- Crypto-economic security to handle any malicious network participants
- Support both ZK as well as optimistic rollups
- Generic enough to support different proof systems and runtimes
The overall system architecture is as follows: We assume three system participants: a) user with ET, b) a developer who wishes to commission a rollup, c) AVS operator
A user first stakes her ETH and then obtains an LST which she then restakes via EigenLayer. A developer who wishes to have a restaked rollup would then set up the AVS contracts to allow AVS operators to register for SQUAD (for sequencing), VITAL (for verification), and MACH for fast finality. Once these AVSes are set up and the operators are registered, they can start operating the rollup.
In the following sections, we explain how each component of the AVS works.
Verifier AVS aka VITAL
VITAL acts as an enshrined verification layer for rollups. It consists of a network of AVS-registered operators that verify all new states proposed across by SQUAD operators. It operators detect invalid state roots and can challenge SQUAD operators in a bisection protocol.
VITAL can also operate with optimistic ZK proofs whereby VITAL operators demand SQUAD operators to create a ZK proof for a disputed state root instead of engaging in a bisection protocol. Another operation mode would be to verify intermediate proofs that do not need to go to an L1. VITAL is crucial as the last AVS MACH leverages it to provide a fast finality layer.
Fast Finality AVS aka MACH
To address the slow finality of rollups, we present MACH: a fast finality layer for Ethereum rollups with the following key desiderata:
- Fast confirmation for rollup transactions
- Crypto-economic security so as to handle any malicious network participants
- Support both ZK as well as optimistic rollups
- Generic enough to support different proof systems and runtimes
In order to guarantee finality, MACH as a network needs to verify the validity of a rollup state to ensure that the rollup operators have followed the state transition function correctly. To this end, MACH supports three state validity modes.
Pessimistic Mode
In the pessimistic mode, each transaction is considered by default invalid, and hence needs to be replayed. As a result, the rollup operator feeds transaction data directly to the MACH network which in turn re-executes the transaction and reaches consensus on the validity of the proposed state by the rollup operator.
While this operational mode is the simplest of all, one of its major downsides is that it is not very efficient as the MACH practically operates as a network of full nodes for the rollup. And this results in beefy node requirements.
A future work is to build stateless clients that require a smaller state footprint to operate a node for the rollup.
Optimistic Mode
In this mode, the rollup operator asserts a state claim on MACH, stating that the execution of a specific block of transactions leads to a particular state commitment. Any node in the MACH network can then challenge the claim and prove that the new state is not valid by engaging with the rollup operator in a bisection protocol.
Note that the bisection protocol is triggered only when a challenger believes the state commitment is not valid. One could also replace the bisection protocol by on-demand ZK proofs, where the ZK proof is only generated if there is a challenge.
This setup assumes the existence of at least one honest node in the MACH network and network nodes are mostly in observation mode.
Validity Proof Mode
In this mode, the MACH network acts as a decentralised verifier network for validity proofs. The rollup operator such as a sequencer will commit to a newly set of transactions, the resulting state, together with the validity proof on MACH. The MACH network will then verify and reach consensus on the validity of the proof.
Despite the explicit usage of validity proofs, this mode can also work well with optimistic rollups. With optimistic rollups, any designated prover with the right incentive (outside of MACH), can generate a proof of validity and submit it to the MACH network which in turn verifies and reaches consensus on the validity of the proof.
Note that for ZK rollups, the prover can generate and submit proofs more frequently on MACH than it does on Ethereum and it is important they do so for faster finality. Moreover, this does not need to happen at the expense of more proving work: Instead of waiting to create a single batch proof, the prover can create proofs in real time and send it to MACH and use recursion to aggregate them into a batch proof later that can go to Ethereum. As long as the incremental proofs are distributed right away to MACH, the transactions will experience fast finality.
Implementation
We have implemented MACH as an AVS for an optimistic rollup implementation in Rust with fault proof over WASM. The rollup runs Sputnik VM (a Rust implementation of EVM) as the execution engine. The rollup client compiles Sputnik VM (in Rust) to WASM instructions and then runs bisection protocol over WASM.
In this section, we present our implementation of the optimistic mode with fault proofs via bisection protocol.
Each MACH node acts as an AVS operator that rigorously verifies the rollup state and proactively challenges any discrepancies observed during the designated challenge window. The challenger node in the MACH network follows the following steps:
- Restakes via EigenLayer
- Registers as an AltLayer AVS operator on EigenLayer and opts into slashing
- Once registered, the node can challenge any rollup state during the challenge period
- If the challenger wishes to dispute any rollup state, it can create a challenge request on rollup contracts on MACH
- Once the challenge is created, the bisection protocol between the challenger and the rollup operator will begin. Upon finding the disputed instruction, it will be executed on MACH and the challenge ends
Note that the challenger gets frozen (and is subjected to slashing) on EigenLayer if it fails the challenge.
Here is a quick demo of how this is implemented end to end.
https://drive.google.com/file/d/1c_Oo6gJiXHNULmqXxEBL64Jy3IjP7QXj/view?usp=sharing
We have also implemented on-demand ZK proofs to replace bisection protocol. Details can be found in this joint work with the RISC Zero team.
Decentralized Sequencing AVS aka SQUAD
SQUAD presents a rollup-dedicated decentralized sequencer network. Simply put, SQUAD is a network of nodes open for anyone to join after the registration at the AVS.
To become a validator for the SQUAD, a node has to stake a certain minimum number of LSTs. This provides the economic guarantee for the security of the rollup and can be potentially slashed.
Operators can bring in the minimum required LST stake themselves or implement a delegated staking mechanism allowing LST holders to stake with the operator. Staking on the SQUAD is implemented natively at AVS contract.
Conclusion
Restaked rollups are new design and implementation of rollups that provide decentralized sequencing, verification, and fast finality via three vertically integrated AVSes. These AVSes can work with any rollup stack and potentially any DA layer of choice and can be extremely useful to build trust in the long-tail of dApp rollups.
