Original Title: The math of when stage 1 and stage 2 make sense

Original Author: Vitalik Buterin

Original Translation: Wenser, Odaily Planet Daily

Editor's Note: The discussion about the three stages of Ethereum rollup security has always been a focus of the Ethereum ecosystem community. This not only concerns the operational stability of the Ethereum mainnet and L2 networks but also the actual development status of L2 networks. Recently, Ethereum community member Daniel Wang proposed the naming label #BattleTested for the L2 network Stage 2 on the X platform, believing that only when the current code and configuration have been live on the Ethereum mainnet for over 6 months and have consistently maintained a total locked value (TVL) of over $100 million, including at least $50 million of ETH and major stablecoins, can an L2 network receive this title. The title is dynamically evaluated to avoid "on-chain trickery." Ethereum co-founder Vitalik later provided a detailed response and perspective on this issue, as translated by Odaily Planet Daily below.

The 3 Major Stages of L2 Networks: From 0 to 1 and then to 2, Security Determined by Governance Share

The three stages of Ethereum rollup security can be determined based on when the security council can cover trustless (i.e., purely cryptographic or game-theoretical) components:

· Stage 0: The security council has full control. There may be a proof system running (Optimism or ZK mode), but the security council can override it through a simple majority vote mechanism. Therefore, the proof system is only "advisory" at this stage.

· Stage 1: The security council requires 75% (at least 6/8) approval to override the running system. There must be a quorum subset (e.g., ≥ 3) outside the main organization to block. Therefore, the difficulty of controlling the proof system is relatively high but not insurmountable.

· Stage 2: The security council can only take action in provably erroneous situations. For example, a provable error could be two redundant proof systems (e.g., OP and ZK) contradicting each other. In the presence of a provable error, it can only choose one of the proposed answers: it cannot arbitrarily respond to one mechanism.

We can use the following chart to represent the "voting share" that the Security Council holds at different stages:

Governance Voting Structure across Three Stages

An important question is: What is the optimal timing for an L2 network to transition from stage 0 to stage 1, and then further from stage 1 to stage 2?

The only valid reason for not immediately entering stage 2 is if you cannot fully trust the proof system—this is a understandable concern: the system is comprised of a lot of code, and if there are vulnerabilities in the code, an attacker could potentially steal all user assets. The more confident you are in the proof system (or conversely, the less confident you are in the Security Council), the more you would want to push the entire network ecosystem forward to the next stage.

In fact, we can quantify this point using a simplified mathematical model. First, let's list the assumptions:

· Each member of the Security Council has a 10% chance of "individual failure";

· We consider liveness failures (failure to sign transactions or unavailable keys) and safety failures (signing incorrect items or compromised keys) as equally likely events. In reality, we only assume a single "failure" category, where a "failed" Security Council member both signs incorrect items and fails to sign to progress the correct ones;

· In stage 0, the Security Council's threshold is 4/7, and in stage 1, it is 6/8;

· We assume the existence of a single unified proof system (as opposed to a 2/3 design, where the Security Council can break deadlocks when opinions diverge). Therefore, the presence of the Security Council is entirely irrelevant in stage 2.

Given these assumptions, considering the specific probability of proof system failure, we want to minimize the likelihood of an L2 network collapse.

We can use the binomial distribution to do this work:

· If each Security Council member has a 10% independent failure chance, then the probability of at least 4 out of 7 failing is ∑= 47( 7 )∗ 0.1 ∗ 0.97 −= 0.002728 Therefore, the stage 0 integration system has a fixed 0.2728% failure probability.

· Stage 1 integration can also fail if the proof system fails and the Security Council verification mechanism experiences ≥ 3 failures, preventing network computation coverage (probability ∑= 38( 8 )∗ 0.1 ∗ 0.98 −= 0.03809179 multiplied by the proof system failure rate), or if the Security Council has 6 or more failures, it can autonomously generate an incorrect computation answer (fixed probability of ∑= 68( 8 )∗ 0.1 ∗ 0.98 −= 0.00002341 );

· The probability of Phase 2 merge failure is consistent with the probability of a proof system failure.

Presented here in chart form:

L2 Network Proof System Failure Probability at Different Phases

As speculated above, as the quality of the proof system improves, the optimal phase shifts from Phase 0 to Phase 1, and then from Phase 1 to Phase 2. Using a Phase 0 quality proof system for Phase 2 network operation results in the worst outcome.

Now, please note that the assumptions in the above simplified model are not perfect:

· In reality, the members of the security committee are not entirely independent, and there may be "common-mode failures" among them: they may collude, or all be subject to the same coercion or hacking, and so on. The reason for requiring a legal number of members outside the major organization to prevent a subset from blocking is to avoid this, but it is still not perfect.

· The proof system itself may be composed of multiple independent systems (as I advocated in a previous blog). In this case, (i) the probability of the proof system crashing is very low, and (ii) even in Phase 2, the security committee is crucial as it is key to resolving disputes.

Both of these arguments suggest that Phases 1 and 2 are more attractive compared to what the chart indicates.

If you believe in math, then the existence of Phase 1 will almost never be shown to be rational: you should go straight to Phase 1. The main counterargument I have heard is: if a critical error occurs, it may be difficult to quickly get 6 out of 8 security committee members' signatures to fix it. But there is a simple solution: grant any security committee member the power to delay withdrawals by 1 to 2 weeks, giving others enough time to take action (remedy).

At the same time, however, jumping to Phase 2 too early is also a mistake, especially if the transition to Phase 2 comes at the cost of sacrificing work to strengthen the underlying proof system. Ideally, data providers like L2Beat should display proof system audits and maturity metrics (preferably the proof system implementation rather than a whole aggregate metric so that we can reuse), accompanied by the phase.

Original Article Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia