Original source: Vitalik
Compiled by: Odaily Planet Daily ( @OdailyChina )
Translator: Wenser ( @wenser 2010 )
Editors note: The discussion on the three stages of Ethereum rollup security has always been the focus of the Ethereum ecological community. This is not only related to the operational stability of the Ethereum mainnet and L2 network, but also to the actual development of the L2 network. Recently, Daniel Wang, a member of the Ethereum community, proposed the naming tag #BattleTested for the L2 network Stage 2 on the X platform, believing that only L2 networks with current code and configuration that have been online on the Ethereum mainnet for more than 6 months and have maintained a total locked value (TVL) of more than 100 million US dollars and at least 50 million US dollars of ETH and major stablecoins can obtain this title, and the title is dynamically evaluated to avoid the emergence of on-chain ghosts. Ethereum co-founder Vitalik subsequently gave a detailed answer to the question and shared his views, which are compiled by Odaily Planet Daily as follows.
The 3 major stages of L2 network: from 0 to 1 to 2, security is determined by governance share
Three phases of Ethereum rollup security can be determined based on when the security committee can cover the trustless (i.e. purely cryptographic or game theoretic) components:
Phase 0: The Safety Committee has full control. There may be a running proof system (Optimism or ZK mode), but the Safety Committee can overturn it with a simple majority vote. Therefore, the proof system is only advisory.
Phase 1: 75% (at least 6/8) approval is required by the safety committee to cover the running system. There must be a quorum blocking subset (e.g. ≥ 3) outside the main organization. Therefore, the difficulty of controlling the proof system is relatively high, but not insurmountable.
Phase 2: The safety committee can only act in the case of provable errors. For example, a provable error could be that two redundant proof systems (e.g. OP and ZK) contradict each other. If there is a provable error, it can only choose one of the proposed answers: it cannot respond to a mechanism arbitrarily.
We can use the following diagram to represent the voting shares that the safety committee has at different stages:
Three-stage governance voting structure
An important question is: What is the optimal time for an L2 network to transition from stage 0 to stage 1, and when to evolve from stage 1 to stage 2?
The only valid reason not to move to Phase 2 right away is that you can’t fully trust the proof system — an understandable concern: the system consists of a bunch of code, and if there’s a bug in that code, then an attacker could steal all of the users’ assets. The more confidence you have in the proof system (or conversely, the less confidence you have in the security committee), the more you’ll want to push the entire network ecosystem to the next phase.
In fact, we can quantify this using a simplified mathematical model. First, lets list the assumptions:
Each member of the safety committee has a 10% chance of individual failure;
We treat liveness failures (refusal to sign contracts or keys not available) and safety failures (signing the wrong thing or keys hacked) as equally likely. In practice, we only assume a single “failure” class, where a “failed” security council member both signed the wrong thing and failed to sign the right thing forward;
In stage 0, the safety committees criteria are 4/7 and in stage 1 they are 6/8;
We assume that there is a single overall proof system (as opposed to a 2/3 design mechanism where the safety committee can break a deadlock when the two disagree). Therefore, in phase 2, the existence of the safety committee is not important at all.
Under these assumptions, we want to minimize the chance of the L2 network crashing, given the certain probability of the attestation system crashing.
We can use the binomial distribution to do this:
If each security council member has a 10% chance of independent failure, then the probability that at least 4 out of 7 fail is ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 Therefore, the integrated system at stage 0 has a fixed 0.2728% probability of failure.
The integration of Phase 1 can also fail if the proof system fails and the safety committee verification mechanism fails ≥ 3 times, making network computation coverage impossible (with probability ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplied by the proof system failure rate), or if the safety committee fails 6 or more times and can force itself to generate an incorrect computation answer (with fixed probability ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341);
The probability of failure of the phase 2 merge is consistent with the probability of failure of the proof system.
Here it is presented in graphical form:
Proof of system failure probability at different stages of L2 network
As the results above surmise, as the quality of the proof system improves, the best stage shifts from stage 0 to stage 1, and then from stage 1 to stage 2. Using a stage 0 quality proof system to run a stage 2 network is the worst result.
Now, note that the assumptions in the above simplified model are not perfect:
In reality, security committee members are not completely independent, and there are common mode failures: they may collude, or all be subject to the same coercion or hack, etc. Requiring a quorum block subset outside the main organization is intended to avoid this, but its still not perfect.
The proof system itself may be composed of multiple independent systems (I have advocated this in previous blogs ). In this case, (i) the probability of the proof system crashing is very low, and (ii) the safety committee is important even in phase 2 because it is key to resolving disputes.
Both arguments suggest that Phases 1 and 2 are more attractive than the chart suggests.
If you believe in math, then the existence of Phase 1 can almost never be justified: you should just go straight to Phase 1. The main objection Ive heard is that if a critical bug occurs, it might be hard to quickly get 6 of the 8 safety committee members to sign off on it. But theres a simple solution: give any one safety committee member the power to delay withdrawals for 1-2 weeks, giving the others enough time to take (remedial) action.
At the same time, however, it would be a mistake to jump to Phase 2 too early, especially if the work to transition to Phase 2 comes at the expense of work to strengthen the underlying proof systems. Ideally, data providers like L2Beat should be showing proof system audits and maturity metrics (preferably proof system implementations rather than entire aggregate metrics so we can reuse them) along with the showcase phase.
