Safe 智能合约账户的安全操作指南 - 第 2 部分

Bazzani
发布于 1天前
阅读 120

本文探讨了高价值Safe智能账户的安全操作指南，包括推荐的安全配置、签名过程以及人员培训等方面。文中强调了针对特定攻击的多种预防措施和安全策略，以确保高价值安全账户的有效操作和减少人为失误的风险。

![](https://img.learnblockchain.cn/2025/04/11/1FN2PfiDuWQtmh2Ix1b2pOg.png)

> “只有偏执狂才能生存” — **安迪·格罗夫**

## 介绍

操作 **Safe智能账户** 需要清晰的理解以太坊的账户机制和基本的安全实践。本文将关键概念综合成一个实践指南，供安全操作员参考。最近，多部高价值安全账户遭遇了复杂的攻击，**归结为朝鲜民主主义人民共和国（DPRK）的行为**。尽管如此，资金损失的根本原因往往是由于缺乏知识、谨慎或意识导致的人为错误，这给被攻破的账户带来了灾难性的后果，也为DPRK带来了可观的利润 [¹](#c5b9)。

对于尚未熟悉安全智能账户核心概念的读者，本文的[第一部分](https://learnblockchain.cn/article/14079) 解释了在安全操作安全智能账户时必须理解的关键术语和架构组件。

## 推荐的安全设置

推荐的安全设置满足以下条件：

**签名接口：**

- 所有所有者应使用通过 **硬件钱包** 生成和管理的EOA。
- 每个所有者的EOA**应仅用于在特定多签下签名元交易，而不用于其他任何目的**。这有助于防止意外为错误的多签签名元交易。
- **EOA密钥绝不应以数字形式存储**。相反，必须创建安全的物理备份并存放在与硬件钱包分开的地点，以确保在硬件故障时可以恢复。
- **硬件钱包至少应支持EIP-712数据的明签名**。只允许盲签名的设备应立即更换。有关最佳设备使用的参考，请参见[Patrick Collins的硬件钱包指南](https://learnblockchain.cn/article/13850) [²](#43ab)。
- 所有者的EOA操作员应使用**多种硬件钱包设备，以最小化单点故障的风险**，以防特定的供应商或型号被攻破或出现故障。
- 所有者的EOA操作员应**通过注入软件钱包（如MetaMask、Rabby或Frame）使用硬件钱包**。这增加了一层额外的验证和设置多样性，因为EIP-712的 `SafeTx` 类型数据会被清楚地显示。然而，由于软件钱包比硬件钱包更容易受到攻击，因此其验证应视为有效事务的确认，但**绝不应排除潜在恶意的验证**。
- 所有者EOA **操作员应使用专用计算设备**专门用于该目的，并且大部分时间保持关机。理想情况下，他们应使用具有安全操作系统的设备（例如Tails或Qubes），仅在验证和签署交易时开启。

**多签配置：**

- **阈值的配置应在安全性和操作需求之间取得平衡**。如果需要更低的阈值以满足操作需求，则应部署一个具有有限权限的二级安全智能账户，仅处理特定操作。对于高价值安全账户，阈值应为**不低于“4-7”**。
- **绝不应使用“m-of-m”阈值**，因为始终必须考虑密钥丢失或泄露的问题。
- **安全智能账户配置应尽可能简单**。避免使用模块，因为它们增加了安全的攻击面。如果使用模块在操作上是必要的，请考虑专门部署一个二级多签钱包处理此用途并定期为其提供资金。

**所有者EOA操作员：**

- 每个所有者的EOA应由来自**不同地理位置**的不同团队成员进行操作，以降低物理威胁风险。
- 一个单独的人**不应在单一多签上操作多个EOA**。
- 所有者EOA **操作员的身份绝不应公开曝光**。
- 所有者EOA操作员应接受培训，**解读、理解并验证每个** `SafeTx` **元交易数据的字段，理想情况下在硬件钱包的屏幕上审查**。
- 所有者EOA **操作员应定期进行培训**，以确保其密钥始终可用，并保持对签名过程的熟悉。对于很少执行交易的安全智能账户，建议 регуляр地进行签名模拟，以帮助所有者保留必要的知识。
- 所有者EOA **操作员应接受培训，以识别钓鱼、社会工程学和其他攻击向量**，包括瞄准的和复杂的攻击。

Fredrik Svantes的[**How to Multisig**](https://howtomultisig.com/) [**³**](#6317) 应用程序提供了针对不同威胁档案的简报清单，帮助评估安全智能账户设置的安全性。

## 推荐的安全签名过程

对于特定操作员和`SafeTx`，签名过程涉及元交易数据从安全应用（或任何使用的接口）转移到硬件钱包接口进行签名，然后再返回签名状态。

![](https://img.learnblockchain.cn/2025/04/11/1Or8qN1WGL8QvXOxRHcfHEQ.png)

**签名过程中 SafeTx 数据流动。**

在攻击场景中，恶意的元交易数据可能会被传递到用户的端点或在端点被篡改。假设硬件钱包是防篡改的，则硬件钱包的屏幕应视为不可篡改的真实信息源。

## `SafeTx` EIP-712 数据解码

每个所有者应**理解显示在 Safe{Wallet} UI 中的每个字段**的`SafeTx`信息，并验证数据是否符合安全智能账户要执行的预期操作。此验证应在所有接口上执行：Safe UI、注入钱包和硬件钱包屏幕。建议对所有者进行培训，使其能够识别特定安全智能账户预期执行的最常见操作，从而能够通过审查即将签名的 `SafeTx` 结构数据来判断事务是否合法。

**解码 ERC-20 代币转账的示例。** 下面是所有者需签署简单 ERC-20 转移时所看到的内容示例。

![](https://img.learnblockchain.cn/2025/04/11/1PA1Ljv5h1a6xQ3Q_37zV2Q.png)

**在 Safe{Wallet} UI 中显示的 USDC ERC-20 转账元交易数据。**

Safe{Wallet} UI 已经解码了 `transfer` 操作，并以更用户友好的方式显示。该具体交易调用 USDC 合约上的 `transfer` 函数，向地址（`to`） `0xCE11BC2359C665aEaDAF586D5f07704EDE4F3b69` 转账。它转移的金额（`value`）为 `1000000000` 单位，这 corresponds to 1000 USDC，因为USDC代币使用6位小数表示精度。

![](https://img.learnblockchain.cn/2025/04/11/11FClFO_dF_6aZhAJTA6hzQ.png)

**解码的 USDC ERC-20 转账元交易。**

此信息也可以通过直接观察交易数据来提取，因为它清晰地显示出需要为该特定交易签名的 `SafeTx` 结构的每个字段。

![](https://img.learnblockchain.cn/2025/04/11/18nmneaZujxQJqAUIQcrLRA.png)

**USDC ERC-20 转账元交易的交易数据。**

对于这一具体的 `SafeTx`：

- `SafeTx.to` 字段指示该交易将调用 USDC 合约，该地址 `0x1c7D4B19…` 对应于 Sepolia 测试网的 USDC 合约。
- `SafeTx.value` 字段指出不会有 ETH 从安全智能账户余额转移到 USDC 合约。
- `SafeTx.data` 字段确定了在 USDC 合约上要调用的函数和参数。
- `SafeTx.operation` 字段指示正进行常规调用，而不是代理调用。

`SafeTx.data` 字段的解释如下：

![](https://img.learnblockchain.cn/2025/04/11/18xNfCxokvkBfyvoG3xlnEQ.png)

`SafeTx.data` **对 USDC ERC-20 转账元交易的解释。**

- 前四个字节指示函数选择器 `0xa9059cbb`，这对应于常规 ERC-20 转账函数 `transfer(address,uint256)`。大多数常见选择器可以在 [openchain.xyz](http://openchain.xyz/) 公共数据库中检查。
- 随后的32个字节是以太坊地址的ABI编码表示，这里表示将接收 USDC 代币的地址 `0xce11bc23...`。
- 最后32个字节代表 ABI 编码的无符号整数，这里是发送的 USDC 数量，表达为十六进制值：`0x3b9aca00`，对应 `1000000000`。

在交易详情的底部，你可以看到对应于正在签名的特定 `SafeTx` 的 EIP-712 哈希值。

![](https://img.learnblockchain.cn/2025/04/11/1weZDpUuZZ8VP418RfbtZIA.png)

**示例元交易的 EIP-712 哈希。**

**建议所有者 EOA 操作员学习如何解码这些数据，如在 ERC-20 转账示例中演示的那样，但重点关注其安全通常执行的具体类型的 `SafeTx` 交易。这将确保他们具备正确验证 `SafeTx` 数据的必要技能。**

## 硬件钱包签名过程

正如我们之前所述，**安全元交易生命周期的关键部分就是元交易签名**，其中每个所有者使用其 EOA 私钥对 EIP-712 `SafeTx` 类型数据摘要进行签名。

**取决于使用的设备类型，我们可能会遇到两种不同的签名流程。**

**案例 A：盲签名设备。** 盲签名设备仅向用户显示 EIP-712 域和消息哈希。**盲签名设备使得在设备屏幕上验证签名数据成为不可能**。

![](https://img.learnblockchain.cn/2025/04/11/1E-6tb7sOUYAUl4MoCn1-kg.png)

**在 Ledger Nano S 上盲签署 EIP-712 消息的示例。**

**盲签名被钱包提供者视为不安全，通常会在盲目签署哈希时显示警告信息。任何仅允许盲签名的设备均应立即更换，如果打算用作安全所有者EOA。此类设备的示例包括 Trezor One 和 Ledger Nano S。**

![](https://img.learnblockchain.cn/2025/04/11/1At0YBRpJU5UZAQVUExO39w.png)

**Trezor One 盲签名警告。**

**案例 B：显示 EIP-712 数据细分的设备。** 为了操作安全智能账户的所有者EOA，**只能使用显示 EIP-712 数据完整细分的设备**。这些设备允许用户直接在设备屏幕上验证正在签名的数据，无需依赖任何第三方应用程序。**在硬件钱包屏幕上验证每个 EIP-712 数据字段是签名之前的最后一步，也是发现潜在攻击的最后机会。**此类设备的示例包括 Trezor Safe 3 和 5。**

![](https://img.learnblockchain.cn/2025/04/11/1_F7AuoZJyyAgYjF3b6-FTQ.png)

**在 Trezor Safe 3 上签名 ERC-20 SafeTx 数据的示例（EIP-712 域）。**

![](https://img.learnblockchain.cn/2025/04/11/1V7SZyLePL2LcNq-01jRggQ.png)

**在 Trezor Safe 3 上签名 ERC-20 SafeTx 数据的示例。**

**案例 C：显示 EIP-712 哈希和数据细分的设备。** 这些设备**同时向用户显示 EIP-712 数据的完整细分和相应的哈希**，允许同时验证数据和哈希。**此类设备的示例包括 Ledger Flex 和 Ledger Stax。**

![](https://img.learnblockchain.cn/2025/04/11/1ZENoUrHky3k79tmK9r1Bhg.png)

**在 Ledger Flex 上签名交易的示例（EIP-712 哈希 + 数据细分）。重复步骤已被省略。**

## 其他安全指南

## 操作字段

**操作字段**是在交易执行中用于指定交易应如何与目标合约交互的参数。它是一个**uint8 值**，包含在交易数据中，可以取两个值之一：

- **0 (CALL)：** 此指令要求 Safe 与目标地址进行 **常规外部调用**。调用在目标合约的上下文中执行，使用其存储和逻辑，Safe 仅发送指定的值（如果有）和 calldata。
- **1 (DELEGATECALL)：** 此指令要求 Safe 将调用委托给目标地址，这意味着目标地址的代码在 Safe 的存储和地址的上下文中执行。这是**更强大但也更危险**，因为它允许目标合约直接修改 Safe 的状态。

如在 [安全智能账户代码](https://github.com/safe-global/safe-smart-account/blob/460f730925c181f9a1700b0f2bec0640b87e8533/contracts/base/Executor.sol#L21-L44) 中所示，执行使用不同的调用指令，具体取决于操作字段。

```
    function execute(
        address to,
        uint256 value,
        bytes memory data,
        Enum.Operation operation,
        uint256 txGas
    ) internal returns (bool success) {
        if (operation == Enum.Operation.DelegateCall) {
            /* solhint-disable no-inline-assembly */
            /// @solidity memory-safe-assembly
            assembly {
                success := delegatecall(txGas, to, add(data, 0x20), mload(data), 0, 0)
            }
            /* solhint-enable no-inline-assembly */
        } else {
            /* solhint-disable no-inline-assembly */
            /// @solidity memory-safe-assembly
            assembly {
                success := call(txGas, to, value, add(data, 0x20), mload(data), 0, 0)
            }
            /* solhint-enable no-inline-assembly */
        }
    }
}
```

`operation=1` 的主要用例是使用 Safe 的 MultiSend 库执行批量交易。批量交易的编码方式与 `SafeTx` 结构不同，且更难以验证，因为它们被作为数组打包在 `SafeTx.data` 字段内。

## 尽量让 `SafeTx` 简单

**简化可以减少攻击面**，安全智能账户的设置和交易结构越复杂，可能的故障或利用点就越多。简单的 `SafeTx` 更易于阅读、验证、模拟和签署。这一点尤其重要，特别是在通过硬件钱包与安全进行交互时，屏幕上显示了即将签名的数据。

当使用 `multiSend` 时，`SafeTx.data` 字段将变成一个包含多个编码交易的大单一数据块，这使得立即识别内部调用的困难。这使得攻击者更容易在批处理内隐藏恶意操作。如果严格要求批量交易，**避免使用 Safe 的 MultiSend，而应使用 MultiSendCallOnly**，因为它[禁止使用](https://github.com/safe-global/safe-smart-account/blob/460f730925c181f9a1700b0f2bec0640b87e8533/contracts/libraries/MultiSendCallOnly.sol#L56) `delegatecall`。此外，**避免直接从持有重大价值的安全执行批量交易**。而是**部署一个辅助 Safe**，只为此目的提供必要的最低资金，并从此辅助安全执行批量交易，以降低主体安全被攻破的风险。

对于需要执行复杂交易的协议，如合约部署、升级或任何其他复杂操作，建议避免直接从安全执行这些交易。相反，**使用外部 Governor** 合约来在此处提出交易申请，并通过多签表决程序批准其执行。这种方法引入了链上交易承诺步骤，使元交易影响的模拟和分析更可控。它还将安全需验证的操作简化为简单的 `castVote` 交易。

![](https://img.learnblockchain.cn/2025/04/11/1KTk9x2Ct1J8pYo_GFSGoqw.png)

**在 Safe{Wallet} UI 中显示的简单 castVote 交易的示例。**

## 第三方工具验证 EIP-712 哈希

为了尽早发现潜在攻击，建议使用第三方软件应用程序，与 Safe{Wallet} UI 一起，双重检查用户在 UI 中看到的内容是否完全与在硬件钱包中签署的内容相匹配。

OpenZeppelin 提供了一个替代应用程序，它根据特定的 `SafeTx` 结构计算 EIP-712 哈希，以便你可以双重检查哈希，而不完全依赖于在 Safe{Wallet} UI 中显示的数据。该工具可通过[托管版本](https://safeutils.openzeppelin.com/) [⁴](#308c) 或通过从 [源代码库](https://github.com/openzeppelin/safe-utils) 本地运行。值得注意的是，此应用程序是 CLI 工具 [safe-tx-hashes-util](https://github.com/pcaversaccio/safe-tx-hashes-util) 的 UI 适应版本，最初由 [pcaversaccio](https://medium.com/u/1f9d692afd8b?source=post_page---user_mention--a5641f6ee725---------------------------------------) 提出。

![](https://img.learnblockchain.cn/2025/04/11/1_YA5VAd0uZje32XU1D7Cww.png)

**使用 OpenZeppelin Safe Utils 生成 ERC-20 SafeTx 的 EIP-712 哈希的示例。**

签署者必须确保正在签署的 `SafeTx` 数据准确代表要由安全执行的预期操作。域哈希和交易的消息哈希在 Safe{Wallet} UI、OpenZeppelin Safe Utils UI，以及最重要的，硬件钱包屏幕上应保持一致。

## 注入式钱包的 EIP-712 数据

在使用如 MetaMask 或 Frame 的注入式钱包时，EIP-712 数据也会显示。

![](https://img.learnblockchain.cn/2025/04/11/1ADtiStt1Mp4wojsnHWDZCA.png)

**在 MetaMask（左）和 Rabby（右）中显示的 ERC-20 `SafeTx` 数据示例。**

## 切勿单独依赖计算机屏幕上显示的内容

如果 Safe{Wallet} 前端或用户端点被攻破，**交易详情或哈希可能会被伪造**。屏幕可能显示正确的地址或金额，同时实际发送给你的硬件钱包签署的是其他内容。**硬件钱包的屏幕应被视为真实的信息源**。它离线独立工作，直接从其安全环境中显示你即将签署的内容。**始终在硬件钱包上验证交易详情**，这是确保没有被篡改的唯一方法。**这是你最后且最可靠的安全检查点。**

## 在过程最后一步将执行与签名分开

使用“先离线签名，再作为独立步骤执行”的流程，以确保所有签名者看到相同的交易哈希。否则，最后一个签名者将经过不同的签名流程。Safe{Wallet}支持这一点，让最后一位所需签名者选择稍后执行交易。

在硬件钱包上选择签名和执行选项，将显示触发 `execTransaction` 调用安全智能账户的 EOA 交易哈希，而不是显示实际正在执行的元交易的 EIP-712 `SafeTx` 结构。

![](https://img.learnblockchain.cn/2025/04/11/1k0pCZLrKJPWPrsViCQebEA.png)

**“先离线签名，再作为独立步骤执行”的流程选择模式在 Safe{Wallet} UI。**

## 在法定人数中始终包括区块链安全专家

法定人数中的至少一位签署者应为区块链安全专家。这一点至关重要，因为操作员通常缺乏强大的技术背景，可能会忽视关键检查。如果法定人数中没有专家，签署者应在签名过程中随时可以信任的专家。

## 运行企业实例的安全交易服务

根据你项目的资源和需求，运行你自己的企业实例的[安全交易服务](https://docs.safe.global/core-api/api-safe-transaction-service) [⁵](#58b1) 以与项目的安全智能账户进行交互可能是有兴趣的。这提高了离线签名基础设施的韧性，并允许你在不完全依赖 Safe{Wallet} 基础设施的情况下执行更严格的安全策略。

## 安全智能账户交易数据分析

为了识别高价值安全账户的特定用例需求，进行了一项[数据驱动分析](https://dune.com/openzeppelin/safe-analysis-2024-now) [⁶](#ac57)，分析了2024年1月到撰写本文时（2025年3月）所有主网安全智能账户阈值为3或更高的交易，分析的交易总数超过215,000。以下是结果分析。

## 交易类型分析

通过观察调用的方法，我们可以确定大约 **95% 的交易是对** `execTransaction` 的调用，这些交易都是按照 `SafeTx` 元交易格式形成的。在这95%的交易中，**只有15.5%是代理调用（其中** `SafeTx.operation` **= 1）**，显示出执行的安全交易绝大多数是常规调用 `SafeTx` 元交易。

![](https://img.learnblockchain.cn/2025/04/11/1kpMETEktr9ruBcwyyq_LdQ.png)

**分析中的常规调用（操作=0）与代理调用（操作=1）对比。**

此外，在15.5%的代理调用中，99%以上的情况下，代理调用针对的是官方安全可信库合约。最常用的包括：

- **安全：MultiSendCallOnly 1.3.0**（使用最广，86.2%的案例）
- **安全：MultiSend 1.3.0**（10.1%的案例）
- **安全：SignMessageLib**
- **安全：MultiSend 1.1.1**

## SafeTx.data 选择器分析

所进行的分析显示，分析的所有 `SafeTx` 交易中有58.5%是简单的 ERC-20 代币转账或 ETH 转移。在这些情况下，元交易数据易于验证。

![](https://img.learnblockchain.cn/2025/04/11/19vuwPSnoZT7C4xf2r6mY_Q.png)

**所有分析过的 SafeTx 的 SafeTx.data 选择器。**

## SafeTo.to 地址分析

通过分析 `SafeTx.to` 地址，我们可以识别出调用频率最高的合约。在超过33%的情况下，当 `SafeTx.operation = 0` 时，**所调用的合约是 ERC-20 代币**，USDC 或 USDT 是最常见的类型。

![](https://img.learnblockchain.cn/2025/04/11/1BQ46b3Q-ziJN9D9-Z_I1GQ.png)

**对所有分析过的 SafeTx 的 safeTx.to 地址的分析。**

## 已知攻击

## 2024年7月18日 — WazirX — 2.35亿

签署者被诱骗签署 `SafeTx.operation = 1`，将实现升级至恶意实现。

交易：[https://app.blocksec.com/explorer/tx/eth/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d?line=0](https://app.blocksec.com/explorer/tx/eth/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d?line=0)

反编译的恶意实现：[https://app.dedaub.com/ethereum/address/0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2/decompiled](https://app.dedaub.com/ethereum/address/0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2/decompiled)

## 2024年10月16日 — Radiant Capital — 5300万

Radiant 报告称[⁷](#ac57) 其设备通过 DPRK 演员冒充承包商的方式，例如利用恶意 PDF 进行感染。签署者被诱骗签署一个将协议所有权转移到恶意地址的 `SafeTx`。

交易：[https://app.blocksec.com/explorer/tx/arbitrum/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1](https://app.blocksec.com/explorer/tx/arbitrum/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1)

## 2025年2月21日 — Bybit — 14.3亿

一次高度复杂的针对DPRK黑客的定向攻击涉及改编 Secure{Wallet} 机构，加上在撰写此文时，注入了针对所利用的 Bybit 安全智能账户的恶意有效载荷。签署者被诱骗签署 `SafeTx.operation = 1` 交易，升级合约至恶意实现。黑客使用的一个把戏是将 `SafeTx.data` 的前四个字节设置为匹配ERC-20 `transfer`调用的选择器，使其看起来像是合法的代币转账。然而，`SafeTx.to` 指向恶意实现。

交易：[https://app.blocksec.com/explorer/tx/eth/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882?line=5](https://app.blocksec.com/explorer/tx/eth/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882?line=5)

反编译的恶意实现：[https://app.dedaub.com/ethereum/address/0x96221423681a6d52e184d440a8efcebb105c7242/decompiled](https://app.dedaub.com/ethereum/address/0x96221423681a6d52e184d440a8efcebb105c7242/decompiled)

## 参考文献

\[1\]: samczsun. 揭开朝鲜威胁的面纱 [https://www.paradigm.xyz/2025/03/demystifying-the-north-korean-threat](https://learnblockchain.cn/article/13574)

\[2\]: Patrick Collins Medium. 2025年十大加密货币硬件钱包 | 安全研究员评测 [https://patrickalphac.medium.com/top-9-cryptocurrency-hardware-wallets-for-2025-security-researcher-review-9fcb16d771e0](https://learnblockchain.cn/article/13850)

\[3\]: Fredrik Svantes. 如何进行多签 [https://howtomultisig.com/](https://howtomultisig.com/)

\[4\]: OpenZeppelin. 安全工具 [https://safeutils.openzeppelin.com/](https://safeutils.openzeppelin.com/)

\[5\]: Safe. 运行安全交易服务 [https://docs.safe.global/core-api/api-safe-transaction-service](https://docs.safe.global/core-api/api-safe-transaction-service)

\[6\]: Dune OpenZeppelin. 安全智能账户分析 [https://dune.com/openzeppelin/safe-analysis-2024-now](https://dune.com/openzeppelin/safe-analysis-2024-now)

\[7\]: Radiant Capital Medium. Radiant Capital事件更新 [https://medium.com/@RadiantCapital/radiant-capital-incident-update-e56d8c23829e](https://learnblockchain.cn/article/10798)

\[8\]: X @safe. ByBit调查更新 [https://x.com/safe/status/1897663514975649938](https://x.com/safe/status/1897663514975649938)

>- 原文链接： [medium.com/@bazzanigianf...](https://medium.com/@bazzanigianfranco/safe-secops-guidelines-for-high-value-safe-smart-accounts-a5641f6ee725)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

“只有偏执狂才能生存” — 安迪·格罗夫

介绍

操作 Safe智能账户 需要清晰的理解以太坊的账户机制和基本的安全实践。本文将关键概念综合成一个实践指南，供安全操作员参考。最近，多部高价值安全账户遭遇了复杂的攻击，归结为朝鲜民主主义人民共和国（DPRK）的行为。尽管如此，资金损失的根本原因往往是由于缺乏知识、谨慎或意识导致的人为错误，这给被攻破的账户带来了灾难性的后果，也为DPRK带来了可观的利润 ¹。

对于尚未熟悉安全智能账户核心概念的读者，本文的第一部分解释了在安全操作安全智能账户时必须理解的关键术语和架构组件。

`SafeTx` EIP-712 数据解码

每个所有者应理解显示在 Safe{Wallet} UI 中的每个字段的SafeTx信息，并验证数据是否符合安全智能账户要执行的预期操作。此验证应在所有接口上执行：Safe UI、注入钱包和硬件钱包屏幕。建议对所有者进行培训，使其能够识别特定安全智能账户预期执行的最常见操作，从而能够通过审查即将签名的 SafeTx 结构数据来判断事务是否合法。

解码 ERC-20 代币转账的示例。 下面是所有者需签署简单 ERC-20 转移时所看到的内容示例。

在 Safe{Wallet} UI 中显示的 USDC ERC-20 转账元交易数据。

Safe{Wallet} UI 已经解码了 transfer 操作，并以更用户友好的方式显示。该具体交易调用 USDC 合约上的 transfer 函数，向地址（to） 0xCE11BC2359C665aEaDAF586D5f07704EDE4F3b69 转账。它转移的金额（value）为 1000000000 单位，这 corresponds to 1000 USDC，因为USDC代币使用6位小数表示精度。

解码的 USDC ERC-20 转账元交易。

此信息也可以通过直接观察交易数据来提取，因为它清晰地显示出需要为该特定交易签名的 SafeTx 结构的每个字段。

USDC ERC-20 转账元交易的交易数据。

对于这一具体的 SafeTx：

SafeTx.to 字段指示该交易将调用 USDC 合约，该地址 0x1c7D4B19… 对应于 Sepolia 测试网的 USDC 合约。
SafeTx.value 字段指出不会有 ETH 从安全智能账户余额转移到 USDC 合约。
SafeTx.data 字段确定了在 USDC 合约上要调用的函数和参数。
SafeTx.operation 字段指示正进行常规调用，而不是代理调用。

SafeTx.data 字段的解释如下：

SafeTx.data 对 USDC ERC-20 转账元交易的解释。

前四个字节指示函数选择器 0xa9059cbb，这对应于常规 ERC-20 转账函数 transfer(address,uint256)。大多数常见选择器可以在 openchain.xyz 公共数据库中检查。
随后的32个字节是以太坊地址的ABI编码表示，这里表示将接收 USDC 代币的地址 0xce11bc23...。
最后32个字节代表 ABI 编码的无符号整数，这里是发送的 USDC 数量，表达为十六进制值：0x3b9aca00，对应 1000000000。

在交易详情的底部，你可以看到对应于正在签名的特定 SafeTx 的 EIP-712 哈希值。

示例元交易的 EIP-712 哈希。

建议所有者 EOA 操作员学习如何解码这些数据，如在 ERC-20 转账示例中演示的那样，但重点关注其安全通常执行的具体类型的 SafeTx 交易。这将确保他们具备正确验证 SafeTx 数据的必要技能。

硬件钱包签名过程

正如我们之前所述，安全元交易生命周期的关键部分就是元交易签名，其中每个所有者使用其 EOA 私钥对 EIP-712 SafeTx 类型数据摘要进行签名。

取决于使用的设备类型，我们可能会遇到两种不同的签名流程。

案例 A：盲签名设备。 盲签名设备仅向用户显示 EIP-712 域和消息哈希。盲签名设备使得在设备屏幕上验证签名数据成为不可能。

在 Ledger Nano S 上盲签署 EIP-712 消息的示例。

盲签名被钱包提供者视为不安全，通常会在盲目签署哈希时显示警告信息。任何仅允许盲签名的设备均应立即更换，如果打算用作安全所有者EOA。此类设备的示例包括 Trezor One 和 Ledger Nano S。

Trezor One 盲签名警告。

案例 B：显示 EIP-712 数据细分的设备。 为了操作安全智能账户的所有者EOA，只能使用显示 EIP-712 数据完整细分的设备。这些设备允许用户直接在设备屏幕上验证正在签名的数据，无需依赖任何第三方应用程序。在硬件钱包屏幕上验证每个 EIP-712 数据字段是签名之前的最后一步，也是发现潜在攻击的最后机会。此类设备的示例包括 Trezor Safe 3 和 5。**

在 Trezor Safe 3 上签名 ERC-20 SafeTx 数据的示例（EIP-712 域）。

在 Trezor Safe 3 上签名 ERC-20 SafeTx 数据的示例。

案例 C：显示 EIP-712 哈希和数据细分的设备。 这些设备同时向用户显示 EIP-712 数据的完整细分和相应的哈希，允许同时验证数据和哈希。此类设备的示例包括 Ledger Flex 和 Ledger Stax。

在 Ledger Flex 上签名交易的示例（EIP-712 哈希 + 数据细分）。重复步骤已被省略。

其他安全指南

操作字段

操作字段是在交易执行中用于指定交易应如何与目标合约交互的参数。它是一个uint8 值，包含在交易数据中，可以取两个值之一：

0 (CALL)： 此指令要求 Safe 与目标地址进行 常规外部调用。调用在目标合约的上下文中执行，使用其存储和逻辑，Safe 仅发送指定的值（如果有）和 calldata。
1 (DELEGATECALL)： 此指令要求 Safe 将调用委托给目标地址，这意味着目标地址的代码在 Safe 的存储和地址的上下文中执行。这是更强大但也更危险，因为它允许目标合约直接修改 Safe 的状态。

如在安全智能账户代码中所示，执行使用不同的调用指令，具体取决于操作字段。

    function execute(
        address to,
        uint256 value,
        bytes memory data,
        Enum.Operation operation,
        uint256 txGas
    ) internal returns (bool success) {
        if (operation == Enum.Operation.DelegateCall) {
            /* solhint-disable no-inline-assembly */
            /// @solidity memory-safe-assembly
            assembly {
                success := delegatecall(txGas, to, add(data, 0x20), mload(data), 0, 0)
            }
            /* solhint-enable no-inline-assembly */
        } else {
            /* solhint-disable no-inline-assembly */
            /// @solidity memory-safe-assembly
            assembly {
                success := call(txGas, to, value, add(data, 0x20), mload(data), 0, 0)
            }
            /* solhint-enable no-inline-assembly */
        }
    }
}

operation=1 的主要用例是使用 Safe 的 MultiSend 库执行批量交易。批量交易的编码方式与 SafeTx 结构不同，且更难以验证，因为它们被作为数组打包在 SafeTx.data 字段内。

尽量让 `SafeTx` 简单

简化可以减少攻击面，安全智能账户的设置和交易结构越复杂，可能的故障或利用点就越多。简单的 SafeTx 更易于阅读、验证、模拟和签署。这一点尤其重要，特别是在通过硬件钱包与安全进行交互时，屏幕上显示了即将签名的数据。

当使用 multiSend 时，SafeTx.data 字段将变成一个包含多个编码交易的大单一数据块，这使得立即识别内部调用的困难。这使得攻击者更容易在批处理内隐藏恶意操作。如果严格要求批量交易，避免使用 Safe 的 MultiSend，而应使用 MultiSendCallOnly，因为它禁止使用 delegatecall。此外，避免直接从持有重大价值的安全执行批量交易。而是部署一个辅助 Safe，只为此目的提供必要的最低资金，并从此辅助安全执行批量交易，以降低主体安全被攻破的风险。

对于需要执行复杂交易的协议，如合约部署、升级或任何其他复杂操作，建议避免直接从安全执行这些交易。相反，使用外部 Governor 合约来在此处提出交易申请，并通过多签表决程序批准其执行。这种方法引入了链上交易承诺步骤，使元交易影响的模拟和分析更可控。它还将安全需验证的操作简化为简单的 castVote 交易。

在 Safe{Wallet} UI 中显示的简单 castVote 交易的示例。

第三方工具验证 EIP-712 哈希

OpenZeppelin 提供了一个替代应用程序，它根据特定的 SafeTx 结构计算 EIP-712 哈希，以便你可以双重检查哈希，而不完全依赖于在 Safe{Wallet} UI 中显示的数据。该工具可通过托管版本 ⁴ 或通过从源代码库本地运行。值得注意的是，此应用程序是 CLI 工具 safe-tx-hashes-util 的 UI 适应版本，最初由 pcaversaccio 提出。

使用 OpenZeppelin Safe Utils 生成 ERC-20 SafeTx 的 EIP-712 哈希的示例。

签署者必须确保正在签署的 SafeTx 数据准确代表要由安全执行的预期操作。域哈希和交易的消息哈希在 Safe{Wallet} UI、OpenZeppelin Safe Utils UI，以及最重要的，硬件钱包屏幕上应保持一致。

注入式钱包的 EIP-712 数据

在使用如 MetaMask 或 Frame 的注入式钱包时，EIP-712 数据也会显示。

在 MetaMask（左）和 Rabby（右）中显示的 ERC-20 SafeTx 数据示例。

切勿单独依赖计算机屏幕上显示的内容

如果 Safe{Wallet} 前端或用户端点被攻破，交易详情或哈希可能会被伪造。屏幕可能显示正确的地址或金额，同时实际发送给你的硬件钱包签署的是其他内容。硬件钱包的屏幕应被视为真实的信息源。它离线独立工作，直接从其安全环境中显示你即将签署的内容。始终在硬件钱包上验证交易详情，这是确保没有被篡改的唯一方法。这是你最后且最可靠的安全检查点。

在过程最后一步将执行与签名分开

在硬件钱包上选择签名和执行选项，将显示触发 execTransaction 调用安全智能账户的 EOA 交易哈希，而不是显示实际正在执行的元交易的 EIP-712 SafeTx 结构。

“先离线签名，再作为独立步骤执行”的流程选择模式在 Safe{Wallet} UI。

在法定人数中始终包括区块链安全专家

运行企业实例的安全交易服务

根据你项目的资源和需求，运行你自己的企业实例的安全交易服务 ⁵ 以与项目的安全智能账户进行交互可能是有兴趣的。这提高了离线签名基础设施的韧性，并允许你在不完全依赖 Safe{Wallet} 基础设施的情况下执行更严格的安全策略。

安全智能账户交易数据分析

为了识别高价值安全账户的特定用例需求，进行了一项数据驱动分析 ⁶，分析了2024年1月到撰写本文时（2025年3月）所有主网安全智能账户阈值为3或更高的交易，分析的交易总数超过215,000。以下是结果分析。

交易类型分析

通过观察调用的方法，我们可以确定大约 95% 的交易是对 execTransaction 的调用，这些交易都是按照 SafeTx 元交易格式形成的。在这95%的交易中，只有15.5%是代理调用（其中 SafeTx.operation = 1），显示出执行的安全交易绝大多数是常规调用 SafeTx 元交易。

分析中的常规调用（操作=0）与代理调用（操作=1）对比。

此外，在15.5%的代理调用中，99%以上的情况下，代理调用针对的是官方安全可信库合约。最常用的包括：

安全：MultiSendCallOnly 1.3.0（使用最广，86.2%的案例）
安全：MultiSend 1.3.0（10.1%的案例）
安全：SignMessageLib
安全：MultiSend 1.1.1

SafeTx.data 选择器分析

所进行的分析显示，分析的所有 SafeTx 交易中有58.5%是简单的 ERC-20 代币转账或 ETH 转移。在这些情况下，元交易数据易于验证。

所有分析过的 SafeTx 的 SafeTx.data 选择器。

SafeTo.to 地址分析

通过分析 SafeTx.to 地址，我们可以识别出调用频率最高的合约。在超过33%的情况下，当 SafeTx.operation = 0 时，所调用的合约是 ERC-20 代币，USDC 或 USDT 是最常见的类型。

对所有分析过的 SafeTx 的 safeTx.to 地址的分析。

已知攻击

2024年7月18日 — WazirX — 2.35亿

签署者被诱骗签署 SafeTx.operation = 1，将实现升级至恶意实现。

交易：https://app.blocksec.com/explorer/tx/eth/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d?line=0

反编译的恶意实现：https://app.dedaub.com/ethereum/address/0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2/decompiled

2024年10月16日 — Radiant Capital — 5300万

Radiant 报告称⁷ 其设备通过 DPRK 演员冒充承包商的方式，例如利用恶意 PDF 进行感染。签署者被诱骗签署一个将协议所有权转移到恶意地址的 SafeTx。

交易：https://app.blocksec.com/explorer/tx/arbitrum/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1

2025年2月21日 — Bybit — 14.3亿

一次高度复杂的针对DPRK黑客的定向攻击涉及改编 Secure{Wallet} 机构，加上在撰写此文时，注入了针对所利用的 Bybit 安全智能账户的恶意有效载荷。签署者被诱骗签署 SafeTx.operation = 1 交易，升级合约至恶意实现。黑客使用的一个把戏是将 SafeTx.data 的前四个字节设置为匹配ERC-20 transfer调用的选择器，使其看起来像是合法的代币转账。然而，SafeTx.to 指向恶意实现。

交易：https://app.blocksec.com/explorer/tx/eth/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882?line=5

反编译的恶意实现：https://app.dedaub.com/ethereum/address/0x96221423681a6d52e184d440a8efcebb105c7242/decompiled