原文标题：《慢雾解析｜Safe 困局，Guard 能否重构契约巴别塔？》原文作者：flush & kong，慢雾科技
背景
2025 年 2 月 21 日，加密货币行业遭遇史上最严重的资产管理危机。交易平台 Bybit 的链上多签钱包遭定向攻破，近 15 亿美元资产通过一笔「合法签名」的交易悄然流失。事后链上分析显示，攻击者通过精密的社会工程攻击获取了多签权限，利用 Safe 合约的 delegatecall 功能植入恶意逻辑，最终绕过多重签名验证机制，将资金转移至匿名地址。
此次事件暴露出一个残酷现实：「多重签名」不等于「绝对安全」，即便是 Safe 多签钱包这样的安全机制，如果缺乏额外的防护措施，仍然存在被攻破的风险。这也并非首个针对 Safe 多签钱包的攻击案例。去年 WazirX（损失 2.3 亿美元）和 Radiant Capital（损失 5,000 万美元）都遭遇了类似的攻击手法。正如慢雾：Bybit 近 15 亿美元被盗背后的黑客手法与疑问一文中的分析，Safe 多签钱包攻击事件呈现出以下技术同源性：
过度依赖签名机制：将安全责任都交给私钥保管。
动态防御缺失：缺乏交易执行前的实时风险扫描。
权限控制粗粒度：未对 delegatecall 等高风险操作建立白名单机制。
(Bybit 被盗流程：使用 Safe v1.1.1)
这一系列事件的核心问题不在于 Safe 合约本身，而是在于整个系统的集成过程中的安全隐患，特别是在前端验证环节。这促使我们需要思考：如何通过 Safe 的额外安全措施机制来强化多签钱包的防护能力？
Safe
Safe 是一款多重签名 (Multi-Sig) 钱包，主要用于管理高价值资产和数字货币的安全存储与转移。作为去中心化资产管理的基础设施，它通过多方协同验证机制确保资金操作的安全性，防止单一管理员或黑客利用单点故障进行恶意操作，广泛应用于 DAO 治理、企业资金托管、去中心化基金池等场景。该合约由 Safe（原 Gnosis Safe）团队开发，是当前行业标准的链上资产管理解决方案。合约采用 EIP-712 标准实现结构化数据签名，从而提高交易数据的安全性和可验证性。
核心用途
资金安全管理：合约要求多个预先设定的所有者 (Owners) 共同确认交易才能执行，从而有效防止单点失误或恶意操作，确保资金安全。
交易执行与管理：通过内置的多签验证机制，合约能够在满足签名阈值条件的情况下，执行对外转账、调用其他合约或处理复杂的业务逻辑，支持代币和原生币的支付和费用补偿。
模块化扩展：合约采用模块化设计，通过继承和组合多个管理模块（如 OwnerManager、ModuleManager、GuardManager、FallbackManager 等），使其功能灵活且易于扩展，为不同应用场景提供定制化支持。
函数解析
execTransaction 函数执行经过多重签名验证的交易：
· 计算交易的唯一哈希值（结合交易参数、nonce 等）；
· 验证所有签名的有效性，确保每个签名均来自合法的所有者或预先批准的地址；
· 调用目标地址的业务逻辑，并在交易执行后通过事件记录成功或失败状态；
· 支持灵活的 gas 费用处理，确保在支付补偿时准确计算交易成本。
checkContractSignatures & checkNSignatures 函数验证交易或消息的签名数据：
· 分别处理 EOA 账户签名、合约签名 (EIP-1271)、以及预批准的哈希；
· 确保签名按照所有者顺序排列，并且每个签名都来自有效地址，防止重放攻击和签名篡改。
getTransactionHash 函数生成交易哈希，用于签名验证和防止重放攻击：
· 利用 EIP-712 标准对交易数据进行结构化哈希；
· 使用内联汇编优化内存操作，提高计算效率；
· 结合当前的 nonce 值，确保每笔交易的唯一性。
handlePayment 函数处理执行交易过程中的 gas 补偿支付：
· 根据实际消耗的 gas 费用和基础费用计算支付金额；
· 支持 ETH 以及其他代币的支付，确保费用补偿准确无误。
onBeforeExecTransaction 为内部虚拟钩子函数，在 execTransaction 函数执行之前被调用。该函数的设计目的是允许继承 Safe 合约的子合约在交易执行前进行自定义逻辑处理。接收的参数集包括：
· to：目标地址 – 交易要调用的合约或账户地址
· value：以太币值 – 随交易发送的以太币数量
· data：数据载荷 – 包含函数选择器和参数的调用数据
· operation：操作类型 – 确定是 CALL 还是 DELEGATECALL
· safeTxGas：交易 gas 限制 – 为交易执行预留的 gas 数量
· baseGas：基础 gas – 独立于交易执行的 gas 成本
· gasPrice：gas 价格 – 用于计算交易费用补偿的 gas 价格
· gasToken：gas 代币 – 用于支付交易费用的代币地址
· refundReceiver：退款接收者 – 接收交易费用补偿的地址
· signatures：签名集合 – 所有者对交易的签名数据
尽管多签钱包合约凭借其严谨的安全设计和灵活的模块化结构，为数字资产管理提供了高效且安全的解决方案，实现了从交易初始化到最终执行的全流程安全管控，并成为区块链安全管理的重要工具，但同样需要注意的是，受害者大多依赖硬件钱包进行签名，而部分硬件设备对结构化数据签名的显示效果欠佳，容易导致用户在短时间内无法准确识别交易数据，从而有「盲签」风险。针对这一现象，除了优化硬件及其数据展示效果之外，还可以探索增加多重确认、智能提示以及增强签名验证工具等措施，以进一步降低盲签带来的安全隐患。
Safe Guard
Safe 合约在 1.3.0 版本中引入的重要安全功能——Safe Guard 机制。这一机制旨在为标准的 n-out-of-m 多签方案提供额外的限制条件，进一步增强交易安全性。Safe Guard 的核心价值在于能够在交易执行的不同阶段进行安全检查：
· 交易前检查 (checkTransaction)：Guard 机制可以在交易执行前，对交易的所有参数进行程序化检查，确保交易符合预设的安全规则。
· 交易后检查 (checkAfterExecution)：在交易执行完成后，Guard 还会进行额外的安全验证，检查交易执行后 Safe 钱包的最终状态是否符合预期。
架构分析
(当使用 Safe 版本 ≥ v1.3.0 Safe Guard 模块的验证操作 https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)
总的来说，Safe 仅在 1.3.0 版本之后才提供 Guard 功能，尽管 Guard 可以提供极为细粒度的多签交易检查，但用户在使用 Guard 功能时有较大的门槛。他们需要自行实现 Guard 检查逻辑，粗略的或者有缺陷的 Guard 实现可能无法帮助用户提升其 Safe 钱包的安全性，因此对 Guard 实现进行安全审计是必要的。毫无疑问的是，安全且适当的 Guard 实现可以极大提升 Safe 钱包的安全性。
结论与展望
Bybit 被攻击事件凸显了及时更新安全基础设施的重要性，Bybit 使用的是 v1.1.1 (<1.3.0) 版本的 Safe 合约，这意味着他们无法使用 Guard 机制这一关键安全特性。如果 Bybit 升级到 1.3.0 或更高版本的 Safe 合约，并实现了合适的 Guard 机制，例如指定唯一接收资金的白名单地址，并进行严格的合约函数 ACL 验证，可能就能避免这次的损失。尽管这只是假设，但它为未来的资产安全管理提供了重要思路。
Safe Guard 机制就像给数字资产保险箱加装的智能安检系统，其效能取决于规则设计的严谨性和实施质量。面对日益精密的攻击手段，我们需要：
· 自动化验证：建立自动化的交易验证机制
· 动态策略调整：根据威胁情报实时调整安全策略
· 多层防御：结合多种安全机制构建深度防御体系
· 持续审计：对 Guard 实现进行定期安全审计
未来的数字资产管理，将是智能合约安全机制与持续攻防演进的共同进化过程。只有将安全理念融入每一个环节，才能在黑客的”矛”与守护者的”盾”的博弈中构筑真正的安全壁垒。
