为什么 Rollup 都需要安全委员会？

多重签名不是 Rollup 的全部，但它是更大系统架构中重要的一小部分。

撰文：PATRICK MCCORRY
编译：Luffy，Foresight News

任何与加密资产交互的数据库终有一天都会选择 Rollup 作为技术堆栈。开发人员做出这样的决定是有很多充分理由的：

• 实时审计

• 默认偿付能力证明

• 用户资金的托管是可选的

• 诚实的一方参与者可以保护整个系统

最重要的是，Rollup 的所有设计和实现工作都集中于保护用户、他们的资金以及他们的所有交互，免受潜在未知且强大的系统操作员的侵害。

即使整个系统离线，用户也可以凭一己之力收回资金。

如果 Rollup 能够作为技术堆栈得到广泛部署，那么我们可能有能力打破信任壁垒，使全球社区中的任何人都能进行财务互动，从而进入全球电子商务、远程招聘和无摩擦提供服务的新时代。

要使 Rollup 正确执行，确实需要付出很多努力。

多重签名怎么样？

这听起来不错，但整个系统最终由多重签名控制。如果签名者受到损害或萌生恶意，那么他们可以轻而易举地窃取所有资金。

那么，谁会关心 Rollup 呢？CT 上的某个地方。

确实，当前所有 Rollup 都具有多重签名，有权升级底层智能合约，但正如我们将看到的，它是一种保护用户资金的保守主义机制，并且是更广泛的系统架构的一部分。

安全委员会的责任

多重签名是一个技术术语，指的是需要多个签名者授权某项操作的系统。例如，N 个签名者中的 K 个完成数字签名，交易才会被允许。

在 Rollup 的背景下，多重签名通常被称为安全委员会，签名者被赋予升级所有相关智能合约的权力。

让我们看一下 Arbitrum 中的安全委员会（因为我对它非常熟悉），以了解这个组织可能承担的职责类型：

• 否决权。 如果安全委员会认为 Arbitrum DAO 通过的提案违反了 Arbitrum 章程并可能损害 Arbitrum 生态系统，则可以取消该提案。例如，取消因受到治理攻击而通过的提案。

• 维护。 升级 Arbitrum 智能合约套件以进行细微更改，这些更改影响较小，不需要 Arbitrum DAO 参与进来。

• 紧急事件。 在紧急情况下迅速响应，如果他们认为用户资金面临迫在眉睫的风险，则可以紧急升级智能合约。

当然，最重要的是，安全委员会的首要职责是应对紧急事件并迅速采取行动保护用户资金。

安全委员会的成员需要非常值得信赖的人员来担任。

人们相信签名者能够迅速做出反应，在紧急情况发生时能够升级智能合约，并相信他们会尽最大努力保护智能合约中的资金安全。

选择正确的多重签名阈值

在决定设立安全委员会时，需要考虑两个重要因素：

• 一共有多少签名者？

• 至少需要多少签名者才能批准一项行动？

这看似是一个微不足道的问题，毕竟它只是两个数字，但必须考虑一个平衡行为：

• 安全违规： K 个成员可能串通更改智能合约并窃取用户资金。

• 活性违规：N-K+1 成员串通阻止对智能合约进行任何更改，如果发现严重漏洞，问题尤其严重。

难处在于确定一个阈值，既能在和平时期维护资金安全，又能在紧急情况下当用户资金受到威胁时迅速采取行动。

让我们考虑一个具体的例子。假设阈值设置为 9/10，其中 9 个签名者必须共同签署一条消息。这是一个严苛的安全阈值，因为必须 9 个签名者合谋才能窃取资金。然而，缺点是任何两个签名者都可以阻止紧急情况下的任何行动。例如，如果两名签署者乘坐跨大西洋航班远游，则安全委员会将无法履行其职责。

当然，如果安全阈值较低，假设为 2/10，那么只需任意两个签名者串通（或私钥被泄露），用户资金就会被盗。

选择适当的阈值更多的是一个社会问题，而不是一个技术问题，我认为这更多的是一门艺术而不是一门科学。安全性很大程度上取决于个人签名者的诚信度。正如我们很快就会看到的，有一些方法可以减少对多重签名的信任，但这会带来一系列权衡。

安全委员会成员

大多数 Rollup 在其安全委员会中都有一组匿名签名者。我们怀疑这可能是由于：

• Rollup 的发展阶段，

• 保护成员人身安全，

• 认为匿名是保护用户资金的最佳选择。

另一方面，有三个 Rollup 项目公开宣布了其安全委员会成员身份：

• Arbitrum：签名者由公开选举产生，当前名单可在 Tally 上查看。只有三名签署者与 Arbitrum 项目相关（两名来自 Offchain Labs，一名来自 Arbitrum 基金会）。

• Base：2/2 多重签名，一个由 Base 控制，另一个由 Optimism 控制。

• Polygon zkEVM：尚未实施，但他们已宣布会将其多重签名升级至 10/13，其中包括来自 Polygon Labs 的两名成员以及 Polygon Labs 的一名顾问。

