L2 网路的 3 大阶段：从 0 到 1 再到 2，安全性由治理份额决定

以太坊 rollup安全性的三个阶段可以根据安全委员会何时可以覆盖无信任（即纯加密或博弈论）组件来判定：

· 阶段 0 ：安全委员会拥有完全控制权。可能有一个运作中的证明系统（Optimism 或 ZK 模式），但安全委员会可以透过简单的多数票机制来推翻它。因此，证明系统仅为「咨询性质」。

· 阶段 1 ：安全委员会需要 75%（至少 6/8）的批准才能覆盖运作系统。必须有一个法定人数阻止子集（如 ≥ 3）在主要组织之外。因此，控制证明系统的难度相对较高，但并非不可逾越。

· 阶段 2 ：安全委员会只能在可证明的错误情况下采取行动。例如，可证明的错误可能是两个冗余的证明系统（例如 OP 和 ZK）相互矛盾。如果有可证明的错误，它只能选择提出的答案之一：它不能任意回应某一机制。

我们可以用下面的图表来表示安全委员会在不同阶段拥有的「投票份额」：

1，以及从阶段 1 发展到阶段 2 的最优时机分别是什么？

不立即进入阶段 2 的唯一有效理由是，你不能完全信任证明系统——这是一种可以理解的担忧：该系统由一大堆代码组成，如果代码有存在漏洞，那么攻击者可能窃取所有用户的资产。你对证明系统的信心越强（或相反，你对安全委员会的信心越弱），你就越想推动整个网路生态向后一个阶段发展。

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

· 每个安全委员会的成员有 10% 的「单独故障」的可能；

· 我们将活跃性故障（拒绝签署合约或金钥不可用）和安全性故障（签署错误事项或被骇）实际上，我们只假设一个「失败」的类别，其中「失败」的安全理事会成员既签署了错误的事项，又未能签署推进正确的事项；

· 在阶段 0，安全委员会的判定标准是 4/7，在阶段 1 是 6/8 ；

我们存在一个单一的假设（p的设计机制相对，安全委员会可以在两者意见矛盾时打破僵局）。因此，在阶段 2，安全委员会的存在根本无关紧要。

在这些假设下，考虑到证明系统崩溃的特定机率，我们希望最小化 L2 网路崩溃的可能。

我们可以使用二项分布来完成这项工作：

· 如果每个安全理事会成员有 10% 的独立故障机会，那么至少有 4 个在 7 个中故障的机率是 ∑= 47( 7 ) 0.18 阶段的整合系统有固定的 0.2728% 的失败机率。

· 阶段 1 的整合也可能失败，如果证明系统失败且安全委员会验证机制发生 ≥ 3 次失败，无法进行网络计算覆盖（概率 ∑= 38( 8 )∗ 0.1 ∗ 0.98 −= 0.03809179 证明如果安全失败率次或更多次失败，可以自行强制产生一个错误的计算答案（固定 ∑= 68( 8 )∗ 0.1 ∗ 0.98 −= 0.00002341 机率）；

· 期 2 合并失败的机率与证明系统失败的机率一致。

这里以图表形式呈现：

现在，请注意上述简化模型中的假设并不完善：

· 在现实中，安全委员会成员并不完全独立，（他们之间可能）存在「共同模式故障」：他们可能串通一气，或者都受到同样的胁迫或骇客攻击等等。要求在主要组织之外拥有一个法定人数阻止子集的目的是为了避免这一点的发生，但仍然并不完美。

· 证明系统本身可能是由多个独立系统组合而成的（我在先前的部落格中曾提倡这样做）。在这种情况下，（i）证明系统崩溃的机率非常低，并且（ii）即使在阶段 2，安全委员会也很重要，因为它是解决争议的关键。

这两个论点都表明，与图表所示相比，阶段 1 和阶段 2 更具吸引力。

如果你相信数学，那么阶段 1 的存在几乎永远不会被证明是合理的：你应该直接进入阶段 1。我听到的主要反对意见是：如果发生一个关键的错误，可能很难在 8 名安全委员会成员中迅速获得 6 名成员的签名来修复它。但有一个简单的解决方案：赋予任何一名安全委员会成员延迟提款 1 到 2 周的权限，给其他人足够的时间来采取（补救）行动。

同时，然而，过早地跳到阶段 2 也错误的，尤其是如果向阶段 2 过渡的工作是以牺牲加强底层证明系统的工作为代价的话。理想情况下，像 L2Beat 这样的资料提供者应该展示证明系统稽核和成熟度指标（最好是证明系统实作而非整个汇总的指标，这样我们可以重复使用），并附带展示阶段。

原文连结