Loopring protocol founder Daniel Wang expressed his views on the decentralized security of Ethereum L2 Rollup on the X platform on May 4th, which drew a response from Ethereum founder Vitalik Buterin. The focus of their discussion centered on when Rollup should transition from centralized or partially decentralized (Stage 0 or Stage 1) to fully decentralized (Stage 2), and how to ensure the safety of this process.
Daniel Wang: Code Maturity is Key to Rollup Security
Daniel Wang emphasized that the practical maturity of code is crucial to ensuring system stability. He believes that even if a Rollup reaches the second stage of full decentralization (Stage 2), if its code has not been stress-tested in a real environment, it may still have vulnerabilities that cannot withstand hacker attacks motivated by profit, such as the state-sponsored Lazarus group.
Therefore, Daniel Wang pointed out that Rollup manages a large number of assets and must prove the reliability of its code under high economic pressure. He proposed the "#BattleTested" tag as an independent assessment standard, focusing on code maturity and separate from L2Beat's stage model (Stage 0-2). Specific criteria include:
· Code has been running on the Ethereum mainnet for over 6 months;
· Continuously protecting at least $100 million in total locked value (TVL), of which at least $50 million is ETH and major stablecoins;
· Each code upgrade requires re-passing the test to retain the tag.
Daniel Wang wrote in his tweet:
1/ Not all code is created equal. A Rollup may reach the second stage but is executing new code that has never been tested under real stress.
2/ I propose an independent tag: #BattleTested. A Rollup whose current code and configuration has been running on the Ethereum mainnet for over 6 months and continuously protecting over $100 million in total locked value (TVL), of which at least $50 million is ETH and major stablecoins, can be called #BattleTested.
3/ #BattleTested is not permanent. Any upgrade will reset the timer. The Rollup must prove its operation again in a production environment with actual value to regain this tag.
4/ This tag is independent of @l2beat's stage model. A Rollup may reach the second stage but not be #BattleTested, or be #BattleTested but not reach the second stage. One is about decentralization, the other about code maturity.
5/ @taikoxyz's goal is to reach the second stage and upgrade with #BattleTested code (we may need another Ethereum test Rollup...).
Vitalik Buterin: Decentralization Requires Proving System Reliability
Regarding Daniel Wang's view, Vitalik emphasized that the timing of Rollup decentralization should be based on the reliability of the Proof System, and only when its failure probability is lower than the centralization risk is it suitable to enter Stage 2. He proposed a simplified mathematical model, assuming that security committee members 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, security committee members may experience "common mode failure" due to collusion or simultaneous attacks, making the security of Stage 0 and Stage 1 lower than the model predicts, so they should actually enter Stage 2 earlier. He advocates designing the proof system as a multisig structure to reduce failure probability and suggests that L2Beat incorporate proof system audit and maturity indicators to improve cross-project assessment efficiency:
Below is a simplified mathematical model showing when to enter the second stage.
> Assumption: Each security committee member has an independent 10% "failure" probability.
> We view liveness failure (refusing to sign or key inaccessibility) and security failure (signing incorrect content or key being hacked) as equally probable.
> Objective: Minimize protocol failure probability under the above assumptions.
> Stage zero security committee requires 4 out of 7 to agree, stage one requires 6 out of 8.
Note that these assumptions are very imperfect. In reality, security committee members may experience "common mode failure": they may collude, or all be coerced, or be hacked in the same way. This makes the security of stage zero and stage one lower than the model shows, so the best time to enter stage two is earlier than the model suggests.
Moreover, the failure probability of the proof system can be significantly reduced by making the proof system itself a multisig of multiple independent systems. I guess that all stage two deployments in the first few years will adopt this approach. Considering these, here is the chart. The X-axis is the probability of proof system failure, and the Y-axis is the protocol failure probability.
As the proof system quality improves, the optimal stage transitions from stage zero to stage one, and then from stage one to stage two. Using a stage zero quality proof system for stage two is the worst. In short: @l2beat should ideally show audit and maturity indicators for the proof system (preferably for proof system implementation, rather than the entire Rollup, to facilitate reuse), and display them alongside the stages.
Welcome to join BlockBeats official community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Twitter Official Account: https://twitter.com/BlockBeatsAsia
