Mathematical model reveals L2 stage selection logic: Why is phase 1 possible to be skipped?

Written by: Vitalik Buterin

Compiled by: Wenser, Odaily Planet Daily

Editor's note: The three stages of Ethereum rollup security have always been the focus of the Ethereum ecological community. This is not only related to the operational stability of the Ethereum main network and L2 network, but also to the real development status of the L2 network. Recently, Daniel Wang, a member of the Ethereum community, proposed the naming tag #BattleTested for the L2 network Stage 2 stage on the X platform, believing that only the current code and configuration are online on the Ethereum main network for more than 6 months and have maintained a total locked value of more than US$100 million (TVL) and at least US$50 million of ETH and major stablecoins L2 network can obtain this title, and the title is dynamically evaluated to avoid the generation of "on-chain ghosts". Ethereum co-founder Vitalik then gave a detailed answer to the question and shared his views, and the Odaily Planet Daily compiled as follows.

The three major stages of the L2 network: from 0 to 1 to 2, security is

determined by the governance share

The three phases of Ethereum rollup security can be determined based on when the Security Committee can override trustless (i.e. pure encryption or game theory) components:

• Phase 0: The Safety Committee has full control. There may be a running proof system (Optimism or ZK mode), but the Security Council can overturn it with a simple majority vote mechanism. Therefore, the proof system is only "consultational".
• Phase 1: The Safety Committee requires 75% (at least 6/8) approval to cover the operating system. There must be a quorum blocking subset (e.g. ≥ 3) outside the main organization. Therefore, it is relatively difficult to control the proof system, but it is not insurmountable.
• Phase 2: The Safety Committee can only act in case of proven errors. For example, proveable errors may be that two redundant proof systems (such as OP and ZK) conflict with each other. If there is a proven error, it can only choose one of the answers proposed: it cannot respond a certain mechanism arbitrarily.

We can use the following chart to illustrate the "voting share" that the Security Council has 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 to not enter Phase 2 immediately is that you can’t fully trust the proof system – an understandable concern: the system consists of a large pile of code, and if the code has a vulnerability, 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 a later stage.

In fact, we can quantify this with simplified mathematical models. First, let's list the assumptions:

• Each member of the Safety Committee has a 10% chance of "separate failure";
• We consider active failures (refusing to sign a contract or the key is not available) and security failures (signing errors or keys are hacked) as equally possible. In fact, we only assume a category of “failure” where “failure” members of the Security Council both signed the wrong things and failed to sign the right things;
• In stage 0, the criterion of the Safety Committee is 4/7, and in stage 1 is 6/8;
• We assume that there is a single holistic proof system (as opposed to the 2/3 design mechanism, the Safety Committee can break the deadlock when the two are in conflict). Therefore, in Phase 2, the existence of the Security Council is simply irrelevant.

Under these assumptions, we want to minimize the possibility of L2 network crashing, considering the specific probability of proving the system crash.

We can do this using a binomial distribution:

• If each Security Council member has a 10% chance of independent failure, then at least 4 of the 7 failures are ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 Therefore, the integrated system in phase 0 has a fixed probability of failure of 0.2728%.
• Integration in Phase 1 may also fail, if the proof system fails and the Security Committee verification mechanism fails ≥ 3 times, network computational coverage cannot be performed (probability ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplied by the proof system failure rate), or if the proof system failure occurs 6 or more times, a wrong computational answer can be generated by itself (fixed ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probability);
• The probability of the merge failure in Phase 2 is consistent with the probability of the proof system failure.

Here is presented in a graph form:

 L2 network proves the probability of system failure at different stages

As the results speculated above, as the quality of the proven system improves, the optimal phase is transferred from stage 0 to stage 1 and then from stage 1 to stage 2. Using a proof system of phase 0 quality to perform a phase 2 network operation is the worst result.

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

• In reality, the members of the Security Council are not completely independent, and there may be a "common mode failure": they may collude, or they are all subject to the same coercion or hacking, etc. The purpose of requiring a quorum blocking subset outside the main organization is to avoid this, but it is still not perfect.
• Prove that the system itself may be composed of multiple independent systems (I advocated this in my previous blog). In this case, (i) the probability of proving that the system crashes is very low, and (ii) the Security Council is important even in Phase 2, as it is the key to resolving the dispute.

Both arguments suggest that phases 1 and 2 are more attractive than those shown in the chart.

If you believe in mathematics, then the existence of stage 1 will almost never be justified: you should go directly to stage 1. The main objection I heard is: If a critical error occurs, it can be difficult to quickly obtain 6 members of the 8 Security Council members to fix it. But there is a simple solution: Give any Security Council member the authority to delay withdrawals for 1 to 2 weeks, giving others enough time to take (remedial) action.

At the same time, however, it is also wrong to jump to Phase 2 too early, especially if the transition to Phase 2 comes at the expense of strengthening the underlying proof system. Ideally, a data provider like L2Beat should present proof system audits and maturity metrics (preferably proof system implementation rather than the entire summary metrics so we can reuse) with a display phase.