• zkSync Lite：zkSync Lite 应该与 ZkSync Era 区别开，其安全委员会是公开宣布的，并且不包括来自 Rollup 项目的直接附属机构（zkSync 的投资者除外） 。

在 Arbitrum 中以及在即将到来的 Polygon 中，只有少数签名者与 Rollup 项目直接相关，而且数量足够小以确保附属机构不能串通阻止安全委员会采取的行动。在 zkSync Lite 中，除了 zkSync 的投资者之外，他们还任命了独立于项目的签名者。

在所有情况下，Rollup 都非常重视与项目没有直接关系的签名者。

然而，对于如何构成良好的多重签名似乎缺乏共识，这给我们带来了几个设计问题：

• 是否应该允许匿名成员？

• 成员应该来自不同的地域吗？

• 成员应该是个人还是公司？

• 成员应该由任命还是选举产生？

• 应允许多少名来自同一公司（或国家）的成员？

• 是否存在被认为合适的最小规模和阈值？

一般经验法则应该是挑选高度诚信的成员，以便公众对系统的安全充满信心。至少，我相信大多数项目可能都会这样做，即使这并不总是可以公开验证。

附注 Arbitrum 安全委员会的六名成员目前已被预先任命，但他们将在三月份的选举中被替换。

削弱委员会的权力

到目前为止，我们只考虑了一个有权立即升级智能合约的委员会，但有一些方法可以限制委员会的权力：

时间延迟（Time delay）。委员会授权的所有操作只有在时间 T 过去后才会被执行并生效。

仅暂停（Pause-only）。 原生跨链桥持有的所有资产都可以被委员会冻结。这可能会暂停以下功能：

• 将消息从 L2 传递到 L1（即取款），

• 完成待处理交易的排序，

• 完成新的检查点 / 证书，

• 接受新的 Rollup 数据（即待处理的事务）。

绕过委员会（Removed）。 放弃委员会并依靠另一种治理机制（如 DAO）来批准升级。

当然，这会限制委员会迅速采取行动的能力以及他们能否有效应对威胁用户资金的紧急事件。

如果漏洞已私下向委员会披露，但尚未被黑客利用，则安委员会可以选择升级智能合约并修复错误。在升级中加入时间延迟，会增加攻击者研究公开披露的升级、找到漏洞然后利用它的风险。

例如，比特币中的 CVE-2018-17144 最初被宣传为 DDoS 漏洞，而试图隐藏更严重的代币通胀漏洞。升级速度对于防止其被利用至关重要。

评估仅暂停机制的防御能力

让我们考虑一下攻击者主动利用漏洞的潜在场景：

• 恶意 L2 → L1 消息。 攻击者可以制作源自 Rollup 上的智能合约的任意消息，并通过原生跨链桥将消息转发到以太坊上的智能合约。

• 无效的状态转换。 攻击者可以在 Rollup 上执行违反状态转换函数规则的交易，通常应将其视为无效。

• 提款漏洞。攻击者只需在以太坊（第 1 层）上发出交易即可从原生跨链桥提取资金。

在这三种情况下，时间延迟只会让攻击者有更多时间继续窃取资金，并减少委员会保卫系统的机会窗口。延时功能无法防御主动攻击，只能用于日常维护和不紧急的任务。

我们只会评估暂停系统的能力以及系统可以暂停的程度。

在恶意 L2 → L1 消息的情况下，暂停功能可以减轻攻击而不干扰交易活动。委员会应暂停消息传递和 / 或最终确定新检查点的功能。有一种观点认为，L2 → L1 消息在执行之前应该有一个时间延迟，以便委员会有时间检测错误并对紧急事件做出反应。

防御无效状态转换更加棘手，因为交易最终性在 Rollup 中具有不同的层。 如果我们只考虑 Rollup 交易而不考虑任何副作用，那么安全委员会的最佳防御就是停止检查点最终确定的能力，但继续允许交易排序。这可以留出时间来修复错误、重新激活检查点完成以及简单地忽略无效交易。

然而，如果不关闭 Rollup 上的交易活动，那么用户体验将会很混乱，并且 Rollup 可能会出现被严重破坏的状态，直到客户端软件升级为止。

这将我们带入下一个场景。如果我们考虑 Rollup 上的无效交易可能如何影响其他系统，委员会应该如何反应。最好的防线是冻结原生跨链桥最终确定交易排序的能力，或者完全关闭排序器。

这是因为某些系统，例如将资金从一个 Rollup 转移到另一个 Rollup 的快速跨链桥，一旦它们认为 Rollup 的交易（包括无效交易）被排序，就可能会授权资金转移。在这个例子中，它可能允许攻击者利用 Rollup 上的 DeFi 协议，然后通过快速跨链桥将其转移到另一个 Rollup 来快速转移资金。

当委员会修复漏洞并恢复无效交易时，损害可能已经造成。无论是 DeFi 协议还是跨链桥中的 LP 都可能承担攻击带来的损失。

最后，如果该漏洞允许攻击者直接从原生跨链桥提取资金，类似于 Nomad Hack，则安全委员会可能无力阻止。

