Mathematical models reveal the selection logic of the L2 phase: why might phase 1 be skipped?

Written by: Vitalik Buterin

Compiled by: Wenser, Odaily Planet Daily

Editor’s note: The discussion surrounding the three phases of Ethereum rollup security has always been a focal point for the Ethereum ecosystem community. This not only concerns the operational stability of the Ethereum mainnet and L2 networks but also relates to the real development status of L2 networks. Recently, Ethereum community member Daniel Wang proposed a naming label #BattleTested for the L2 network Stage 2 on the X platform. He believes that only L2 networks with current code and configurations that have been live on the Ethereum mainnet for over 6 months, maintaining a total value locked (TVL) of over 100 million dollars, with at least 50 million dollars in ETH and major stablecoins, can earn this title. This title is dynamically assessed to avoid the emergence of "on-chain phantoms." Ethereum co-founder Vitalik subsequently provided detailed answers and shared his views on the issue, which Odaily Planet Daily has compiled as follows.

The 3 stages of L2 network: from 0 to 1 to 2, security is determined by governance share.

The three phases of Ethereum rollup security can be determined by when the security council can cover the non-trust (i.e., purely cryptographic or game-theoretical) components:

• Stage 0: The Security Council has full control. There may be a running proof system (Optimism or ZK mode), but the Security Council can override it through a simple majority voting mechanism. Therefore, the proof system is only "advisory in nature."
• Stage 1: The Security Committee requires 75% (at least 6/8) approval to override the operating system. There must be a quorum to prevent a subset (e.g., ≥ 3) from being outside the main organization. Therefore, the difficulty of controlling the proof system is relatively high, but not insurmountable.
• Stage 2: The security committee can only take action in the case of a provable error. For example, a provable error could be a contradiction between two redundant proof systems (e.g., OP and ZK). If there is a provable error, it can only choose one of the proposed answers: it cannot arbitrarily respond to a certain mechanism.

We can use the chart below to represent the "voting shares" held by the security committee at different stages:

Three-stage governance voting structure

An important question is: What are the optimal timings for L2 networks to transition from stage 0 to stage 1, and from stage 1 to stage 2?

The only valid reason for not immediately entering Stage 2 is that you cannot fully trust the proof system — this is an understandable concern: the system consists of a large amount of code, and if there are vulnerabilities in the code, then attackers could steal all users' assets. The stronger your confidence in the proof system (or conversely, the weaker your confidence in the security committee), the more you want to push the entire network ecosystem to progress to the next stage.

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

• Each member of the security committee has a 10% chance of "single point of failure";
• We regard active failures (refusal to sign contracts or unavailability of keys) and security failures (signing incorrect matters or keys being hacked) as equally probable events. In fact, we only assume one category of "failure," where a member of the security council has both signed an incorrect matter and failed to sign the correct matter.
• In phase 0, the determination standard of the security committee is 4/7, and in phase 1 it is 6/8;
• We assume there exists a single holistic proof system (as opposed to the 2/3 design mechanism, where the security committee can break the deadlock when there is a disagreement between the two). Therefore, in phase 2, the existence of the security committee is completely irrelevant.

Under these assumptions, considering the specific probability of the proof system collapsing, we aim to minimize the possibility of L2 network failure.

We can use the binomial distribution to complete this task:

• If each member of the Security Council has a 10% chance of independent failure, then the probability of at least 4 failures out of 7 is ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728. Therefore, the integrated system at stage 0 has a fixed failure probability of 0.2728%.
• The integration of Stage 1 may also fail if the proof system fails and the security committee verification mechanism encounters ≥ 3 failures, making it impossible to perform network computation coverage (probability ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplied by the proof system failure rate), or if the security committee experiences 6 or more failures, it can forcibly generate an incorrect computation answer (fixed ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probability);
• The probability of failure in Phase 2 merging is consistent with the probability of failure in the proof system.

Presented here in chart form:

The probability of system failure in different stages of the L2 network

As deduced above, with the improvement in the quality of the proof system, the optimal stage shifts from stage 0 to stage 1, and then from stage 1 to stage 2. Using a proof system of stage 0 quality for the network operation of stage 2 yields the worst result.

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

• In reality, members of the security committee are not completely independent, and there may exist a "common mode failure" among them: they may collude with each other, or all be subject to the same coercion or hacking attacks, etc. The aim of requiring a quorum outside of the main organization to prevent subsets is to avoid this from happening, but it is still not perfect.
• The proof system itself may be composed of multiple independent systems (I advocated for this in my previous blog). In this case, (i) the probability of the proof system crashing is very low, and (ii) even at phase 2, the security committee is still important as it is key to resolving disputes.

Both arguments indicate that phases 1 and 2 are more attractive compared to what is shown in the chart.

If you believe in mathematics, then the existence of Stage 1 will almost never be proven to be reasonable: you should go directly into Stage 1. The main objection I've heard is that if a critical error occurs, it might be difficult to quickly obtain the signatures of 6 out of the 8 members of the Security Committee to fix it. However, there is a simple solution: grant any member of the Security Committee the authority to delay withdrawals by 1 to 2 weeks, giving the others enough time to take remedial action.

At the same time, however, jumping to phase 2 too early is also wrong, especially if the work of transitioning to phase 2 comes at the expense of strengthening the underlying proof system. Ideally, data providers like L2Beat should showcase proof system audits and maturity indicators (preferably indicators of the proof system implementation rather than the entire aggregation, so that we can reuse them), along with demonstrations of the phases.