从第 0 阶段到第 1 阶段：Rollup 治理中的安全委员会最佳实践

共同作者 Michael Lewellen 在一个去中心化治理系统中，一个结构良好的安全委员会是确保协议完整性和去中心化的下一步。它为预测、检测和响应关键安全事件提供了一个清晰的框架。基于 OpenZeppelin 在为 web3 领先项目领导安全委员会方面的经验，本指南详细介绍了如何组建和维护一个安全委员会，该委员会在快速紧急行动和去中心化责任之间取得平衡。通过改进治理程序、定义成员角色、确保强大的多重签名安排以及实践透明的事件响应，你的项目可以从基本治理结构（第 0 阶段）过渡到稳健的、运营成熟的阶段（第 1 阶段及更高阶段），正如 L2BEAT 的 Layer 2 Rollups 治理框架所提出的那样。最终目标是确保你的协议具有长期的信任、信誉和弹性。

你的去中心化项目是否正在探索创建安全委员会？请联系 sales@openzeppelin.com 与我们的一位专家联系。

1. 介绍

在一个去中心化治理系统中，底层协议的安全性不仅仅是一个技术问题，它是其他一切赖以生存的基础。如果没有强有力的保障措施，突然的漏洞利用或漏洞可能会迅速动摇信心，损害参与者，并破坏长期目标。通过建立一个专门负责保护协议关键要素的团队，从个人 DAO 成员到更广泛的生态系统，每个参与者都可以更安心，因为他们知道有一个明确的计划和知识渊博的专家随时待命，以确保系统安全运行。

本指南提供了一个框架，以帮助确保你的安全委员会做好充分准备，并与项目的更广泛的使命和价值观保持一致，并将你的项目从 L2BEAT 提出的治理控制框架中的第 0 阶段提升到第 1 阶段。本运营准备指南侧重于建立组织成熟度，定义明确的角色，并建立技术保障措施，以帮助长期保护协议。

2. 了解安全委员会

安全委员会作为一个专门的决策机构在去中心化治理框架内运作。其主要职责包括：

• 风险缓解： 识别并响应协议安全的紧急威胁。
• 应急响应： 在出现关键问题时，协调行动——例如暂停运营或实施紧急升级。
• 协议管理： 通过例行演练、密钥管理和持续审查治理参数来保持运营准备状态。

简而言之，安全委员会是防御漏洞利用、治理攻击和系统性故障的最后一道防线。就像在部署代码之前进行审计一样，在危机发生之前组建安全委员会可以确保必要的保护措施到位，以保持信任和稳定。

3. 最佳组建和时机

一旦协议达到一定成熟度，建立安全委员会就最有意义：

• 先决条件： 明确的治理结构、有据可查的运营标准以及在何时部署紧急措施的共识。
• 复杂性平衡： 过早组建委员会可能会引入不必要的开销；等待太久可能会在面对危机时没有建立完善的紧急框架。

随着协议的发展，委员会也应该发展。定期审查可确保成员资格、程序和阈值与新兴风险和社区期望保持一致。

4. 主要角色和职责

• 成员构成： 安全委员会成员必须将技术安全专业知识与对协议架构和治理模型的深入了解相结合。考虑将内部贡献者（核心开发人员、安全工程师）与经过审查的外部安全专业人员混合。寻找以下技能：
  • 技术安全专业知识： 智能合约审计、密码密钥管理、漏洞分析。
  • 危机管理经验： 熟悉沟通策略、事件分类和升级策略。
  • 法律和合规洞察力： 了解可能影响紧急行动的多司法管辖区监管约束。确保在单个司法管辖区内没有过多的签名者。

4.1 透明度和问责制： 成员的选择和轮换应通过透明的、社区驱动的流程进行。DAO 投票、公共提案和固定任期有助于确保没有单个实体可以巩固权力。

4.2 成员期望和 SLA： 设置明确的服务级别协议 (SLA)，以便成员了解他们的职责：

• 应急响应： 例如，承诺在检测到严重漏洞利用后的 30 分钟内暂停协议。
• 升级监督： 在预定义的时间范围内（例如，48 小时）审查并批准提议的修复。
• 定期演练： 以定义的间隔参与演练，以保持准备状态。

5. 多重签名设置和托管

多重签名钱包是委员会技术能力的核心。这种机制确保没有单个成员可以单方面损害系统。相反，关键行动——暂停、取消暂停或推动紧急升级——需要多个签名者之间的广泛共识。

