多签的正确使用方式

如何实施多签安全最佳实践以防止你的协议被攻击。

请将这视为你保护多签的终极指南，我们汇集了多位专家的知识，帮助协议团队安心，确保他们在攻击发生之前采取了最佳流程来防止利用。

引言

多签通常是可以与协议的合约交互的最强大账户，正如俗话所说：“力量越大，责任越大”。

然而，直到现在，如何以最好的方式管理这份责任一直不明确。几个签名者是安全的吗？你如何管理多签权限？你是否使用时间锁？

我们将在这篇文章中回答所有这些问题，以及更多来自专注于多签安全的网络2和网络3领域的安全研究人员的见解。

然后，我们将把这些答案汇总成最佳实践，使用Gnosis Safe、RolesAuthority合约和Timelock合约，帮助协议团队简化操作而不妨碍安全性。

首先，我们将对协议团队需要采取的每个行动的风险进行分类，建立一个框架，帮助我们思考多签并可以为其添加不同的安全机制。

风险类别

风险类别是我们用来考虑协议团队需要采取的不同行动的框架。然后我们可以针对每个行动应用不同的程序，以确保最大安全性，同时仍让团队完成工作。

我们可以将多签行动大致分为三个不同的风险类别：

• 低 - 例如为协议操作捐赠 gas/ETH

• 中 - 例如更改系统配置，部署新合约（可通过 MEV 利用）

• 高 - 例如合约升级、资金转移、所有权变更

我们可以将这些类别链接至每个行动所需的签名者数量，其中高风险类别的行动需要更多的签名者。这有助于降低因签名者被攻破或联合而导致的恶意接管的机会。

接下来，我们将看到与风险类别相对应的多签门槛如何帮助我们避免这些恶意接管。然后，我们将讨论根据风险类别添加时间锁作为额外安全层。

门槛

在许多项目使用的 Safe 多签中，门槛设置了需要多少个签名者来批准一项交易。多签只有在满足门槛时才能执行该交易。

签名者的门槛是确定多签安全性的第一步，因为它隐含地决定了冒险程度。

例如，在一个 ⅗ 多签中，进行任何操作需要 3 个签名者。从另一个角度来看，我们看到只有 3 个签名者需要合谋或其私钥被攻破就能完全控制多签。在最坏的情况下，如果这是唯一的多签账户用于管理操作，那么这 3 个签名者可以完全毁掉该协议。

在这种情况下，只有一个多签能够执行所有操作，它会默认被分配到最高风险类别，因此需要一个高门槛。

如果我们有多个多签，可以将门槛与每个多签可以采取的行动的风险类别关联。相对低风险的操作后续需要更低的门槛，而高风险的操作则需要更高的门槛。

我们的建议是，对于中高风险操作，争取达到 70% 的门槛共识。

添加一个外部层，例如安全公司，也可以增强安全性。它们提供公正的监督，并帮助降低风险。一个 5/7 的多签设置与一个外部层达到 70% 的门槛，同时增加了一层额外的保护。

签名者协调风险

多签固有地为签名过程增加了时间因素，因为它们要求多个人之间协调，通常跨越不同的时区。这往往意味着多签对紧急事件的反应较慢。但根据定义，这些事件需要快速行动，以减少潜在的损害。

专用工具，如@go_su_to开发的Safe Panic Modules，可以添加到 Safe 多签中。这个工具帮助团队在紧急情况下迅速行动。通过它，单个多签签名者可以采取行动，比如在集成协议中撤销路由器或受信合约的批准，或者撤出资金。

isSigner 修饰符允许多签签名者在紧急情况下采取保护协议的预先批准行动。

对于像Euler对某一事件有前期认识的攻击，这将允许集成协议的单个签名者在Euler团队暂停合约之前撤出资金，或者在资金被完全盗取之前采取行动。

这加快了对坏事件的反应，同时通过防止单个签名者采取只有多签才能执行的行动来保持多签的安全性。

