阶段更新：安全委员会要求

感谢 Vitalik Buterin , Justin Drake , Alex Gluchowski , Yoav Weiss , Patrick McCorry 和 Maurelian 对最初版本和新版本的 Stages Framework 的反馈。

背景

Stages Framework的初始版本 可以概括如下：

• Stage 0 — 完全的辅助轮： 在这个阶段，rollup实际上是由 operators 运行的。不过，仍然存在一个开源软件，允许从发布在 L1 上的数据中重建状态，用于将状态根与提议的状态根进行比较。
• Stage 1 — 有限的辅助轮： 在这个阶段，rollup过渡到由智能合约管理。不过，安全委员会可能会继续存在，以解决潜在的错误。这个阶段的特点是实现了功能完备的证明系统，欺诈证明提交的去中心化，以及在没有 operator 协调的情况下提供用户退出的机制。由多元化的参与者组成的安全委员会提供了一个安全网，但其权力也带来潜在的风险。
• Stage 2 — 没有辅助轮： 这是最终阶段，rollup完全由智能合约管理。在这一点上，欺诈证明系统是无需许可的，并且在发生不必要的升级时，用户有充足的时间退出。安全委员会的角色严格限定于解决可以在链上裁决的正确性错误，并且用户可以免受治理攻击。

很明显，Stage 0 代表了 operators 的完全控制，Stage 2 代表了智能合约的完全控制，而 Stage 1 则旨在作为两者之间的中间状态。在 Stage 1 中，即时升级的能力不再掌握在核心团队手中，而是委托给由足够去中心化的成员组成的安全委员会。

定义安全委员会的要求对于将其与简单的多签区分开至关重要，从而区分于 Stage 0 的 rollup。当前的要求是：

• 至少 8 名参与者。
• 至少 50% 的成员来自核心组织之外。
• 至少 50% 的阈值。
• 达成共识至少需要 2 名外部人员。
• 成员公开宣布。

问题

让我们考虑在这些要求下的最小安全委员会：8 名成员，50% 的阈值，6 名外部人员和 2 名来自组织内部的人员。

安全委员会可以执行两个操作：

• 通过不否决来接受证明系统的决定。
• 通过推动立即升级来否决证明系统的决定。

在给定的安全委员会设置下，需要50%的成员既遵守证明系统（通过拒绝否决），又可以否决它，至少由2名外部人员和2名内部人员组成。

关键的见解在于，可以调整安全委员会的阈值，使其更容易遵循证明系统，更难以否决它。

想象一个具有 87.5% 阈值 (7/8) 的多签：至少需要 7 名成员来否决证明系统，但只需要 2 名成员来阻止此类否决 被确认。

让我们尝试通过添加“虚拟”地址（如许多零地址）将此 7/8 多签转换为 51%（即 ⌊|multisig|*50%⌋+1）。这些地址是“虚拟的”，因为它们从不投票支持升级，就好像他们总是希望同意智能合约证明系统一样，无论该系统是正确的还是有错误的。如果原始阈值较高，则达到 51% 所需添加的虚拟地址数量会更高。例如，对于具有 8/12 (66.6%) 阈值，我们只需要添加 3 个地址即可达到 8/15，而对于 11/12，我们需要添加 8 个地址才能达到 11/20。

由于这些虚拟地址始终“遵循”智能合约，因此我们可以认为它们是证明系统在多签中的“投票权”，并且通常在整个系统中。

再次，在最初的 7/8 多签设置中，多签可以被视为 7/13 (51%) 的多签，其中证明系统具有 5 票，始终用于不否决自身。为了更好地了解它如何与最初的委员会保持一致，让我们再次回顾一下可能的操作：

• 通过阻止否决来接受证明系统决策：需要 7 票，默认情况下由证明系统提供 5 票，需要另外 2 名成员。
• 通过推动否决来拒绝证明系统决策：需要 7 名成员。

由于推动升级或拒绝它所需的活跃成员数量相同，因此可以将此 51% 的“虚拟”多签视为与原始多签等效。

通过使用此虚拟多签，我们可以计算出证明系统在原始 7/8 多签中获得的权力百分比：证明系统由 7/13 虚拟阈值之上的 5 票组成，因此它在多签中占决策权的约 38.5%。

如果你对数学更感兴趣，请查看本文末尾的附录。

回到最初的 50% 阈值多签，很容易看出证明系统拥有完全零投票权：它的存在并不能使拒绝否决比推动否决更容易，因此它没有投票权。

新的要求

正如之前所说，Stage 1 的目标是传达完全的 operators 控制和完全的智能合约控制之间的中间立场。因此，很自然地通过要求证明系统至少拥有一半以上的 L2 决策权来表达这一点，这相当于简单多数阈值虚拟多签中至少 25% 的投票权。

以下是一些示例，可以帮助你熟悉此概念：

• 6/8 多签 (75%) → 27.27% 证明系统权力 ✅
• 5/8 多签 (62.5%) → 11.11% 证明系统权力 ❌
• 9/12 多签 (75%) → 29.41% 证明系统权力 ✅
• 8/12 多签 (66.67%) → 20.00% 证明系统权力 ❌
• 12/16 多签 (75%) → 30.43% 证明系统权力 ✅
• 11/16 多签 (68.75%) → 23.81% 证明系统权力 ❌

