深度解析Safe困局：Guard 能否重构契约巴别塔？

2025年2月21日，加密货币行业遭遇史上最严重的资产管理危机。某交易平台的链上多签钱包遭定向攻破，近15亿美元资产通过一笔"合法签名"的交易悄然流失。事后链上分析显示，攻击者通过精密的社会工程攻击获取了多签权限，利用Safe合约的delegatecall功能植入恶意逻辑，最终绕过多重签名验证机制，将资金转移至匿名地址。

此次事件暴露出一个残酷现实："多重签名"不等于"绝对安全"，即便是Safe多签钱包这样的安全机制，如果缺乏额外的防护措施，仍然存在被攻破的风险。这也并非首个针对Safe多签钱包的攻击案例。去年两家知名交易所分别损失2.3亿美元和5,000万美元，都遭遇了类似的攻击手法。Safe多签钱包攻击事件呈现出以下技术同源性：

• 过度依赖签名机制：将安全责任都交给私钥保管。
• 动态防御缺失：缺乏交易执行前的实时风险扫描。
• 权限控制粗粒度：未对delegatecall等高风险操作建立白名单机制。

这一系列事件的核心问题不在于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中，多签交易一般通过execTransaction函数进行执行。在Safe Guard启用的情况下，当用户执行多签交易时，Safe合约将调用Guard合约的checkTransaction函数执行交易前检查，而当多签交易执行完成后，Safe合约将调用Guard合约的checkAfterExecution函数对交易的执行结果进行检查。

当Safe合约通过Guard机制执行多签交易预检时，其checkTransaction函数将接收完整的交易上下文数据，包括目标合约地址、调用方式、执行数据（如delegatecall）、owner签名信息、Gas配置及支付信息。该机制使开发者能够实现多维度的风控策略，例如合约白名单管控（限制可交互地址）、函数级权限管理（禁用高危函数选择器）、交易频率限制以及基于资金流向的动态规则等。通过合理配置Guard策略，可有效阻断攻击者利用非合约层面进行攻击。

在近期不断曝出安全事件的背景下，各方对多签钱包合约的安全性日益关注，硬件钱包提供商纷纷呼吁增强Safe合约的解析和防护能力，以预防类似风险的再次发生。在某交易平台事件后，许多项目方开始聚焦Safe合约，并探索基于Guard机制的升级与扩展方案。其中，不乏有基于Guard机制的创新应用，构建一种建立在Safe多签钱包之上的中间层安全解决方案，为底层资产与用户资产之间提供了额外的安全保障。其核心作用在于，通过将Safe多签交易涉及的目标合约、调用方式、执行数据、owner签名信息、付款信息以及gas信息传入checkTransaction函数，实现对交易的极细粒度检查，包括白名单合约调用、白名单函数操作、白名单转账目标、交易频次等权限控制。

值得注意的是，Safe本身只提供Guard管理和回调功能，实际的多签交易检查逻辑由用户自行实现，其安全性取决于Guard实现的质量。如：某安全解决方案拓展了这一思路，在每个Vault配置专门的Guardian来指定允许的目标地址和操作权限，实现了指定允许合约、定义允许函数操作和ACL验证需求三大权限控制要素。同时，采用分离的治理机制，由Vault Guardian负责执行，而Governor控制治理权限，确保即便Guardian出现问题，也能及时采取补救措施保护用户资产。类似的设计理念也在另一个安全模块中得到应用，该模块通过preExecute函数拦截关键操作，并借助白名单机制对模块安装、钩子设置和验证器管理等高风险操作进行精细管控，从而确保只有经过信任的合约才能被添加到系统中，为钱包提供了持久的安全保障。

在某交易平台事件攻击链中，若Safe合约部署了合理配置的Guard机制，攻击者通过execTransaction发起的恶意delegatecall将在预检阶段被多重策略拦截：Guard的checkTransaction函数首先识别到delegatecall操作类型并触发禁用规则（如强制限定operation仅为普通调用），随后解析data字段检测到非常规合约地址及高危函数选择器，通过预设的合约白名单与函数黑名单策略直接回滚交易，最终形成「策略拦截 → 逻辑阻断」的防御体系，彻底阻断存储篡改与资金转移路径。

总的来说，Safe仅在1.3.0版本之后才提供Guard功能，尽管Guard可以提供极为细粒度的多签交易检查，但用户在使用Guard功能时有较大的门槛。他们需要自行实现Guard检查逻辑，粗略的或者有缺陷的Guard实现可能无法帮助用户提升其Safe钱包的安全性，因此对Guard实现进行安全审计是必要的。毫无疑问的是，安全且适当的Guard实现可以极大提升Safe钱包的安全性。

结论与展望

某交易平台被攻击事件凸显了及时更新安全基础设施的重要性，该平台使用的是v1.1.1(<1.3.0)版本的Safe合约，这意味着他们无法使用Guard机制这一关键安全特性。如果该平台升级到1.3.0或更高版本的Safe合约，并实现了合适的Guard机制，例如指定唯一接收资金的白名单地址，并进行严格的合约函数ACL验证，可能就能避免这次的损失。尽管这只是假设，但它为未来的资产安全管理提供了重要思路。

Safe Guard机制就像给数字资产保险箱加装的智能安检系统，其效能取决于规则设计的严谨性和实施质量。面对日益精密的攻击手段，我们需要：

• 自动化验证：建立自动化的交易验证机制
• 动态策略调整：根据威胁情报实时调整安全策略
• 多层防御：结合多种安全机制构建深度防御体系
• 持续审计：对Guard实现进行定