Introducing Stages — a framework to evaluate rollups maturity

Dec 7, 2023: Check the requirements update here!

In the ever-evolving landscape of blockchain technology, rollups have emerged as a promising solution to scale Ethereum in a trust-minimized manner. However, the development of these systems often involves a phase of centralized control, commonly referred to as having “training wheels”, which allows for system updates and bug fixes in a controlled environment.

Though necessary in the early stages, these training wheels should eventually be removed for rollups to fully inherit the security properties of the base layer. To guide this transition, we introduce a new framework, inspired by Vitalik’s proposed milestones, that categorizes rollups into three distinct stages based on their reliance on these training wheels:

1. Stage 0 — Full Training Wheels: At this stage, the rollup is effectively run by the operators. Still, there is an source-available software that allows for the reconstruction of the state from the data posted on L1, used to compare state roots with the proposed ones.
2. Stage 1 — Limited Training Wheels: In this stage, the rollup transitions to being governed by smart contracts. However, a Security Council might remain in place to address potential bugs. This stage is characterized by the implementation of a fully functional proof system, decentralization of fraud proof submission, and provision for user exits without operator coordination. The Security Council, comprised of a diverse set of participants, provides a safety net, but its power also poses a potential risk.
3. Stage 2 — No Training Wheels: This is the final stage where the rollup becomes fully managed by smart contracts. At this point, the fraud proof system is permissionless, and users are given ample time to exit in the event of unwanted upgrades. The Security Council’s role is strictly confined to addressing soundness errors that can be adjudicated on-chain, and users are protected from governance attacks.

Background

The conversation began in November 2022 when Vitalik Buterin proposed an initial framework for rollup milestones on the Ethereum Magicians’ forum. This sparked a lengthy discussion, mainly centered around the notion that a simple ranking system might not adequately represent the varied and complex routes a project can take to achieve the shared goal of a fully decentralized, permissionless scaling solution ultimately secured by Ethereum.

Presenting comprehensive and nuanced information poses a challenge, and earlier this year at L2BEAT, we explored several different directions, including a simple three-stages rating, a letter rating with plus and minus signs to express finer details, a star system, and a numeric score system.

Our (quite obvious from hindsight) conclusion was that there isn’t any single rating system that would satisfy everyone involved. At the same time it became obvious that there’s a need to provide a well-defined system for rollup maturity assessment, as ‘stages’ started being used in the public debate without precise understanding of how they are being defined. We also realized that we did not have enough data to properly evaluate all of the rollups, especially as these systems were being updated at an increasing pace.

So, we have updated our risk assessment research for each rollup and enhanced our automatic monitoring system to ensure that every piece of information on our pages is current, and that we receive alerts if anything changes.

We also decided to stick to the simple three-stage framework as part of the more general risk assessment that we already provide. We have clarified the initial Vitalik’s definitions with some more precise boundaries. The final results is a framework that will serve to categorize the maturity level of a rollup in a straightforward manner, while also providing detailed technical information for a more nuanced evaluation.

The framework includes highly opinionated components, such as the minimum exit window, the Security Council thresholds, and fraud proof allowlist size. We believe it was necessary to select some starting points, but in the future, we may adjust them based on new scenarios and feedback from the community. We hope that this framework will become a basis of in-depth debate in the coming months.

The Framework

In the sections that follow, we delve into the specific requirements and conditions that characterize each stage, providing detailed criteria to guide the progression of rollups from Stage 0 to Stage 2.

Stage 0 requirements

Does the project call itself a rollup?
To be considered a rollup, the project must self-identify as such. This requirement is straightforward and helps distinguish rollups from other scaling solution, such as Optimistic Chains, Validiums or other types of bridges.

Are L2 state roots posted on L1?
Posting state roots on L1 is a key characteristic of rollups that allows for withdrawals. If a rollup does not post state roots on L1, it falls short of a fundamental component of a bridged rollup.

Does the project provide Data Availability (DA) on L1
Ensuring data availability on L1 is essential for the security and reliability of a rollup. This means that all data necessary to reconstruct the L2 state must be available on L1, enhancing the system’s transparency and auditability.