5.1 配置和阈值：

• EOA 模型： 单个委员会成员可以为其签名帐户维护一个 EOA。
• Safe-of-Safes 模型： 由组织代表的委员会成员可以维护自己的多重签名，从而降低单个密钥泄露的风险，并允许他们与多个待命成员执行内部密钥轮换。
• 分层操作： 为不同的操作设置不同的签名阈值——例如，简单多数暂停，更高的阈值用于协议升级。

5.2 托管最佳实践：

• 硬件钱包： 将密钥存储在信誉良好的设备上，以最大限度地减少暴露。
• 不要随意备份： 避免不必要的助记词副本。
• 专用帐户： 仅将签名密钥用于委员会操作，从而降低外部污染的风险。

5.3 实际示例

• LivenessGuard Safe 模块： 安全委员会机制的一个值得注意的参考点是 Optimism 实施的 LivenessGuard Safe 模块。LivenessGuard Safe 模块（由 Optimism 与 Gnosis Safe 一起使用）通过允许删除不活跃的安全委员会成员，同时自动保留 75% 的批准阈值来防止治理僵局。这确保了即使成员变得无响应，委员会仍然可以正常运作，而不会降低安全要求。
• 暂停守护者机制： 在 Compound 等协议中看到的另一种实用方法是“暂停守护者”的概念。如果发现漏洞，指定的角色或小型多重签名组可以快速停止特定的协议功能，而不是等待完整的委员会投票或时间锁。

5.4 特定密钥轮换策略：

如果一个密钥在无人知晓的情况下被泄露，定期轮换密钥可以降低长期风险。

• 定期轮换周期：例如，每年三到四次——确保最小的干扰。
• 紧急轮换：定义触发器（例如，疑似黑客攻击或设备泄露）并快速执行程序以更换泄露的签名者。

6. 事件响应协议和最佳实践

即使有监控工具和保障措施，在危机期间，人为判断和协调行动仍然至关重要。委员会必须有一个清晰的事件响应协议，以指导决策和沟通。并非所有威胁都遵循可预测的模式。当出现自动检测无法捕捉到的异常情况时，委员会需要一个结构化的方法来手动暂停协议。透明的决策渠道和升级策略确保快速、一致的响应。

6.1 自动暂停与手动暂停：

• 自动触发： 集成监控工具，可以在检测到已知威胁模式时暂停协议，可能需要稍后由委员会确认。

• 手动干预： 对于自动系统未捕获的异常，请遵循结构化的决策树：

  • 检测
  • 评估严重程度
  • 必要时暂停
  • 沟通

6.2 紧急升级： 对于严重的漏洞，协调完整的安全升级过程：

• 独立审查： 寻求对提议的修复进行审计或外部验证。
• 签署人法定人数： 收集所需数量的签名（例如，N 中有 5 个）以实施更改。
• 时间延迟执行： 考虑对高影响力的升级使用时间锁，以确保社区监督，如果该漏洞无法立即利用。

6.3 定义紧急行动的范围：

建立安全委员会最关键的部分之一是明确说明什么是被认为是“紧急情况”，什么不是。为什么定义范围很重要：

• 防止范围蔓延：如果没有明确定义的范围，委员会可能会被拉入每一个主要的 DeFi 黑客攻击事件，即使你的协议没有直接受到影响，也会削弱其重点和资源。
• 透明度和社区信任：社区需要清楚地了解委员会何时以及为何可以干预，这样它才不会显得在武断行事。
• 高效的决策：明确的指南可以减少危机期间的犹豫，并简化“这是否是紧急情况？”的讨论。

以下是你可能定义的说明性类别

6.4 紧急情况下的沟通策略：

即使你拥有强大的技术保障措施，沟通不畅也可能导致混乱或恐慌。以下是一些围绕沟通需要考虑的重要事项的示例：

• 快速通知：谁先收到通知（开发人员、委员会、更广泛的 DAO）以及如何通知（Discord、链上警报、Twitter、论坛公告等）。
• 单一的信息来源：在危机期间，指定一个规范的位置来获取官方更新（例如，专门的论坛帖子或公告频道）。
• 公共与私有细节：概述你立即披露哪些信息（例如，“我们已暂停协议；资金安全”），以及稍后可能共享的敏感细节（例如，攻击者的策略、补丁细节）。

