Vitalik Explores Rollup's 'Fully Decentralized' Process: Security is Key

Original Article Title: "Vitalik's Mathematical Model Revealed: When Will Rollup Move Towards 'Complete Decentralization,' System Security Is Key"

Original Article Author: Editor Jr., BlockTempo

Loopring Protocol founder Daniel Wang expressed his views on the decentralized security of Ethereum L2 Rollup on May 4th on the X platform, prompting a response from Ethereum founder Vitalik Buterin. The focus of their discussion was on when Rollup should transition from centralization or partial decentralization (Stage 0 or Stage 1) to complete decentralization (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 to ensuring system stability. He believes that even if Rollup reaches the fully decentralized second stage (Stage 2), if its code has not been stress-tested in a real-world environment, vulnerabilities may still exist, making it unable to withstand profit-motivated hacker attacks, such as Lazarus, a state-sponsored group.

Therefore, Daniel Wang pointed out that Rollup manages a large amount of assets and must prove the reliability of the code under high economic pressure. To this end, he proposed the "#BattleTested" tag as an independent assessment standard, focusing on code maturity, distinct from the L2Beat's stage model (Stage 0-2). Specific criteria include:

· The code has been running on the Ethereum mainnet for over 6 months;

· It continuously protects at least $1 billion in total value locked (TVL), with at least $50 million in ETH and major stablecoins;

· After each code upgrade, it must pass a retest to retain the tag.

Daniel Wang wrote in a tweet:

1/ Not all code is created equal. A Rollup may reach the second stage, but it may be running new, untested code that has not been stress-tested in a real-world scenario.

2/ I propose an independent tag: #BattleTested. A Rollup can be called #BattleTested if its current code and configuration have been running on the Ethereum mainnet for over 6 months and consistently protect over $1 billion in TVL, with at least $50 million in ETH and major stablecoins.

3/ #BattleTested is not permanent. Any upgrade will reset the timer. A Rollup must prove its operation once again in a real-world setting under significant 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 be #BattleTested but not reach Stage 2. One is about decentralization, the other about code maturity.

5/ @taikoxyz's goal is to reach Stage 2 and upgrade using #BattleTested code (we may need another Ethereum test Rollup…).

Vitalik Buterin: Decentralization Requires Proving System's Sufficient Reliability

Regarding Daniel Wang's viewpoint, Vitalik emphasizes that the timing of Rollup decentralization should be based on the reliability of the proof system, only suitable for entering Stage 2 when its failure probability is lower than the risk of centralization. He presents a simplified mathematical model, assuming security committee members have a 10% independent failure probability (including liveness failures or security failures), comparing the individual security of Stage 0 (4-of-7 multisig), Stage 1 (6-of-8 multisig), and Stage 2.

Vitalik further points out that in reality, security committees may exhibit "common-mode failures" due to collusion or simultaneous attacks, resulting in lower security than predicted by the model in Stage 0 and Stage 1. Therefore, it should actually enter Stage 2 earlier. He advocates designing the proof system as a multisignature structure to reduce the failure probability and suggests that L2Beat incorporate auditing of the proof system and maturity metrics to enhance cross-project evaluations:

Here is a simplified mathematical model showing when to enter Stage 2.

> Assumption: Each security committee member has an independent 10% "failure" probability.

> We consider liveness failures (refusing to sign or inaccessible keys) and security failures (signing incorrect content or key compromise) as equally probable.

> Goal: Minimize the probability of protocol failure under the above assumptions.

> The Stage Zero security committee requires 4 out of 7 members to agree, and the Stage One requires 6 out of 8 members to agree.

It is important to note that these assumptions are highly imperfect. In reality, security committee members exhibit a "common mode failure": they may collude, all be coerced, be compromised in the same way, etc. This results in the security of Stage Zero and Stage One being lower than the model suggests, so the optimal time to move to Stage Two is earlier than implied by the model.

Furthermore, the probability of a proof system failure can be dramatically reduced by setting the proof system itself as a multi-signature of multiple independent systems. I speculate that all Stage Two deployments in the first few years will use this approach. Taking these into consideration, here is a chart. The X-axis represents the proof system failure probability, and the Y-axis represents the protocol failure probability.

As 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 case scenario. In short, @l2beat ideally should showcase audit and maturity metrics of the proof system (preferably specific to the proof system implementation rather than the entire Rollup for reusability) alongside the stages.

Original Article Link