深度解读 L2 Stages 框架与安全委员会新标准
Stages 框架将 Rollup 的治理分为三个阶段，强调从运营者控制到智能合约控制的过渡。更新后的要求明确了安全委员会的配置与功能，快来跟我们一起学习一下吧！
感谢 Vitalik Buterin、Justin Drake、Alex Gluchowski、Yoav Weiss、Patrick McCorry 和 Maurelian 对初版和新版 Stages Framework 提供的宝贵反馈。
🔗原文链接：https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52
作者｜Luca Donno
翻译 & 排版｜Echo
背景
Stages 框架的初始版本可以总结如下：
阶段 0 — 完全保护模式：在此阶段，Rollup 由运营者全面控制。但仍然提供开源软件用于从发布在 L1 的数据中重建状态，并将其与提议的状态根进行比较。
阶段 1 — 有限保护模式：在此阶段，Rollup 过渡到由智能合约治理。然而，可能会保留一个安全委员会来处理潜在的漏洞。此阶段的特点是实施了完全功能的证明系统、欺诈证明提交的去中心化，以及在无需运营者协调的情况下允许用户退出。安全委员会由一组多样化的参与者组成，提供了一种安全保障，但它的权力也可能带来潜在风险。
阶段 2 — 无保护模式：这是最终阶段，Rollup 完全由智能合约管理。在这一阶段，欺诈证明系统无需许可，用户在面对不受欢迎的升级时拥有充足的退出时间。安全委员会的角色仅限于处理可以在链上裁定的准确性错误，用户免受治理攻击的影响。
显而易见，阶段 0 表示由运营者完全控制，而阶段 2 表示由智能合约完全控制，而阶段 1 介于两者之间。在阶段 1 中，即时升级的能力不再掌握在核心团队手中，而是交由组成安全委员会的充分去中心化成员组管理。
明确定义安全委员会的要求对于将其与简单多签区分开来非常重要，这也将区分阶段 0 和阶段 1 Rollup。目前的要求是：
至少有 8 位参与者。
至少 50% 的成员来自核心组织外部。
至少需要 50% 的门槛。
至少需要 2 位外部成员达成共识。
成员需公开宣布。
问题
考虑一个符合这些要求的最低配置的安全委员会：8 名成员、50% 的门槛、6 名外部成员，以及 2 名来自组织的成员。
安全委员会可以执行两项操作：
接受证明系统的决定，不推翻它。
推翻证明系统的决定，推动即时升级。
根据当前安全委员会的设置，推翻证明系统或拒绝推翻都需要至少 50% 的成员支持，至少包括 2 名外部成员和 2 名内部成员。
关键在于，安全委员会的门槛可以调整，使得遵循证明系统的决策更容易，而推翻它的决策更困难。
假设一个 87.5% 门槛的多签 (7/8)：至少需要 7 名成员来推翻证明系统，但仅需要 2 名成员即可阻止这种推翻的确认。
通过增加“虚拟地址”（例如许多零地址），可以将这个 7/8 的多签转变为一个 51% 门槛的多签。这些虚拟地址从不参与升级投票，相当于始终同意智能合约证明系统的决策。虚拟地址的数量与原始门槛的高度成正比。例如，一个具有 8/12 (66.6%) 门槛的多签仅需添加 3 个虚拟地址即可达到 8/15，而一个 11/12 的多签则需添加 8 个地址达到 11/20。
虚拟地址总是“遵循”智能合约系统，可以将它们视为证明系统在整个多签中持有的“投票权”。
在原始 7/8 多签设置中，可以将多签视为一个 7/13 (51%) 的多签，其中证明系统默认拥有 5 票，始终倾向于不推翻自身。这样，我们可以得出以下结论：
接受证明系统的决定（防止推翻）：需要 7 票，默认由证明系统提供 5 票，还需 2 名其他成员。
拒绝证明系统的决定（推动推翻）：需要 7 名成员。
通过这种“虚拟”多签，我们可以计算出证明系统在原始 7/8 多签中的决策权百分比：证明系统在 7/13 多签中占有 5 票，占比约 38.5%。
如果对数学更感兴趣，可以参考本文末尾的附录。
回到原始 50% 门槛的多签，很容易看出，证明系统完全没有投票权：它的存在并没有使得拒绝推翻比推动更容易，因此它的投票权为零。
新的要求
在阶段 1，如前所述，目标是传达一种介于完全运营者控制和完全智能合约控制之间的中间地带。因此，要求证明系统至少在 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% 权力要求的关系
一个 75% 的门槛在大多数情况下与证明系统最低 25% 权力要求相符，但当多签的规模较大时会出现例外：
14/20 多签 (70%) → 证明系统权力占比 25.93% ✅
135/200 多签 (67.5%) → 证明系统权力占比 25.56% ✅
对于感兴趣的读者，满足 ≥25% 证明系统权力要求的最低门槛是 2/3。
具体公式请参考附录部分
我们预计安全委员会的规模不会过于庞大，因此为简化起见，我们同意使用 75% 的门槛要求，同时牢记其背后的逻辑。
成员数量的计算
过去，我们要求安全委员会中至少有 50% 的成员来自组织外部，并且至少有 2 位外部成员需要达成共识。
这一要求的隐含问题是：如果只有 2 名外部成员，腐化他们即可推进恶意升级，而多签的规模大小对此没有影响。
最近的几个事件证明了这一点，例如 Multichain 团队与中国执法部门之间的事件，以及 Oasis 遭遇的法院命令。这些事件表明，同一组织或同一司法辖区内的人面临相同的法律风险，因此难以将他们视为独立实体。
我们的目标是建立一个成员多样化的安全委员会，能够抵御恶意活动、法律强制或其他外部影响。然而，通过客观标准实现这一目标非常具有挑战性，因为会遇到各种边界情况。
考虑到这些复杂性，成员多样性将通过主观评估进行衡量。建议让委员会成员代表不同的组织，这样可以降低单一实体内潜在内部共谋的风险。将成员分布在不同司法管辖区，有助于增强委员会应对局部法律行动或法规的能力。
风险分析：何时从阶段 0 过渡到阶段 1？
设计安全委员会时，需要考虑两种情况：
Rollup 存在漏洞：此时，安全委员会应快速升级系统，较低的门槛有助于提高解决问题的概率。
Rollup 正常运行：此时，安全委员会不应覆盖系统，较高的门槛可以降低这种情况的可能性。
多签的规模和门槛应反映系统和安全委员会本身的相关风险。以下是一个示例：
一个虚构的 Rollup 的安全委员会由 15 名成员组成，我们为特定场景分配理论概率：
10% 的概率至少有 4 名成员发生故障。
1% 的概率至少有 8 名成员发生故障。
0.1% 的概率至少有 12 名成员发生故障。
此外，我们假设证明系统有 20% 的概率发生故障。根据这些概率，如何确定最佳门槛？
假设门槛为 12，负面结果的概率计算如下：
0.1\%（12 名成员发生故障）+ 20\%（证明系统存在漏洞）\ times 10\%（4 名成员发生故障并阻止升级）≈ 2.1\%。
如果门槛降低为 8，负面结果的概率为：
0.1\%（12 名成员发生故障）+ 20\%（证明系统存在漏洞） \times 10\%（4 名成员发生故障并阻止升级） ≈ 2.1\%。
因此，门槛为 8 时的结果更好。随着对证明系统信心的提升，门槛应相应提高，最终达到阶段 1 的标准。
关于响应及时性的担忧
高门槛可能会引发对响应及时性的担忧，例如在需要快速推送升级以修复漏洞时，可能难以及时召集分布在不同时区的成员。
因此，可以考虑以下措施：
1.实施较低的门槛以暂停 L2，然后在必要时通过较高门槛覆盖。
2.定期进行突发应急演练，测试成员能否及时签署消息。
受影响的 Rollup：Arbitrum 案例
这一阶段 1 的新要求仅影响 Arbitrum。
Arbitrum 的安全委员会目前使用 9/12 的门槛，同时还存在一个较低的 7/12 门槛，允许在 13 天延迟后进行升级，为用户提供大约 6 天的退出窗口。
由于这一较低门槛未达到 75% 的要求，因此该机制无法被视为安全委员会，仍需遵循简单多签的标准，即为用户提供至少 7 天的退出窗口。
为了保留阶段 1 的状态，Arbitrum 必须完全移除较低门槛，或延长 L1、L2 或两者的时间锁延迟。
尽管 Arbitrum 当前技术上未满足阶段 1 的新要求，但我们将暂时保留其阶段 1 状态，并与 Offchain Labs 和 Arbitrum DAO 密切合作解决这些问题。如果这些更改未能及时实施，我们将重新将其归类为阶段 0。
附录：数学公式
证明系统在虚拟多签中的权力百分比可通过以下公式计算：
证明系统的虚拟票数(proof system virtual votes) = 阈值(threshold) - 需要阻止提案的人数(number of people needed to block a proposal)
阻止提案所需人数(number of people to block a proposal) = 大小(size) - 阈值(threshold)+ 1
等效 51% 多签规模(equivalent 51% multisig size) = 大小(size) + 证明系统虚拟投票(proof system virtual votes)
证明系统权力百分比(proof system power) = 证明系统虚拟投票(proof system virtual votes) / 等效51%多重签名大小(equivalent 51% multisig size)
如果您想尝试不同多签下的证明系统权力计算，可以使用一个简单的 Python 脚本。
｜加入我们
