Vitalik's new article: A Brief Discussion on the Mathematical Principles of Reasonable Division of L2 Stages

Written by: Vitalik Buterin

Compiled by: Wenser, Odaily Planet Daily

Editor's note: For a long time, the discussion on the three phases of Ethereum rollup security has been the focus of the Ethereum ecological community, which is not only related to the operational stability of the Ethereum mainnet and L2 network, but also related to the real development of the L2 network. Recently, Daniel Wang, a member of the Ethereum community, proposed the naming label #BattleTested for the Stage 2 phase of the L2 network on the X platform, arguing that only L2 networks with the current code and configuration that have been online on the Ethereum mainnet for more than 6 months and have maintained a total lock-up value (TVL) of more than $100 million and at least $50 million in ETH and major stablecoins can obtain this title, and the title is dynamically evaluated to avoid "on-chain ghosts". 」。 Ethereum co-founder Vitalik then gave a detailed answer to this question and shared his views, compiled by Odaily Planet Daily below.

The 3 main stages of L2 networks: from 0 to 1 to 2, with security determined by governance shares.

The three stages of Ethereum rollup security can be determined by when the security committee can override the trustless (i.e., purely cryptographic or game-theoretic) 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 overturn it through a simple majority vote mechanism. Therefore, the proof system is only of an "advisory nature."

Stage 1: The Security Committee requires 75% (at least 6/8) approval to override the operating system. A quorum must be present to prevent a subset (e.g., ≥ 3) from operating outside the main organization. Therefore, the difficulty of controlling the proof system is relatively high, but not insurmountable.

Phase 2: The Security Committee can only take action in the event of a provable error. For instance, a provable error may occur if two redundant proof systems (such as OP and ZK) contradict each other. If there is a provable error, it can only choose one of the proposed answers: it cannot arbitrarily respond to a specific 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 the L2 network 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, an attacker 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 evolve 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 consider active failures (refusal to sign contracts or key unavailability) and security failures (signing incorrect matters or keys being hacked) as equally probable events. In fact, we only assume one category of "failure," in which the members of the security council have both signed the incorrect matters and failed to sign the correct matters for advancement.

In stage 0, the judgment criteria of the security committee is 4/7, and in stage 1 it is 6/8;

We assume the existence of a single unified proof system (in contrast to the 2/3 design mechanism, where the security committee can break the deadlock when the opinions of both sides conflict). Therefore, in phase 2, the existence of the security committee is completely irrelevant.

Under these assumptions, taking into account the specific probability of the proof system crashing, we want to minimize the possibility of L2 network failure.

We can use the binomial distribution to accomplish this task:

If each member of the Security Council has a 10% independent failure chance, 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 experiences ≥ 3 failures, making it impossible to conduct 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 result (fixed ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probability);

The probability of failure in Stage 2 merging is consistent with the probability of failure in the proof system.

Presented in chart form here:

The failure probability of the proof system at different stages of the L2 network.

As inferred from the above results, with the improvement of the quality of the proof system, the optimal stage shifts from stage 0 to stage 1, and then from stage 1 to stage 2. Running the network at stage 2 using a proof system of stage 0 quality yields the worst results.

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

In reality, members of the security committee are not completely independent, and there may be "common mode failures" among them: they might collude or all be subjected to the same coercion or hacking attacks, etc. The goal of requiring a quorum outside of the main organization to prevent subsets is to avoid this occurrence, 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 in phase 2, the security committee is important, as it is key to resolving disputes.

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

If you believe in mathematics, then the existence of phase 1 will almost never be proven to be reasonable: you should go directly into phase 1. The main objection I hear is that if a critical error occurs, it may be difficult to quickly obtain the signatures of 6 out of 8 security committee members to fix it. However, there is a simple solution: grant any security committee member 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 stage 2 too early is also a mistake, especially if the work to transition to stage 2 comes at the expense of strengthening the underlying proof system. Ideally, data providers like L2Beat should showcase proof system audits and maturity metrics (preferably metrics of the proof system implementation rather than the entire aggregation, so that we can reuse them), along with a display of the stage.