Safe智能合约中模块守卫上下文数据传递方案探讨

背景介绍

在Safe智能合约的模块管理系统中，模块守卫(Module Guard)是一个重要的安全组件，它负责验证模块发起的交易。然而，当前模块守卫接口存在一个限制：它无法接收任何额外的上下文信息或数据，这在一定程度上限制了其功能的灵活性。

问题分析

在实现负控制(Negative Control)功能时，开发团队发现模块守卫需要验证共同签名者的签名信息，但现有的接口设计无法传递这些额外数据。这引发了对模块守卫接口扩展性的深入思考：是否需要为模块守卫提供接收上下文数据的能力？如果需要，应该如何设计这个功能？

技术方案比较

方案一：修改Safe合约及模块守卫接口

该方案通过在模块守卫的checkModuleTransaction函数中添加context参数，并在Safe合约中新增支持上下文参数的重载函数。

优点：

• 模块守卫接口尚未正式发布，修改不会造成兼容性问题
• 对现有Safe合约保持向后兼容
• 实现直接且直观

缺点：

• 增加Safe合约的大小（但仍保持在24kb限制内）
• 需要模块适配新接口才能使用此功能

方案二：执行前设置守卫上下文

此方案通过让模块守卫提供设置上下文的方法，在执行模块交易前存储上下文信息。

优点：

• 无需修改Safe合约
• 实现相对灵活

缺点：

• 模块守卫需要额外实现上下文存储逻辑
• 增加gas成本
• 需要在交易执行前单独调用守卫设置上下文

方案三：模块自行存储上下文

该方案让模块自行存储上下文信息，守卫通过模块接口获取所需数据。

优点：

• 无需修改Safe合约
• 上下文管理完全由模块控制

缺点：

• 模块需要实现额外接口
• 增加gas成本
• 模块与守卫需要约定数据协议

专家评估与结论

经过深入讨论和技术评估，Safe团队认为：

1. 上下文需求目前主要局限于特定用例（如负控制），尚不具备普遍性
2. 通过Multisend方式已经可以实现上下文传递，无需修改核心合约
3. 强制性的接口标准化可能增加开发复杂度和审计难度
4. 特定功能可以通过共享库或ERC7579标准实现，保持核心合约简洁

因此，团队决定不修改Safe合约或引入新的协议强制要求守卫或模块实现特定接口。这种决策保持了系统的简洁性和灵活性，同时为特定用例提供了替代解决方案。

技术启示

这个案例展示了区块链系统设计中常见的权衡：在增加功能灵活性和保持系统简洁性之间的选择。Safe团队选择了保守的方案，这体现了其对系统稳定性和安全性的重视，同时也为未来的扩展留下了空间。开发者在使用Safe模块系统时，应当根据具体需求选择最适合的上下文传递方式，必要时可以利用共享库或行业标准来实现特定功能。