6.5 事后审查和透明度报告：

公开记录事件的处理方式以及从中吸取的教训可以建立信任。它可以包括以下内容：

• 事件验尸报告：漏洞利用或事件的摘要、响应时间表以及根本原因。
• 纠正措施：已实施的任何代码更改、额外审计或治理更新。
• 委员会绩效评估：安全委员会是否及时响应？是否需要调整阈值或流程？

7. 成员旅行政策

人身安全和可用性会影响响应准备情况。围绕成员旅行、参加会议和相关活动的政策有助于最大限度地降低密钥泄露或不可用的风险。

8. 治理集成

安全委员会不应孤立运作。相反，它必须与更广泛的治理架构无缝衔接——遵守已建立的 DAO 流程、尊重社区驱动的检查以及与协议增长同步发展。本节概述了安全委员会可以与链上治理有效集成，同时保持紧急情况准备就绪的几种方式。

8.1 确保与 DAO 治理保持一致

• 升级路径： 定义将事项升级到 DAO 的精确条件。这可以防止安全委员会行使不受制约的权力。
• 定期参数审查： 安排对关键治理参数的审查。这样做可以确保安全委员会的权力与不断变化的风险和社区期望保持比例。

8.2 协调的跨协议协作

• 生态系统“作战室”： 许多 DeFi 漏洞利用是多管齐下的，并且可能会蔓延到邻近的协议中。与其他领先团队建立非正式或正式的“作战室”可以快速共享威胁情报并协调缓解措施。

示例：2023 年 Compound Oracle 攻击模拟

• 攻击：SEAL Chaos Team 模拟了一个恶意预言机将 WETH 价格抬高 28%，从而有可能从 Compound 的 Comet 池中抽取 65 万美元的 USDC。
• 检测：OpenZeppelin 的 Defender 和 Forta 机器人标记了价格偏差（>相对于 Uniswap 锚点 > 15%）和可疑的提款模式。
• 响应：分配了角色（运营主管 = OpenZeppelin，事件指挥官 = Compound Labs）；WETH 市场通过多重签名暂停。暂停后分析评估了清算风险并起草了公共沟通。
• 工具：OpenZeppelin Defender 自动化了警报/暂停；SEAL 的演练模板 提供了模拟脚手架。
• 共享监控和警报： 考虑与其他项目合并资源，以资助生态系统范围内的审计和监控计划。中心化报告仪表板、跨协议 Slack/Discord 频道或核心安全工程师之间的信任网络可以显着缩短响应时间。
• 社区信任： 通过与其他协议积极协调，你证明安全委员会既具有协作性又具有透明性——从而增强整个生态系统（而不仅仅是你自己的协议）中用户的信心。

9. 准备演练和维护

正如经过良好测试和审计的代码更安全一样，经过良好排练的安全委员会也更具弹性。计划好的演练使成员熟悉紧急协议，而未宣布的激活测试则衡量委员会在压力下的实时响应能力。公开分享：

9.1 公开分享委员会组成和期望

• 成员身份（在适当的情况下），包括每个成员的钱包地址

• 如何选择成员的选择标准

• 每个成员的任期

• 投票门槛（例如，决策通过需要什么百分比或绝对多数）

• 响应时间 SLA（服务级别协议）表明在紧急情况下预计成员投票或响应的速度

9.2 高级程序

事件响应框架和升级过程的概述。

9.3 （私有）机密记录

维护演练、事件结果和决策理由的详细、私有日志，以供内部审计和未来改进。 结论

建立安全委员会不仅仅是选择密钥持有人。它是关于创建一个运营基础，使他们能够在威胁出现时采取明智的行动。通过仔细考虑成员资格、多重签名配置、事件响应协议、旅行政策、准备演练和治理整合——然后记录这些实践并与利益相关者分享正确的信息——你将创建一个可以经受时间考验的框架。

虽然没有单一指南可以保证抵御每一个安全挑战，但此处概述的实践将大大提高你的项目保护用户和保持长期信誉的能力。正如全面的审计准备过程将项目置于安全部署的道路上一样，彻底的安全委员会运营准备计划有助于确保在发生意外情况时，团队已准备好迎接挑战。

如对 OpenZeppelin 参与你的安全委员会事宜有任何疑问，请联系 sales@openzeppelin.com

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