【引介】Canon Guard - 更安全的使用 Safe 多签

defi-wonderland
发布于 3小时前
阅读 51

本文介绍了Canon Guard，一种用于多重签名（Multisig）交易的更安全执行模型。它通过引入Action合约来封装交易逻辑，并结合时间锁和自定义Safe Guard合约来增强安全性，旨在减少重复审批、防止恶意攻击，并实现完全链上的透明度和可模拟性。

Canon Guard是一种多签名解决方案，旨在显著增强安全性，最大限度地减少对外部服务的依赖，并简化重复交易的验证。Canon Guard充分利用链上动作合同和动态时间锁来确保安全性、透明度和可恢复性。

## 基本安全假设

* 使用托管在外部服务器上的 UI 意味着完全依赖于它不被黑客入侵。

* 即使非常谨慎的**多重签名**者仍然可能被黑客入侵。

* “$5 扳手攻击”（人身威胁或胁迫）是一种**真实的**风险，在设计安全流程时应予以考虑。

* 即使是最细致的签名者最终也会因反复检查相同的**多重签名**交易而感到审查疲劳，可能会忽略关键细节。

## Canon Guard 的核心原则

**最小化重复审批**：重复发生的交易应该只需要彻底验证一次，而不是反复验证。

**所有交易都设置时间锁**： 
* 预先批准或常规交易可以通过较短的时间锁
* 新的、不寻常的或风险较高的交易必须面临较长的时间锁，以便取消。

**禁止** DELEGATECALL：此 **操作码** 引入了严重的安全风险，应被断然禁止。

**消除外部依赖**：签名者流程应仅依赖于区块链——无需链下信任或外部服务。

**一切都在链上**：

- 审批必须仅通过链上交易完成。

- 模拟和安全检查应纯粹依赖于链上数据，不需要任何链下输入。

**胁迫下的弹性**：即使在极端情况下（例如，所有签名者同时被攻破），也应该不可能立即耗尽 Safe。

**紧急模式**：

* 在紧急情况下，Safe 可以由允许的地址设置为紧急模式（很可能是一个 1/x**多重签名**）。

* 当处于紧急模式时，紧急签名者也将需要签署任何交易才能执行（紧急签名者很可能是一个 4/7**多重签名**或类似）。

* 如果 Safe 的大多数签名者受到破坏，这将允许轮换签名者。

## 用于**多重签名**的更安全的执行模型

依赖**多重签名**的组织经常执行重复发生的交易——例如工资支付或归属基金声明。每个交易提议和签名都会引入潜在的利用面。此解决方案的目标是显著降低该风险。

这种方法借鉴了 Sky（以前的 MakerDAO）和 Spark 使用的 **spells** 架构，此外还避免了使用 DELEGATECALL， 这需要对每次调用都格外小心，因为存在更改合约存储的风险（灾难性的）。

该系统的核心是 **操作 (Actions)** 的概念：Solidity 智能合约，它封装了所有必要的交易逻辑和参数。这些操作旨在：

**简单** – 专注且易于理解。
**不可变** – 一旦部署，就无法更改。
**独立** – 自包含，没有外部依赖。
**链上** – 完全部署到区块链，以实现透明度和可审计性。

为确保安全性和可靠性，所有操作都应在使用前经过彻底的审计。

这是一个简单的操作示例，将 100,000 DAI 转账到

vitalik.eth :

