# Milestones for rollups taking off training wheels

Source: https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571
Kiwi News: https://news.kiwistand.com/stories/Milestones-for-rollups-taking-off-training-wheels?index=0x64d91f9044cce293fae2413098f751ead390e19cdbf96422fd0efc6c47c6f1e67c08b021
Submitted by tim on 2023-08-13 UTC, 1 upvote, 0 comments

## Summary

The article proposes a three-stage milestone schema for rollups to categorize how heavily they rely on temporary "training wheels," meaning multisig controls that can force outcomes if the code has bugs. Stage 0 requires that all rollup transactions be posted on-chain, that an independently runnable full node exist, and that users can ensure withdrawals without operator cooperation, with a simple multisig allowed for posting state roots. Stage 1 requires a running fraud or validity proof system with practical authority over accepted state roots, and permits a security council override only if it is 6 of 8 or stricter with at least a quorum-blocking group outside the operating organization. Stage 2 requires that, if the code has no bugs, no group of actors can post a state root other than the code's output, with upgrades requiring a delay of at least 30 days.

## Article

Proposed milestones for rollups taking off training wheels

There are currently a large number of (optimistic and ZK) rollup projects, at various stages of development. One pattern that is common to almost all of them is the use of temporary training wheels: while a project’s tech is still immature, the project launches early anyway to allow the ecosystem to start forming, but instead of relying fully on its fraud proofs or ZK proofs, there is some kind of multisig that has the ability to force a particular outcome in case there are bugs in the code.

L2beat’s risk analysis page shows a large amount of stats about various rollups, including the status of their training wheels:

However, as of today this information is not well-standardized, making it difficult for users to understand what specific trust model a particular rollup is using. Rollup teams may even have the incentive to keep quiet about their present-day trust model, focusing the discussion instead on the fully-trustless tomorrow.

This post proposes a simple milestone-based schema to help us categorize rollups into three different stages, depending on how heavily they rely on their training wheels. This is intended to achieve a few goals:

Make it easier for users to identify the extent to which a particular rollup depends on “trust in a specific group of humans” vs “trust in code”

Help motivate rollup projects to improve on their trust models, reducing the risk that trust minimization gets deprioritized because it is “less visible” than eg. flashy UX improvements

Give the ecosystem some precise milestones to coordinate around and celebrate, letting us say when “The Surge” is half-complete or fully complete, paralleling “The Merge”

This schema is NOT intended to imply a moral judgement that movement to maximum trust in code as quickly as possible is the only correct course of action. Rollups absolutely should have a clear roadmap to taking off training wheels, but they should take training wheels off only when they are ready.

The Schema

Stage 0: full training wheels

Requirements:

The project should call itself a rollup.

All rollup transactions should go on-chain.

There should exist a “rollup full node”: an independently runnable software package that can read the L1 chain, extract and the rollup chain, and compute the current state of the rollup chain. If it disagrees with a rollup state root posted into the contract, it should give an alarm.

There should be machinery that allows users to either post rollup transactions or at least ensure a withdrawal of their assets with no cooperation from the operator. That is, the operator cannot freeze or steal users’ assets by censoring users; their only possible tool for doing so must be to post a false state root.

It’s okay if the on-chain mechanism for posting new state roots is simply a multisig, with no active fraud proof or validity proof whatsoever.

Stage 1: limited training wheels

Requirements:

There must be a running fraud proof or validity proof scheme, which has the practical authority to accept or reject which state roots get accepted by the rollup contract.

There can exist a multisig-based override mechanism (“security council”) that can override the fraud proof or validity proof system’s outputs and post state roots, to be used in case the proof system code is bugged. However:

The multisig must be 6 of 8 or stricter (that is, >= 8 participants AND >= 75% threshold)

At least a quorum-blocking group (that is, enough participants to prevent the multisig from acting) must be outside the organization that is running the rollup.

There can exist an upgrade mechanism, but if it has a lower threshold than the multisig, upgrades must have a mandatory activation delay of at least 7 days or the maximum length of the fraud proof game, whichever is longer. The goal of this rule is to ensure that the upgrade mechanism cannot be used to intervene in real-time disputes.

Stage 2: no training wheels

Requirements:

In the event that code does not have bugs, there must not be any group of actors that can, even unanimously, post a state root other than the output of the code

This somewhat awkward phrasing (“IF the code does not have bugs, THEN no one can override it”) is meant to permit use of security councils in ways that are clearly limited to adjudicating undeniable bugs, such as the following:

The rollup uses two or more independent implementations of its state transition function (eg. two distinct fraud provers, two distinct validity provers, or one of each), and the security council can adjudicate only if they disagree - which would only happen if there is a bug

If someone submits a transaction or series of transactions that contains two valid proofs for two distinct state roots after processing the same data (ie. “the prover disagrees with itself”), control temporarily turns over to the security council

If no valid proof is submitted for >= 7 days (ie. “the prover is stuck”), control temporarily turns over to the security council

Upgrades are allowed, but must have a delay of >= 30 days