L Wang 平台 5 月在以太坊针对 Lup 15 月 5 月 5 月针对的去中心化安全性问题发表了看法，引来了以太坊创办人 Vitalik Buterin 的回应。两人讨论的焦点集中在 Rollup 何时应从中心化或部分去中心化（Stage 0 或 Stage 1）转向完全去中心化（Stage 2），以及如何确保这一过程的安全性。

Daniel Wang：程式码成熟度是 Rollup 安全的关键

Daniel Wang 强调，程式码的实战成熟度对确保系统稳定性至关重要。他认为，即使 Rollup 达到完全去中心化的第二阶段（Stage 2），若其代码未经真实环境的压力测试，仍可能存在漏洞，无法抵御以利润为动机的黑客攻击，例如国家支持的 Lazarus 集团。

因此 Daniel Wang 指出，Rollup 管理大量资产，必须在高经济压力下证明程式码的可靠性。对此他提出了「#BattleTested」标签作为独立评估标准，专注于程式码成熟度，与 L2Beat 的阶段模型（Stage 0-2）分开评估。具体标准包括：

· 代码在以太坊主网上运行超过 6 个月；

· 持续保护至少 1 亿美元的总锁定价值（TVL），其中至少 5,000 万美元为 ETH 和主要稳定货币；

·每次通过测试代码

Daniel Wang 在推文中这样写道：

1/ 并非所有程式码都生而平等。 一个 Rollup 可能达到第二阶段，但执行的却是从未在真实压力下测试的新程式码。

2/ 我提议一个独立的标签：#BattleTested。一个 Rollup 若其当前代码和配置已在以太坊主网上运行超过 6 个月，且持续保护超过 1 亿美元的总锁定价值（TVL），其中至少 5,000 万美元为 ETH 和主要稳定币，则可称为 #BattleTested。

3/ #BattleTested 并非永久的。 任何升级都会重设计时。 Rollup 必须再次透过在实际价值下的生产环境证明其运作来重新获得此标签。

4/ 此标签独立于 @l2beat 的阶段模型。 一个 Rollup 可能达到第二阶段但未获 #BattleTested，或者已获 #BattleTested 但未达第二阶段。一个关于去中心化，另一个关于程式码成熟度。

5/ @taikoxyz 的目标是达到第二阶段，并使用 #BattleTested 的程式码进行升级（我们可能需要另一个以太坊测试 Rollup…）。

Vitalik Buterin：去中心化需证明系统足够可靠

对于 Daniel Wang 的观点，Vitalik 则强调，Rollup 去中心化故障的时机是基于其系统可靠Stage 2。他提出了一个简化数学模型，假设安全委员会成员有 10% 的独立故障机率（包括活性失败或安全性失败），比较 Stage 0（4-of-7 多重签名）、Stage 1（6-of-8 多重签名）与 Stage 2 的个别安全性。

Vitalik 续指出，现实中安全委员会可能因共谋或同时被攻击而出现「共同模式失败」，使得 Stage 0 和 Stage 1 的安全性低于模型预测，因此实际上应更早进入 Stage 2。他主张将证明系统设计为多重签章结构，以降低故障机率，并建议 L2Beat 纳入证明系统的稽核与成熟度指标，以提升跨专案评估效率：

以下是显示何时进入第二阶段的简化数学模型。

> 假设：每个安全委员会成员有独立的 10%「故障」机率。

> 我们将活性失败（拒绝签署或金钥无法存取）与安全性失败（签署错误内容或金钥被骇）视为同等机率。

> 目标：在上述假设下最小化协议故障的机率。

> 第零阶段安全委员会为 7 人中需 4 人同意，第一阶段为 8 人中需 6 人同意。

请注意，这些假设非常不完美。现实中，安全委员会成员存在「共同模式失败」：他们可能共谋，或全被胁迫，或以相同方式被骇等。这使得第零阶段和第一阶段的安全性低于模型显示，因此进入第二阶段的最佳时机比模型暗示的更早。

此外，证明系统的故障机率可透过将证明系统本身设为多个独立系统的多重签章来大幅降低。我猜测最初几年的所有第二阶段部署都将采用这种方式。考虑到这些，以下是图表。 X 轴为证明系统故障的机率，Y 轴为协定故障的机率。

随著证明系统品质提高，最佳阶段从第零阶段转向第一阶段，再从第一阶段转向第二阶段。使用第零阶段品质的证明系统进行第二阶段是最糟糕的。简而言之：@l2beat 理想上应展示证明系统的审计和成熟度指标（最好针对证明系统实现，而不是整个 Rollup，以便重复使用），并与阶段一同显示。

原文连结