![](https://img.learnblockchain.cn/2025/09/15/46469067_image.png)

为重复发生的交易部署一个操作——一个小的、不可变的智能合约——确保只需要仔细审查一次。一旦经过审查，相同的操作可以安全地重用并在 Safe 中排队，而无需重复进行深入审查。

为了管理这些操作，我们引入了一个 **入口点 (Entrypoint)** 合约。此合约维护操作队列，并跟踪哪些操作地址已预先批准，用于特定时间段（例如，“预先批准一项操作一年”）。

组织应旨在将所有重复发生或例行操作定义为链上操作，将它们与**特别的 (ad-hoc)** 或敏感交易明确分开：

**预先审查的操作**：
* 通过较短的时间锁（例如，1 小时）。
* 每次排队时不需要详细的签名者审查。
* 示例包括定期工资支付或 **token** 归属声明。
* 预先批准一段有限的时间。

**不规则交易**：
* 通过较长的时间锁（例如，1 周）。
* 当排队时，应触发来自监控工具的警报。
* 需要签名者进行全面的人工审查，以检测潜在的恶意行为。
* 将新操作添加到预先审查的列表中本身被认为是不规则交易。
* 最佳实践是**最小化**不规则交易的数量和频率。

### 使用自定义 Safe Guard 增强安全性

为强制执行严格的交易边界，应部署自定义 Safe Guard 合约以：

* 阻止所有链下签名。

* 仅允许来自入口点的调用。

* 拒绝所有 DELEGATECALL 操作，除了到 multiSend 的操作。

### 透明且可模拟

由于操作和队列都完全存储在链上，因此可以使用 Tenderly 等工具来模拟交易行为，而无需任何链下输入。这允许签名者和观察者准确地预览交易的执行方式。

一个 Canon Guard 设置并不能消除谨慎的需要。不规则交易仍然是一个关键的风险向量。必须使用严格的程序和彻底的审查来处理每个交易，以确保它们是合法的且没有隐藏的威胁。

## 常见问题 FAQ

### 此设置适用于谁？

此设置专为需要对其**资金库**运营进行高保证控制的 DAO、**协议**团队和 **crypto-native** 组织而设计。它特别适合于管理大量资金或执行重复发生的交易的团队，其中**最小化**签名者疲劳以及暴露于网络钓鱼或 UI 破坏至关重要。任何寻求完全链上、模拟友好且防篡改的**多重签名**执行模型的团队都将从此架构中受益。

### 如何防止所有签名者同时受到胁迫？

即使所有签名者同时受到胁迫，执行任何不规则交易（例如，提取所有资金）仍然至少需要很长时间锁周期（例如，7 天）的时间。除非胁迫持续整个期间，并且没有人触发紧急模式，或者紧急签名者**多重签名**也受到破坏，否则这种延长的延迟提供了充足的干预机会。

### 如果所有签名者的硬件钱包或计算机受到破坏会怎样？

如果由于硬件受到破坏而提出了不规则交易，监控系统将立即触发警报。将有一个时间锁窗口（例如，7 天）来识别并从队列中删除恶意操作。
但是，删除受损的签名者也需要此时间锁周期，在此期间攻击者可能会进行干扰。在这种极端情况下，组织应使用紧急**多重签名**作为安全后备，以避免遭受 DoS 攻击。

### 如果 Safe UI 受到破坏会怎样？

此提议的系统根本不依赖 Safe UI。可以使用本地脚本、Etherscan 或直接通过支持任意合约交互的钱包来对操作进行排队。

### 如果 Tenderly 或另一个模拟工具受到破坏会怎样？

在极少数情况下，恶意行为者拦截了一笔不规则交易并操纵 Tenderly 等模拟工具来掩盖其恶意性质，仅依赖于单个工具会带来风险。为缓解这种情况，应采用多种独立的验证方法来彻底确认交易的有效性。我们将来可能会发布推荐的验证流程。

### 你能在 Safe 中预先审查一个 **swap** 操作吗？

你能吗？可以… 你应该吗？我们不这么认为。

**Swaps** 需要复杂的逻辑和动态参数，例如**最小**输出量。我们认为操作应该尽可能简单。因此，如果你需要进行**token**转换，最好只是将你想 **swap** 的 **token** 移动到另一个 Safe 或 EOA，在那里执行 **swap**，然后存回去，从而降低你主 Safe 中的风险。

## 实施概述

该项目仍在开发中，但当前代码库提供了该系统如何工作的清晰视图。

[GitHub Repository](https://github.com/defi-wonderland/canon-guard)

一些 Action 合约及其 **工厂** 已经实现，以及核心的 **入口点 (Entrypoint)** 合约。

注意：我们正在简化 CappedTokenTransfers，它目前过于复杂，无法实现其应实现的目标。

## 架构

### 关键组件

**提议者（Safe 签名者）**

* 对交易批处理进行排队和删除。

**入口点 (Entrypoint)**

- 用于排队、验证和执行交易的中央控制器。
- 根据预先批准强制执行短/长时间锁。
- 唯一批准的执行者。
- 为监控工具（例如 Discord）发送链上事件。

**操作 (Actions)**

- 通过 getActions() 返回交易批处理的不可变智能合约。
- 可重用于重复发生的工作流程。

## 生命周期

### 1\. 批处理提议

```Solidity
Proposer → Entrypoint.queue(Actions address) Entrypoint -> Actions.getActions()
```

* 调用 Actions 合约上的 getActions()

* 应用时间锁：

* 如果操作已预先审查，则为短时间锁。

* 否则，为长时间锁。

* 触发 actionHash 供链下监听器使用。

### 2\. 交易模拟

```Solidity
Proposer → Entrypoint.execute(actionHash)
Entrypoint -> SAFE.execTransaction(payload,newSignatures\[\])
```
 * 使用 Tenderly 等工具进行模拟，使用：

* timestamp 覆盖来绕过时间锁

* prank 提议者（如果访问受控制）

* 设置所需的签名者 = 0

* 入口点构建：

- 一个 MultiSend **payload**
    - 对 SAFE.execTransaction 的调用

如果模拟失败或执行不需要的操作，任何提议者都可以调用 `unqueue()` 来取消批处理。

### 3\. 交易审批

```Solidity
Signer → Entrypoint.getBatchHash(hash\[, nonce\])
Signer → SAFE.approveHash(batchHash)
```

签名者使用以下方式批准：

getBatchHash(hash)（默认为下一个 **nonce**）或

getBatchHash(hash, nonce)（指定执行顺序）

如果另一个交易先执行，则需要使用更新的 **nonce** 重新批准。

### 4\. 交易执行

```Solidity
Proposer → Entrypoint.execute(actionHash)
Entrypoint -> SAFE.nonce()
Entrypoint -> SAFE.execTransaction(payload, signaturePayload)
SAFE -> Guard.verifyTransaction(txData)// checks msgSender == Entrypoint
```

* 验证：

* 时间锁已过

* 当前 Safe nonce

* 删除入口点中的时间锁数据以防止重放。

* 调用 SAFE.execTransaction() 使用：
    *  MultiSend **payload**
    * Guard 验证：
        * 执行者是入口点或紧急**多重签名**
        * DELEGATECALL 仅允许到 MultiSend

从入口点的角度来看，**nonce** 是动态的。签名者在批准时必须跟踪它。

## 主要优点

- **透明**：所有内容都存储在链上并经过验证
-**易于模拟**：简单的操作地址输入，无需手动准备 **payload**
- **无信任验证**：模拟和执行之间的一致 **哈希**
- **安全**：Guard 强制执行关键约束
- **无链下签名**：完全链上控制和可审计性
- **灵活**：**白名单**逻辑支持快速/慢速路径

## 实现说明

Action 合约可以重用（例如，用于声明 **token**）
**白名单**操作的**快速通道**（1 小时延迟）
**Nonce** 在执行时动态加载

你可以构建智能的可重用 Action 合约（例如，**上限转移**），这些合约直接嵌入安全限制。这些合约可以预先批准，而无需向入口点添加逻辑。

>- 原文链接： [defi-wonderland.notion.s...](https://defi-wonderland.notion.site/Canon-Guard-Explainer-1dc9a4c092c78003ba94c88f7485914c)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

基本安全假设

使用托管在外部服务器上的 UI 意味着完全依赖于它不被黑客入侵。
即使非常谨慎的多重签名者仍然可能被黑客入侵。
“$5 扳手攻击”（人身威胁或胁迫）是一种真实的风险，在设计安全流程时应予以考虑。
即使是最细致的签名者最终也会因反复检查相同的多重签名交易而感到审查疲劳，可能会忽略关键细节。

Canon Guard 的核心原则

最小化重复审批：重复发生的交易应该只需要彻底验证一次，而不是反复验证。

所有交易都设置时间锁：

预先批准或常规交易可以通过较短的时间锁
新的、不寻常的或风险较高的交易必须面临较长的时间锁，以便取消。

禁止 DELEGATECALL：此 操作码 引入了严重的安全风险，应被断然禁止。

消除外部依赖：签名者流程应仅依赖于区块链——无需链下信任或外部服务。

一切都在链上：

审批必须仅通过链上交易完成。
模拟和安全检查应纯粹依赖于链上数据，不需要任何链下输入。

胁迫下的弹性：即使在极端情况下（例如，所有签名者同时被攻破），也应该不可能立即耗尽 Safe。

紧急模式：

在紧急情况下，Safe 可以由允许的地址设置为紧急模式（很可能是一个 1/x多重签名）。
当处于紧急模式时，紧急签名者也将需要签署任何交易才能执行（紧急签名者很可能是一个 4/7多重签名或类似）。
如果 Safe 的大多数签名者受到破坏，这将允许轮换签名者。

用于多重签名的更安全的执行模型

依赖多重签名的组织经常执行重复发生的交易——例如工资支付或归属基金声明。每个交易提议和签名都会引入潜在的利用面。此解决方案的目标是显著降低该风险。

这种方法借鉴了 Sky（以前的 MakerDAO）和 Spark 使用的 spells 架构，此外还避免了使用 DELEGATECALL，这需要对每次调用都格外小心，因为存在更改合约存储的风险（灾难性的）。

该系统的核心是 操作 (Actions) 的概念：Solidity 智能合约，它封装了所有必要的交易逻辑和参数。这些操作旨在：

简单 – 专注且易于理解。 不可变 – 一旦部署，就无法更改。独立 – 自包含，没有外部依赖。链上 – 完全部署到区块链，以实现透明度和可审计性。

为确保安全性和可靠性，所有操作都应在使用前经过彻底的审计。

这是一个简单的操作示例，将 100,000 DAI 转账到

vitalik.eth :

为了管理这些操作，我们引入了一个 入口点 (Entrypoint) 合约。此合约维护操作队列，并跟踪哪些操作地址已预先批准，用于特定时间段（例如，“预先批准一项操作一年”）。

组织应旨在将所有重复发生或例行操作定义为链上操作，将它们与特别的 (ad-hoc) 或敏感交易明确分开：

预先审查的操作：

通过较短的时间锁（例如，1 小时）。
每次排队时不需要详细的签名者审查。
示例包括定期工资支付或 token 归属声明。
预先批准一段有限的时间。

不规则交易：

通过较长的时间锁（例如，1 周）。
当排队时，应触发来自监控工具的警报。
需要签名者进行全面的人工审查，以检测潜在的恶意行为。
将新操作添加到预先审查的列表中本身被认为是不规则交易。
最佳实践是最小化不规则交易的数量和频率。

使用自定义 Safe Guard 增强安全性

为强制执行严格的交易边界，应部署自定义 Safe Guard 合约以：

阻止所有链下签名。
仅允许来自入口点的调用。
拒绝所有 DELEGATECALL 操作，除了到 multiSend 的操作。

透明且可模拟

常见问题 FAQ

此设置适用于谁？

此设置专为需要对其资金库运营进行高保证控制的 DAO、协议团队和 crypto-native 组织而设计。它特别适合于管理大量资金或执行重复发生的交易的团队，其中最小化签名者疲劳以及暴露于网络钓鱼或 UI 破坏至关重要。任何寻求完全链上、模拟友好且防篡改的多重签名执行模型的团队都将从此架构中受益。

如何防止所有签名者同时受到胁迫？

即使所有签名者同时受到胁迫，执行任何不规则交易（例如，提取所有资金）仍然至少需要很长时间锁周期（例如，7 天）的时间。除非胁迫持续整个期间，并且没有人触发紧急模式，或者紧急签名者多重签名也受到破坏，否则这种延长的延迟提供了充足的干预机会。

如果所有签名者的硬件钱包或计算机受到破坏会怎样？

如果由于硬件受到破坏而提出了不规则交易，监控系统将立即触发警报。将有一个时间锁窗口（例如，7 天）来识别并从队列中删除恶意操作。但是，删除受损的签名者也需要此时间锁周期，在此期间攻击者可能会进行干扰。在这种极端情况下，组织应使用紧急多重签名作为安全后备，以避免遭受 DoS 攻击。

如果 Safe UI 受到破坏会怎样？

此提议的系统根本不依赖 Safe UI。可以使用本地脚本、Etherscan 或直接通过支持任意合约交互的钱包来对操作进行排队。

如果 Tenderly 或另一个模拟工具受到破坏会怎样？

你能在 Safe 中预先审查一个 swap 操作吗？

你能吗？可以… 你应该吗？我们不这么认为。

Swaps 需要复杂的逻辑和动态参数，例如最小输出量。我们认为操作应该尽可能简单。因此，如果你需要进行token转换，最好只是将你想 swap 的 token 移动到另一个 Safe 或 EOA，在那里执行 swap，然后存回去，从而降低你主 Safe 中的风险。

实施概述

该项目仍在开发中，但当前代码库提供了该系统如何工作的清晰视图。

GitHub Repository

一些 Action 合约及其工厂已经实现，以及核心的 入口点 (Entrypoint) 合约。

注意：我们正在简化 CappedTokenTransfers，它目前过于复杂，无法实现其应实现的目标。

架构

关键组件

提议者（Safe 签名者）

对交易批处理进行排队和删除。

入口点 (Entrypoint)

用于排队、验证和执行交易的中央控制器。
根据预先批准强制执行短/长时间锁。
唯一批准的执行者。
为监控工具（例如 Discord）发送链上事件。

操作 (Actions)

通过 getActions() 返回交易批处理的不可变智能合约。
可重用于重复发生的工作流程。

生命周期

1. 批处理提议

Proposer → Entrypoint.queue(Actions address) Entrypoint -> Actions.getActions()

调用 Actions 合约上的 getActions()
应用时间锁：
- 如果操作已预先审查，则为短时间锁。
- 否则，为长时间锁。
触发 actionHash 供链下监听器使用。

2. 交易模拟

Proposer → Entrypoint.execute(actionHash)
Entrypoint -> SAFE.execTransaction(payload,newSignatures\[\])

使用 Tenderly 等工具进行模拟，使用：
- timestamp 覆盖来绕过时间锁
- prank 提议者（如果访问受控制）
- 设置所需的签名者 = 0

入口点构建：
- 一个 MultiSend payload
- 对 SAFE.execTransaction 的调用

如果模拟失败或执行不需要的操作，任何提议者都可以调用 unqueue() 来取消批处理。

3. 交易审批

Signer → Entrypoint.getBatchHash(hash\[, nonce\])
Signer → SAFE.approveHash(batchHash)

签名者使用以下方式批准：

getBatchHash(hash)（默认为下一个 nonce）或

getBatchHash(hash, nonce)（指定执行顺序）

如果另一个交易先执行，则需要使用更新的 nonce 重新批准。

4. 交易执行

Proposer → Entrypoint.execute(actionHash)
Entrypoint -> SAFE.nonce()
Entrypoint -> SAFE.execTransaction(payload, signaturePayload)
SAFE -> Guard.verifyTransaction(txData)// checks msgSender == Entrypoint

验证：
- 时间锁已过
- 当前 Safe nonce
删除入口点中的时间锁数据以防止重放。
调用 SAFE.execTransaction() 使用：
- MultiSend payload
- Guard 验证：
  - 执行者是入口点或紧急多重签名
  - DELEGATECALL 仅允许到 MultiSend

从入口点的角度来看，nonce 是动态的。签名者在批准时必须跟踪它。

主要优点

透明：所有内容都存储在链上并经过验证 -易于模拟：简单的操作地址输入，无需手动准备 payload
无信任验证：模拟和执行之间的一致哈希
安全：Guard 强制执行关键约束
无链下签名：完全链上控制和可审计性
灵活：白名单逻辑支持快速/慢速路径

实现说明

Action 合约可以重用（例如，用于声明 token） 白名单操作的快速通道（1 小时延迟） Nonce 在执行时动态加载

你可以构建智能的可重用 Action 合约（例如，上限转移），这些合约直接嵌入安全限制。这些合约可以预先批准，而无需向入口点添加逻辑。

原文链接： defi-wonderland.notion.s...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。