Safe 困局 Guard 能否重构契约巴别塔？

作者：flush&kong背景

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

这一系列事件的核心问题不在于Safe合约本身，而是在于整个系统的集成过程中的安全隐患，特别是在前端验证环节。这促使我们需要思考：如何通过Safe的额外安全措施机制来强化多签钱包的防护能力？Safe

Safe是一款多重签名(Multi-Sig)钱包，主要用于管理高价值资产和Crypto的安全存储与转移。作为去中心化资产管理的基础设施，它通过多方协同验证机制确保资金操作的安全性，防止单一管理员或黑客利用单点故障进行恶意操作，广泛应用于DAO治理、企业资金托管、去中心化基金池等场景。该合约由Safe（原GnosisSafe）团队开发，是当前行业标准的链上资产管理解决方案。合约采用EIP-712标准实现结构化数据签名，从而提高交易数据的安全性和可验证性。核心用途

资金安全管理：合约要求多个预先设定的所有者(Owners)共同确认交易才能执行，从而有效防止单点失误或恶意操作，确保资金安全。

交易执行与管理：通过内置的多签验证机制，合约能够在满足签名阈值条件的情况下，执行对外转账、调用其他合约或处理复杂的业务逻辑，支持Tokens和原生币的支付和费用补偿。

模块化扩展：合约采用模块化设计，通过继承和组合多个管理模块（如OwnerManager、ModuleManager、GuardManager、FallbackManager等），使其功能灵活且易于扩展，为不同应用场景提供定制化支持。

函数解析

execTransaction函数执行经过多重签名验证的交易：

计算交易的唯一哈希值（结合交易参数、nonce等）；

验证所有签名的有效性，确保每个签名均来自合法的所有者或预先批准的地址；

调用目标地址的业务逻辑，并在交易执行后通过事件记录成功或失败状态；

支持灵活的gas费用处理，确保在支付补偿时准确计算交易成本。

checkContractSignatures&checkNSignatures函数验证交易或消息的签名数据：

分别处理EOA账户签名、合约签名(EIP-1271)、以及预批准的哈希；

确保签名按照所有者顺序排列，并且每个签名都来自有效地址，防止重放攻击和签名篡改。

getTransactionHash函数生成交易哈希，用于签名验证和防止重放攻击：

利用EIP-712标准对交易数据进行结构化哈希；

使用内联汇编优化内存操作，提高计算效率；

结合当前的nonce值，确保每笔交易的唯一性。

handlePayment函数处理执行交易过程中的gas补偿支付：

根据实际消耗的gas费用和基础费用计算支付金额；

支持ETH以及其他Tokens的支付，确保费用补偿准确无误。

onBeforeExecTransaction为内部虚拟钩子函数，在execTransaction函数执行之前被调用。该函数的设计目的是允许继承Safe合约的子合约在交易执行前进行自定义逻辑处理。接收的参数集包括：

to：目标地址-交易要调用的合约或账户地址

value：以太币值-随交易发送的以太币数量

data：数据载荷-包含函数选择器和参数的调用数据

operation：操作类型-确定是CALL还是DELEGATECALL

safeTxGas：交易gas限制-为交易执行预留的gas数量

baseGas：基础gas-独立于交易执行的gas成本

gasPrice：gas价格-用于计算交易费用补偿的gas价格

gasToken：gasTokens-用于支付交易费用的Tokens地址

refundReceiver：退款接收者-接收交易费用补偿的地址

signatures：签名集合-所有者对交易的签名数据

尽管多签钱包合约凭借其严谨的安全设计和灵活的模块化结构，为数字资产管理提供了高效且安全的解决方案，实现了从交易初始化到最终执行的全流程安全管控，并成为Blockchain安全管理的重要工具，但同样需要注意的是，受害者大多依赖硬件钱包进行签名，而部分硬件设备对结构化数据签名的显示效果欠佳，容易导致用户在短时间内无法准确识别交易数据，从而有“盲签”风险。针对这一现象，除了优化硬件及其数据展示效果之外，还可以探索增加多重确认、智能提示以及增强签名验证工具等措施，以进一步降低盲签带来的安全隐患。SafeGuard

Safe合约在1.3.0版本中引入的重要安全功能——SafeGuard机制。这一机制旨在为标准的n-out-of-m多签方案提供额外的限制条件，进一步增强交易安全性。SafeGuard的核心价值在于能够在交易执行的不同阶段进行安全检查：

交易前检查(checkTransaction)：Guard机制可以在交易执行前，对交易的所有参数进行程序化检查，确保交易符合预设的安全规则。

交易后检查(checkAfterExecution)：在交易执行完成后，Guard还会进行额外的安全验证，检查交易执行后Safe钱包的最终状态是否符合预期。

架构分析

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

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

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

(当使用Safe版本≥v1.3.0 SafeGuard模块的验证操作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验证，可能就能避免这次的损失。尽管这只是假设，但它为未来的资产安全管理提供了重要思路。

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

自动化验证：建立自动化的交易验证机制

动态策略调整：根据威胁情报实时调整安全策略

多层防御：结合多种安全机制构建深度防御体系

持续审计：对Guard实现进行定期安全审计

未来的数字资产管理，将是智能合约安全机制与持续攻防演进的共同进化过程。只有将安全理念融入每一个环节，才能在黑客的"矛"与守护者的"盾"的博弈中构筑真正的安全壁垒。