然而，签名者的门槛只是我们分层安全的一部分。下一层是通过时间锁更明确地为多签增加时间元素。

时间锁

时间锁延迟一个地址所采取的行动的执行，直到未来的预定时间。在协议操作的背景下，发起行动的地址是多签。

调度行动和其执行之间的延迟有助于协议团队。它给他们额外的时间来检查该行动是否正确。例如，如果协议升级有足够的时间锁，团队可以让外部安全团队检查有效负载及其影响。这帮助他们在时间锁结束时看到升级是否按计划工作。

此外，时间锁还给予协议用户在任何潜在更改生效之前选择退出的能力。

时间锁还为用户增加了 protections，如果多签被攻破，用户可以在攻击者执行恶意行动之前有时间退出。

一个常用的时间锁实现是来自 OpenZeppelin 的 TimelockController：

schedule 和 execute 函数允许调度管理操作，并在延迟结束后执行它。

该合约允许设置多签作为提议者，使用 PROPOSER_ROLE。多签可以调度对协议合约中的管理功能的调用。它通过将所需参数传递给 schedule 函数实现。一旦延迟结束，拥有 EXECUTOR_ROLE 的签名者之一可以调用 execute 函数。

execute 的调用较不敏感，因为它只运行已经获得多签签名者批准的有效负载。然而，将 EXECUTOR_ROLE 分配给这些签名者有助于防止在多个有效负载排队时出现的问题。任何人都可以通过无权限的功能以错误的顺序执行有效负载。这可能导致意想不到的副作用。

时间锁通过引入一个时间因素来增强安全性。但是，我们如何将其与多签结合使用？我们希望保持高安全性，同时不造成不必要的操作延迟。

多重多签方法

幸运的是，你可以通过使用多个多签选择任何所需的门槛/时间锁组合！这使你能够在任何操作上平衡风险、速度和安全性。

你可以为上述风险类别设置多个多签，如下所示：

• 低 - 低门槛和短时间锁

• 中 - 高门槛（>=70%）和短时间锁

• 高 - 高门槛（>=70%）和长时间锁

请注意，这些只是示例，你项目的风险安全配置会有所不同，选择自己的参数时应予以考虑。

这提高了协议团队的效率。它减少了签名者的等待时间，限制了对小型操作的延误。与此同时，它确保了对更重要行动的强有力保护。

管理多签

在多个多签的情况下，挑战在于管理权限。每个多签必须拥有执行其任务的正确访问权限。