Is software capable of reconstructing the rollup’s state source available?
A rollup node software capable of reconstructing the L2 state from L1 data should be available, contributing significantly to transparency and trust. This allows anyone to review, audit, and run the software, enabling users and external observers to independently validate the proposed state roots against published data.

Stage 1 requirements

Does the project use a proper proof system?
The proof system is used to adjudicate whether the proposed state root is correct or not. In the case of a fraud proof system, it allows invalid proofs to be rejected. For zk rollups, the proof system is required to accept a proposed state root. If state diffs are used for data availability, the proof system must also ensure that all state changes are included in the diff.

Are there at least 5 external actors that can submit a fraud proof?
A fraud proof system requires at least one honest actor to verify the correctness of proposed state roots and potentially dispute them. For Stage 2 the proof system must be open to all participants, but for Stage 1 we allow an allowlist. The fraud proof system must allow a minimum of 5 external actors to perform this task.

Can the users exit without the operator’s coordination?
The system should be designed so that user withdrawals cannot be blocked by the rollup operators. The rollup must implement mechanisms that allow users to exit independently, ensuring they can always access and control their assets.

Do users have at least 7 days to exit in case of unwanted upgrades (Security Council and governance excluded)?
This requirement is designed to protect users in the event of significant changes to the system, such as upgrades or modifications that they do not agree with. A minimum exit period of 7 days provides users with sufficient time to withdraw their assets and exit the system if they choose. At this stage, a Security Council and a governance system are permitted to act more swiftly. Note that a 7-day upgrade delay alone might not be sufficient: if any delay to withdraw is present (for example, a delay to force transactions in case of censoring operators), it is subtracted from the exit window.

Is the Security Council properly set up?
The Security Council acts as a safeguard in the system, ready to step in in the event of bugs or issues with the proof system. It must function through a multisig setup consisting of at least 8 participants and require a 50% consensus threshold. Furthermore, at least half of the participants must be external to the organization running the rollup, with a minimum of two outsiders required for consensus. This setup ensures a diversity of viewpoints and minimizes the risk of any single party exerting undue influence. For the sake of transparency and accountability, the identities (or the pseudonyms) of the council participants should also be publicly disclosed.

Stage 2 requirements

Is the fraud proof system permissionless?
In this stage, the fraud proof system should be fully decentralized and open to everyone. This means that anyone, not just a set of allowlisted actors, should be able to submit fraud proofs. This is a key requirement to ensure that the system is not controlled by a limited set of entities and instead is subject to the collective scrutiny of the entire community.

Do users have at least 30 days to exit in case of unwanted upgrades?
Users should be provided with at least 30 days to exit the system in case of unwanted upgrades, including upgrades initiated by a DAO. This ample time frame allows users to react to significant changes in the system that they may not agree with and withdraw their assets if needed. One exception that we make is given the existence of a on chain bug detection system (e.g. two valid contradicting zk proofs) instant upgrades are allowed for detected bugs.

Is the Security Council restricted to act only due to errors detected on chain?
In the final stage of rollup development, the power of the Security Council should be highly limited. It should only be able to intervene in the case of adjudicable soundness errors, which are serious flaws in the system that could cause significant harm if not addressed. By restricting the council’s actions to these types of errors, the system becomes more decentralized and the trust placed in the Security Council is reduced. This moves the rollup further towards the ideal of trust minimization, where the code itself is the ultimate authority. An example of this feature is present in the Polygon zkEVM contracts, where the rollup goes in “Emergency Mode” if two different valid proofs can be submitted using the same batches.

Going forward

We hope our framework will serve as a reference point for discussing the maturity of rollups and act as an incentive for projects to focus on specific security measures in their roadmaps.

While we understand that some of the decisions we made regarding the criteria may be contentious, we believe that ultimately it will provide the community with clearer guidance on how to assess existing systems in terms of their goals of being “secured by Ethereum”.

We now wish to initiate a series of discussions around certain aspects of this framework. Our aim is for every project involved to express their stance on improving their stage assessment, enabling us all to have a more structured debate around specific risk factors.