除了当多签大小变得很大时，75% 的阈值与至少 25% 的证明系统权力要求非常吻合：

• 14/20 多签 (70%) → 25.93% 证明系统权力 ✅
• 135/200 多签 (67.5%) → 25.56% 证明系统权力 ✅

对于好奇的人来说，≥25% 的证明系统权力成立的最小阈值为 2/3：

有关公式，请参阅附录。

我们不希望安全委员会这么庞大，因此为简单起见，我们同意使用 75% 的阈值要求，同时牢记其背后的基本原理。

计数成员

到目前为止，我们要求至少 50% 的安全委员会成员来自组织外部，并且至少有 2 名外部人员达成共识。此要求意味着，无论多签的大小如何，只需腐化这 2 个人就可以推动恶意升级。

正如 Multichain 团队与中国执法部门之间 的最近事件，或 Oasis 法院命令 所证明的那样，同一组织或同一司法管辖区内的人员共享相同的法律风险，这使得很难将他们视为不同的实体。

目的是创建一个安全委员会，其成员构成足够多样化，以抵抗协调一致的恶意活动、法律胁迫或其他形式的外部影响。由于存在各种极端情况，因此通过客观标准实现此目标已被证明具有挑战性。

考虑到这些复杂性，成员多样性将受到主观评估。建议拥有代表各种组织的成员，这有助于降低单个实体内部潜在串通相关的风险。包括来自不同法律管辖区的成员可以增强委员会对本地化法律行动或法规的抵御能力。

风险分析：何时从 Stage 0 转移到 Stage 1？

在设计安全委员会时，应考虑两种情况：

1. rollup包含一个错误：在这种情况下，安全委员会应迅速升级系统。较低的阈值会增加积极结果的可能性。
2. rollup按预期工作：在这种情况下，安全委员会不应否决该系统。较高的阈值有助于降低这种情况的可能性。

多签的大小和阈值应反映系统和安全委员会本身相关的风险。让我们来看一个例子，让概念更容易理解。一个虚构的rollup安全委员会由15名成员组成。根据他们感知的风险，我们为特定情况分配理论概率：

• 至少 4 名成员出现故障的概率为 10%。
• 至少 8 名成员出现故障的概率为 1%。
• 至少 12 名成员出现故障的概率为 0.1%。

此外，我们为证明系统出现故障分配了 20% 的概率。给定这些概率，我们如何确定哪个阈值是最好的？

假设阈值为 12，则负面结果的概率可以这样计算：0.1%（12 名成员出现故障）+ 20%（证明系统存在错误）* 10%（4 名成员出现故障并阻止升级）≈ 2.1%¹。相反，如果我们假设阈值为 8 以推动升级，则负面结果的概率为 1% + 20% * 1% ≈ 1.2%，这低于上述提出的阈值 12，因此更好。

随着对证明系统信心的增加，应相应地提高阈值，以最终达到 Stage 1。

活性问题

较高的安全委员会阈值可能会引发对修复错误所需推动升级的及时性的担忧。当需要从可能不同的时区聚集大量人员时，这尤其具有挑战性，这些人可能正忙或在睡觉。

因此，实施较低的阈值来暂停 L2 可能是有益的，如果需要，可以使用较高的阈值来覆盖该阈值。除此之外，我们建议进行定期但出乎意料的紧急演习，以练习及时签署消息。

受影响的 rollup：Arbitrum 案例

Stage 1 要求的这个变化仅影响 Arbitrum。除了安全委员会的 9/12 阈值外，Arbitrum 在同一多签中还具有 较低的 7/12 阈值。此阈值允许以 13 天的延迟进行升级，从而提供大约 6 天的退出窗口。由于此较低的阈值不符合被认可为安全委员会的要求（阈值 ≤75%），因此简单的多签标准适用，需要用户至少有 7 天的退出窗口。为了保留其 Stage 1 状态，Arbitrum 必须完全删除较低的阈值，或者延长 L1、L2 或两者的 timelock 延迟。此外，Arbitrum 安全委员会目前包括来自 Offchain Labs 的 2 名成员。

与其他 rollup 相比，Arbitrum 的升级和选举是高度去中心化的，因此，提出、投票和执行都需要时间。目前，尽管 Arbitrum 在技术上不符合新的 Stage 1 要求，但我们将保持其当前指定。我们目前与 Offchain Labs 和 Arbitrum DAO 密切合作，以迅速解决这些问题；但是，如果未及时实施必要的更改，我们将把 rollup 重新分类为 Stage 0。

附录：数学

证明系统在虚拟多签中拥有的权力百分比可以按如下方式计算：

1. 证明系统虚拟投票 = 阈值 — 阻止提案所需的人数
2. 阻止提案所需的人数 = 大小 — 阈值 + 1
3. 等效的 51% 多签大小 = 大小 + 证明系统虚拟投票
4. 证明系统权力 = 证明系统虚拟投票 / 等效的 51% 多签大小

如果你想使用该公式，这是一个快速的 python 脚本，用于计算不同多签的证明系统投票权，并包含一些其他考虑因素→ 链接。

[1] 应减去非独立事件之间的交集，但结论保持不变。

• 原文链接： medium.com/l2beat/stages...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～