通过与各种协议的合作，我们发现，最有效的方法是Maker最初使用的方法，现在被Badger DAO和Corn团队所采纳。该方法采用[RolesAuthority](https://etherscan.io/address/0xe5E99eD2764cB90017f95Dd5db8b1fb20f6B24FE#code#F4#L1)合约（另一个例子是由Balancer DAO治理使用的AuthorizerAdaptor合约）。它区分了哪个多签可以访问特定的治理功能。

RolesAuthority是基于角色的，这些角色决定了调用地址可以在给定合约上调用的函数签名。这个角色首先通过setRoleCapability函数字段设置：

角色是分配给多签地址的编号。它决定了它们可以在目标合约上调用哪些函数签名。

然后setUserRole函数允许我们将上述创建的角色之一分配给特定的多签/时间锁地址：

这将之前创建的角色设置为用户地址（多签/时间锁）。

这一方法的一个好处是你只需部署一次 RolesAuthority 合约。这将多签权限集中在一个地方，而不是在你系统中的所有合约中分散。

例如，如果你的系统使用多个 ERC4626 金库，你无需为每个多签单独设置权限。相反，你只需在部署金库时设置一次。使用 setUserRole 函数，然后你就可以忘记它。

拥有一个合约作为真理源还可以让你查询哪些多签可以访问给定合约上的哪些功能。你可以使用 doesUserHaveRole 和 doesRoleHaveCapability 函数查看你已部署合约中的所有权限。

这为我们提供了一种以编程方式为我们设置的每个多签 + 时间锁配置访问控制的方法。

RolesAuthority 合约允许由 Auth 合约授权的任何地址设置角色能力和用户角色。但是，它缺乏对不同地址作为特定能力或用户角色的管理员的微调。在你的系统中使用 RolesAuthority 合约时，请确保考虑到这一点。

综合总结

我们现在有三个关键组件：Gnosis Safes、RolesAuthority 合约和 TimelockController 合约。我们可以将它们结合起来，为协议中的每个操作创建一个量身定制的治理流程，我们在以下图表中进行了可视化：

我们推荐的多签设置架构。

从下到上，我们看到系统的核心是 Gnosis Safe 多签。我们为多签添加以下所有者保护：

checkTransaction 函数检查发送者是否为正在使用的 Safe 的所有者。

这个保护可以阻止任何达到其签名者门槛的排队交易被任何非多签签名者执行。

这保护我们免受攻击者钓鱼签名者以获取其签名的攻击。一旦获得这些签名，攻击者就可以在没有所有者保护的情况下执行恶意有效负载。有了所有者保护，攻击者还必须获取额外的签名以调用 execute 函数。这个步骤不太可能完成，并且很可能会提醒签名者注意恶意活动。

然后，我们为每个多签添加一个时间锁，相关于其风险类别。然而，仅凭时间锁并不能确保太多，除此之外只是延迟了有效负载的最终执行。当一个撤销者角色被分配给一个不是多签签名者的签名者时，时间锁最为有用。这个设置允许撤销者阻止恶意有效负载的执行。

拥有 CANCELLER_ROLE 的地址可以取消任何待决的时间锁交易。这可以阻止有害有效负载的实施。

在这种设置的最坏情况下，如果撤销者的私钥被攻破，撤销者仍可以防止新的提案生成。撤销者还可以阻止在调度但后续验证为错误的有效负载被执行。

最后一部分是管理多个时间锁。我们在之前提到的 RolesAuthority 合约。这允许在一个地方查看你系统中所有多签的权限。

这一设置使管理多签安全资源变得更加简单。然而，还有其他与多签组织不直接相关的因素，也应该考虑到以确保安全的操作环境。

其他考虑

受信任的有效负载

在 Safe 多签中签名有效负载时，签名的有效负载是由一个签名者在链下生成的。这使得对这个签名者的信任度很高。他们需要准确创建有效负载，否则可能对协议产生负面影响。

由 @go_su_to 为 Balancer DAO 开发的这个工具在通过 Safe 前端上传之前验证有效负载数据是否为 JSON。它在 CICD 管道中包括额外检查。这些检查确保编码并上传到 Safe UI 的信息符合预期的提案要求。这个过程帮助防止其他签名者无意中批准的有效负载中的错误。

有权限的执行

使用如Kleidi之类的工具，你可以对时间锁添加更细粒度的控制。

例如，你可以批准一个签名者进行再平衡操作。这意味着他们可以即时从一个预批准合约中提取资金，并存入另一个预批准合约。然而，他们不能进行其他操作。你在初始设置期间设置了这两个合约进行再平衡，以防止提取到随机合约。如果签名者的私钥被攻破，攻击者只能在两个批准的位置之间转移资金。

通过这种精确性，协议团队可以平衡效率和安全性。他们可以无需不必要的延迟完成低风险的维护操作。

治理模糊测试

Recon提供了我们称之为治理模糊测试的服务。这使你可以在更改时使用分叉链状态测试协议不变性。你将确切知道更改后系统将如何运行。

你可以使用此方法验证任何协议更改。这包括通过桥接接收外部消息触发的更改，这就是我们为Corn团队所做的。Corn是一个允许你在DeFi中使用比特币的Layer2。

他们的系统通过 LayerZero 进行跨链消息传递，在 Corn 和以太坊主网之间发送和交换代币。通过分叉模糊测试测试两个链之间的交互是具有挑战性的，因为你无法同时分叉两个链环境，但通过治理模糊测试，我们可以模拟此情况。

治理模糊测试使我们能够监听 Corn 上与桥接相关的事件。然后，我们可以在以太坊主网上触发分叉模糊作业。在发生跨链行动之前先测试现有不变性与预计会在主网发生的更改。

target_doGovFuzzing 函数执行对 LayerZero 端点的调用，将来自 Corn 事件的数据作为有效负载。endpoint_lzCompose 函数随后由模糊测试工具随机调用，以预览该事件在主网上的影响。

对于治理更改，我们使用类似的方法。这使我们能够监听来自多签或时间锁的更新，其结果我们可以在它们发生之前在系统中预览。然后，我们在分叉链状态上使用模糊测试检查不变性。这帮助我们查看升级是否会破坏任何不变性。如果是，我们可以使用前面提到的撤销者角色阻止任何意外行为。

良好实践

协议多签的成员还应确保落实以下良好实践：

• 所有签名者必须使用硬件钱包。

• 推荐型号：Ledger Nano S Plus、Trezor Model One、Trezor Safe 3（避免使用因电池问题的 Ledger Nano X）。

• 所有多签签名者应通过限制和加密的通信渠道（signal/telegram）进行协调。

• 所有多签签名者必须拥有4个硬件钱包（2个用于签名 + 2个备份）。

• 实施密钥轮换系统（例如每2年）。

• 高风险有效负载的签名者必须仅使用他们的硬件钱包进行这些多签交易。

结论

我们已经看到如何根据风险对不同的治理操作进行分类。这些风险类别帮助我们更好地应用像门槛和时间锁这样的工具。最终，这导致了针对操作风险的独特签名方案。

使用我们定义的类别，我们看到更高风险操作需要更多签名者和更长时间锁。相比之下，较低风险操作则需要更少的签名者和更短时间锁。然而，这可能会根据协议治理团队正在处理的特定操作而变化。

通过使用多个多签来管理这些风险，我们看到如何使用 RolesAuthority 合约管理多签。该合约允许我们为特定多签实施权限，以使用其可以使用的合约函数。

接着，我们讨论了一些与多签设置不直接相关的多签安全方面，即有效负载形成、指定操作和私钥安全性：

• 建立审查流程并限制有效负载执行者为签名者有助于防止意外或恶意有效负载的批准。

• Kleidi 对团队帮助分配低风险任务，如再平衡。这样可以加快维护任务，同时保持安全。

• 私钥的推荐实践有助于防止外部威胁。

实施这些最佳实践有助于防止你的协议成为另一个统计数字。不过如果你感到不知所措，请联系我们。我们会帮助你开始！

贡献者

这篇文章之所以能够实现，是因为其他研究人员在这些主题上付出了大量的时间和努力。这些研究人员最近与 Recon 举办过一次活动，深入探讨了上面讨论的主题：

非常感谢以下研究人员对这篇文章的贡献：

• Souilos - 智能合约审计必不可少，但还不够。操作安全（OpSec）审计保护你的协议免受单点故障的影响，补充智能合约审计同样至关重要。Louis（别名Souilos）在本文中为我们提供了帮助，并提供 OpSec 审计，已经帮助了不同的网络3协议（包括 Optimism）。

• Elliot Friedman - 一个专注于安全的智能合约工程师，构建了多个 DeFi 和治理协议——包括 Kleidi Wallet，一个面向安全极端主义者的自我保管解决方案——以及 Forge 提案模拟器，以帮助 DAO 创建安全的治理提案。

• Gosuto - 将传统的财务运营经验带上链，@go__su__to在过去 4 年的全职时间运营多签、分析和 EVM 上的报告。他最擅长区块链的边缘，结合定制的智能合约，构建每个链上资产持有者梦想的端到端管道。

• Alex The Entreprenerd - 根据 Sherlock 的统计，他是历史上32强的出色候选者。Spearbit / C4 的 SR。Recon 的共同创始人。在 C4 中参加了超过 25 场比赛的评委。Badger 的构建者，数亿元的 TVL。

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