Ethereum founder Vitalik Buterin recently discussed the timing of Rollup decentralization with Loopring protocol founder Daniel Wang on the X platform. Vitalik emphasized that the timing of Rollup decentralization should be based on the reliability of the Proof System, and it is only suitable to enter Stage 2 when its failure probability is lower than the centralization risk.
To further explain his point of view, Vitalik wrote another article yesterday (6) to expand on his response on the X platform, and once again emphasized that the timing of Ethereum Rollup decentralization (from Phase 0 to Phase 1, and then to Phase 2) should depend on the reliability of the Proof System and the risk comparison of the Security Council.
The Dynamic Zone compiled and organized Vitalik's original text as follows.
Mathematical model of Ethereum Rollup phase transition: when to enter phase 1 and phase 2
The three “stages” of Ethereum Rollup security can be described based on when the Security Council can cover the trustless (pure cryptography or game theory) components:
- Stage 0: The Safety Committee has full control. There may be a proof system (either optimistic or ZK), but the security committee can overturn its results through a Simple Majority Vote. Therefore, the certification system is of advisory nature only.
- Stage 1: 75% (at least 6 out of 8) of the safety committee must agree to override the result. The Quorum-Blocking Subset (i.e. at least 3 people) must be from outside the main organization. Therefore, the threshold for coverage proof systems is high, but not insurmountable.
- Stage 2: The Security Committee can take action only when vulnerabilities are proven to exist. For example, two redundant proof systems (such as optimistic and zero-knowledge, OP and ZK) produce different results. If there is a proof loophole, the Security Committee can only choose an answer from the existing proposals and cannot make an arbitrary decision.
We can use a chart to show the "Share of the Vote" of the Safety Committee at each stage:
An important question is: When should L2 transition from Stage Zero to Stage One, and then from Stage One to Stage Two?
The only legitimate reason not to move to Phase 2 immediately is a lack of complete trust in the attestation system — an understandable concern: the attestation system contains a large amount of code, and if there is a problem with the code, an attacker could steal all user assets. The more confidence you have in the proof system (or the less confidence you have in the security committee), the more you tend to move to the right (i.e. more decentralized).
In fact, we can quantify this using a simplified mathematical model. First, list the assumptions:
- Each Safety Committee member has an independent 10% chance of "breaking".
- We treat liveness failures (such as refusing to sign or keys being inaccessible) and safety failures (such as signing the wrong content or keys being hacked) as equally likely. In practice, we assume a uniform class of “failures” where a failed safety committee member both signs the wrong thing and is unable to sign the correct thing.
- The safety committee for Phase Zero requires 4-of-7 approval, while the safety committee for Phase I requires 6-of-8 approval.
- We assume a Monolithic Proof System, rather than a 2-of-3 design (where a safety committee resolves disputes when the two disagree). Therefore, in the second phase, the safety committee has no influence at all.
Under these assumptions, given a certain probability of proving that the system fails, we wish to minimize the probability of L2 failure.
We can calculate this using Binomial Distributions:
- If each member of the safety committee has an independent 10% chance of failure, then the probability of at least 4 out of 7 members failing is (calculation formula omitted). Therefore, the fixed failure probability of the stage zero Rollup is 0.2728%.
- The first stage of the Rollup may fail for the following reasons: First, the Proof System fails and 3 or more members of the Security Council fail, making it impossible to overwrite the result; second, 6 or more members of the Security Council fail and can force through the wrong answer on their own.
- The failure probability of the second-stage Rollup is equal to the failure probability of the proof system.
Here is the chart:
As predicted, as the quality of the proof system improves, the optimal stage shifts from stage zero to stage one, and then from stage one to stage two. Using a stage-zero quality proof system for stage-2 is the worst possible thing.
It is important to note that the assumptions of the above simplified model are very imperfect:
- In reality, members of the security committee are not independent and may experience “common mode failures” such as collusion, coercion, or being hacked in the same way. This makes Phase Zero and Phase I less safe than the model suggests. Requiring that a subset of the blocking majority come from outside the main organization is intended to alleviate this problem, but is still far from perfect.
- The proof system itself may consist of multiple independent systems. In this case, (i) the probability of proving a system failure is likely to be very low, and (ii) even in the second phase, the safety committee still has the role of resolving disputes (Tiebreaking).
These two arguments suggest that Phases 1 and 2 are more attractive than the chart suggests. Going strictly by mathematical model, stage zero almost never makes sense: you should at least go straight to stage one. The main argument against this view is that if a critical bug occurs, it may be difficult to quickly gather 6 out of 8 people to sign to fix the problem. But there is a simple solution: grant a single security committee member the ability to delay withdrawals for 1 to 2 weeks, giving others enough time to act.
However, it would be a mistake to jump to phase 2 too quickly, especially if the effort to strengthen the underlying proof system is sacrificed in order to get there. Ideally, data providers like L2Beat should show audits and maturity metrics (preferably for the proof system implementation rather than the entire Rollup to facilitate reuse) of the proof system, and display them along with the stages.
