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

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

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

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

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

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

一个重要的问题是：L2 网络从阶段 0 转换到阶段 1，以及从阶段 1 发展到阶段 2 的最优时机分别是什么？

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

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

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

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

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

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

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

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

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

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

· 阶段 2 合并失败的概率与证明系统失败的概率一致。

这里以图表形式呈现：

如上所推测的结果，随着证明系统质量的提高，最佳阶段从阶段 0 转移到阶段 1，然后从阶段 1 转移到阶段 2。使用阶段 0 质量的证明系统进行阶段 2 的网络运行是最差的结果。

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

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

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

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

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

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

原文链接