作者：Vitalik，以太坊创始人；编译：AIMan@金色财经

本文在早期草案基础上进行了扩展。

以太坊Rollup安全性的三个“阶段”可以根据安全委员会何时被允许覆盖无需信任（即纯加密或博弈论）组件来描述：

• 阶段 0：安全委员会拥有完全控制权。可能存在一个证明系统（乐观证明或零知识证明），但安全委员会可以通过简单多数票推翻该系统。因此，该证明系统“仅供参考”。

• 阶段 1：安全委员会获得 75%（至少 8 人中的 6 人）批准即可推翻。达到法定人数阻止的子集（即 >= 3 人）必须位于主要组织之外。因此，推翻证明系统的门槛很高，但并非不可逾越。

• 阶段 2：只有在存在可证明的漏洞的情况下，安全理事会才能采取行动。可证明的漏洞可能是两个冗余证明系统（例如OP和ZK）彼此不一致的情况。如果存在可证明的漏洞，它只能在提议的答案中选择一个：它不能随意回答。

通过一张图表可以模拟这一情况，显示安全理事会在每个阶段的“投票份额”：

一个重要的问题是：L2从阶段0进入阶段1，以及从阶段1进入阶段2的最佳时机是什么时候？

不立即进入阶段2的唯一正当理由是，你并不完全信任证明系统——这种担忧是可以理解的：它包含大量代码，如果代码被破解，攻击者就有可能窃取所有用户的资产。你对证明系统越有信心（或者，反过来说，你对安全委员会越没有信心），你就越想向右走。

事实证明，我们可以用一个简化的数学模型来量化这一点。首先，列出假设：

• 每个安理会成员都有 10% 的独立机会“崩溃”。

• 我们将活跃性故障（拒绝签名或密钥无法访问）和安全故障（签名错误或密钥被黑客入侵）视为同等可能发生的情况。实际上，我们只假设一种“故障”情况，即“故障”的安理会成员既签署了错误的内容，又未能签署正确的内容。

• 在阶段0，安全理事会是 7 个中的 4 个，在阶段1，安全理事会是 8 个中的 6 个。

• 我们假设一个单一的整体证明系统（而不是像 2/3 的设计那样，如果双方意见不一致，安全理事会可以中断关系）。因此，在阶段2，安全理事会根本不重要。

基于这些假设，并给定证明系统崩溃的特定概率，我们希望最小化 L2 崩溃的概率。

通过二项分布可以做到这一点：

• 如果每个安全理事会成员都有 10% 的独立崩溃概率，那么 7 个成员中至少有 4 个崩溃的概率是，因此，阶段0 Rollup 失败的概率固定为 0.2728%。

• 如果证明系统失败，并且安全委员会出现 >= 3 次失败，则阶段1 Rollup可能会失败，因此它无法覆盖（概率乘以证明系统失败率），或者如果安全理事会发生 6 次以上失败，并且可以自行强制给出错误答案（固定可能性）。

• 阶段2 Rollup 崩溃的概率恰好等于证明系统失效的概率。

下图反映了上述分析：

正如推测的那样，随着证明系统质量的提高，从阶段0转到阶段1，再从阶段1转到阶段2的最佳时机如上图所示。使用阶段0质量的证明系统执行阶段2 是最糟糕的。

需要注意的是，上述简化模型中的假设非常不完善：

• 实际上，安全理事会成员并不是独立的，并且存在“常见模式故障”：他们可能串通一气，或者都以同样的方式受到胁迫或黑客攻击等。要求在主要组织之外设立一个法定人数阻止子集是为了缓解这种情况，但这还远远不够完美。

• 证明系统本身可以是多个独立系统的组合（这正是我在此前文章中倡导的）。在这种情况下，(i) 证明系统被攻破的概率最终会非常低；(ii) 即使在阶段2，安全委员会也发挥着决定性作用，可以打破僵局。

这两个论点都暗示阶段1和阶段2比图表显示的更具吸引力。如果你认真计算一下，你会发现阶段0几乎永远没有道理：你至少应该直接进入阶段1。我听到的主要反对意见是：如果出现严重漏洞，让8个安理会成员中的6个足够快地签署修复协议可能太难了。但有一个简单的解决办法：允许任何一个安理会成员将取款许可推迟1到2周，让其他所有成员都有足够的时间采取行动。

但与此同时，过快进入阶段2也是错误的，尤其是如果进入阶段2的工作是以牺牲强化底层证明系统的工作为代价的。理想情况下，像l2beat这样的数据提供商应该在阶段推进的同时，展示证明系统审计和成熟度指标（最好是证明系统实现的审计和成熟度指标，而不是整个 rollup 的审计和成熟度指标，以便我们能够重复使用）。