Original Title: "Vitalik's Mathematical Model Revealed: When Should Rollups Transition to 'Fully Decentralized'? System Security is Key"
Original Author: Editor Jr., BlockTempo
On May 4, Daniel Wang, the founder of the Loopring protocol, expressed his views on the decentralization security issues of Ethereum L2 Rollups on the X platform, which drew a response from Ethereum founder Vitalik Buterin. The focus of their discussion centered on when Rollups should transition from centralized or partially decentralized (Stage 0 or Stage 1) to fully decentralized (Stage 2), and how to ensure the security of this process.
Daniel Wang: Code Maturity is Key to Rollup Security
Daniel Wang emphasized that the practical maturity of the code is crucial for ensuring system stability. He believes that even if a Rollup reaches the fully decentralized Stage 2, if its code has not been stress-tested in a real environment, it may still have vulnerabilities and be unable to withstand profit-motivated hacker attacks, such as those from the state-sponsored Lazarus group.
Therefore, Daniel Wang pointed out that Rollups manage a large amount of assets and must prove the reliability of their code under high economic pressure. He proposed the "#BattleTested" label as an independent evaluation standard, focusing on code maturity, separate from the L2Beat stage model (Stage 0-2). The specific criteria include:
· The code has been running on the Ethereum mainnet for over 6 months;
· Continuously protecting at least $100 million in total locked value (TVL), with at least $50 million in ETH and major stablecoins;
· Each code upgrade must be re-evaluated to retain the label.
Daniel Wang wrote in a tweet:
1/ Not all code is created equal. A Rollup may reach Stage 2, but the code it executes may be new code that has never been tested under real pressure.
2/ I propose an independent label: #BattleTested. A Rollup can be considered #BattleTested if its current code and configuration have been running on the Ethereum mainnet for over 6 months and continuously protect over $100 million in total locked value (TVL), with at least $50 million in ETH and major stablecoins.
3/ #BattleTested is not permanent. Any upgrade resets the clock. Rollups must prove their operation again in a production environment with actual value to regain this label.
4/ This label is independent of @l2beat's stage model. A Rollup may reach Stage 2 but not be #BattleTested, or it may be #BattleTested but not reach Stage 2. One is about decentralization, the other is about code maturity.
5/ @taikoxyz aims to reach Stage 2 and upgrade using #BattleTested code (we may need another Ethereum test Rollup…).
Vitalik Buterin: Decentralization Must Prove System is Sufficiently Reliable
In response to Daniel Wang's views, Vitalik emphasized that the timing for Rollup decentralization should be based on the reliability of the proof system; it is only suitable to enter Stage 2 when its failure probability is lower than the risks of centralization. He proposed a simplified mathematical model, assuming that members of the security committee have a 10% independent failure probability (including liveness failure or security failure), comparing the individual security of Stage 0 (4-of-7 multisig), Stage 1 (6-of-8 multisig), and Stage 2.
Vitalik further pointed out that in reality, the security committee may experience "common mode failures" due to collusion or simultaneous attacks, causing the security of Stage 0 and Stage 1 to be lower than the model predicts, thus suggesting that Stage 2 should be entered earlier. He advocated designing the proof system as a multisig structure to reduce failure probabilities and suggested that L2Beat incorporate auditing and maturity metrics for the proof system to enhance cross-project evaluation efficiency:
Here is a simplified mathematical model showing when to enter Stage 2.
Assumption: Each member of the security committee has an independent 10% "failure" probability.
We consider liveness failures (refusal to sign or key inaccessibility) and security failures (signing incorrect content or key compromise) as having equal probability.
Goal: Minimize the probability of protocol failure under the above assumptions.
The security committee in Stage 0 requires 4 out of 7 to agree, while in Stage 1, it requires 6 out of 8 to agree.
Please note that these assumptions are very imperfect. In reality, security committee members may experience "common mode failures": they may collude, all be coerced, or be hacked in the same way, etc. This makes the security of Stage 0 and Stage 1 lower than what the model shows, so the best time to enter Stage 2 is earlier than the model suggests.
Moreover, the failure probability of the proof system can be significantly reduced by setting the proof system itself as a multisig of multiple independent systems. I suspect that all Stage 2 deployments in the initial years will adopt this approach. Considering these factors, here is the chart. The X-axis represents the failure probability of the proof system, and the Y-axis represents the failure probability of the protocol.
As the quality of the proof system improves, 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 Stage 2 is the worst scenario. In short: @l2beat ideally should display auditing and maturity metrics for the proof system (preferably targeting the implementation of the proof system rather than the entire Rollup for reusability) and show them alongside the stages.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