暂停机制存在一个最终的总体问题。我们必须假设有一个更广泛的治理系统可以批准升级并重新激活 Rollup。如果我们假设治理系统是一个带有在 Rollup 上运行的链上投票系统的 DAO，那么就会出现棘手的实施问题。

例如，如果 L2→L1 消息跨链桥暂停，则 DAO 的投票结果无法从 Rollup 传递到以太坊上的原生跨链桥，必须存在一种 DAO 发送批准信息并执行升级的替代方法。

逐步取消安全委员会

社区中有些人认为应该逐步取消安全委员会，但在我看来，这会带来两个问题：

错误的安全感。 了解漏洞利用的攻击者会等到安全委员会逐步淘汰后再执行攻击。随着时间的推移，这会削弱我们对系统安全性的信心。

恢复选项有限。 如果没有安全委员会，社区就无法反击攻击者。唯一可用的选择是进行并行的白帽黑客攻击，并希望夺回部分资金。

我认为，安全委员会永远是必要的，但赋予它们的权力应该逐渐缩减。

考虑到这一点，设计问题应该是：

我们如何才能让安全委员会在对用户影响最小的情况下暂停系统，同时允许更广泛的社区参与决定如何修复错误并重新激活系统？

换句话说，我们需要一个真正允许社区介入并恢复系统的方案，然后再限制安全委员会的暂停权力。

在 Layer 1 区块链领域，社区确实可以通过使用用户激活的分叉来直接达成，但这种方法不适用于以太坊上的智能合约（如 Rollup），因为无需分叉整个以太坊。在某些情况下，以太坊社区可能会集体决定保存 Rollup，就像 2016 年的 TheDAO，但 Rollup 永远不应该依赖或期望这样一个结果。

沿着这些思路的另一个有趣的想法是实现以太坊最高法院来决定智能合约升级并启用类似于用户激活的分叉。

如前所述，如果 Rollup 将其安全性委托给 DAO，那么应该有一个实现允许 DAO 直接在以太坊上投票。这是非常棘手的，特别是如果投票协议存在于 Rollup 中。

最后一点，我认为要对可能需要安理会做出反应的情况类型进行全面审查，以帮助围绕其必要性的讨论。

如果有了多重签名，为什么还要担心 Rollup？

我们花了相当多的时间来理解安全委员会的责任、设计和需求，但重要的是回到本文最初的问题：

Rollup 只是多重签名吗？

答案是不。

为了帮助理解为什么，最好退一步并理解区块链系统真正想要做什么。

区块链协议是一种工具，允许用户计算数据库的副本，并确信他们拥有与其他人相同的数据库。

考虑到这一点，任何区块链系统都有两个组件：

• 区块链协议。 软件、密码学和分布式系统的组合，使任何人都对数据库的完整性充满信心。

• 治理系统。 一种协调机制，允许所有利益相关方共同努力并同意更改区块链协议。

任何区块链系统（包括 Rollup）的目标都是确保区块链协议始终以 99.9999% 的极其可靠的正常运行时间运行。 受信任的系统运营商对系统的日常运行应该几乎没有干扰。 最终负责保护用户余额、智能合约代码和状态的应该是软件、密码学和分布式系统。

有时需要更改区块链协议以改善用户的利益。社区可能想要修复配置问题、添加新功能或对威胁系统完整性的关键漏洞做出反应。这需要人工干预，并且只能在 0.0001% 的时间内被调用。

治理系统负责实现人为干预，多年来已经出现了几种方法：

• 集权政党：单方可以单独决定如何升级系统（包括比特币在内的许多项目都是以这种方式开始的）。

• 粗略共识：大多数参与者表示他们已准备好部署升级，确定标记日，然后在标记日执行升级 （比特币 / 以太坊）。

• 投票协议：各方参与选举并明确投票决定是否批准升级。

• 无法干涉：智能合约可以是不可变的，系统永远无法更改。

除上述内容外，社区还可以决定任命一个安全委员会作为治理的补充选项，以在紧急情况中迅速采取行动。

安全委员会不阻止攻击。 这是一种被动机制，当区块链协议的用户资金或系统可靠性 / 性能的受到攻击时，它与治理一起发挥作用。

最后

所有围绕区块链协议、治理和安全委员会的讨论都至关重要。这种讨论的存在使得加密货币如此特别。

这是信任工程的一个很好的例子：专注于识别、测量和减少 / 消除系统中信任元素的工程学科。

在加密货币中，我们专注于构建不仅能够保护用户免受强大的系统运营商侵害的系统，而且能够使系统在最不利的条件下可靠（安全）地运行。

这就是为什么社区成员对安全委员会的作用保持怀疑是健康的，但他们有责任在紧急事件期间提出更好的解决方案，以被动的方式保护用户资金。

我希望这篇文章能够清楚地说明为什么安全委员会有用，它们在今天是必要的，但也只是智能合约系统更广泛架构的一小部分。

If you find submirror valuable, please consider donate to wong2.eth to help cover server cost.