Safe智能账户模块守卫上下文数据传递方案探讨

背景介绍

Safe智能账户项目在开发过程中遇到了一个关于模块守卫(Module Guard)功能的设计问题。模块守卫作为Safe账户安全机制的重要组成部分，负责验证由模块发起的交易。然而当前实现中，模块守卫在执行检查时无法获取交易相关的上下文信息，这限制了其功能的灵活性。

问题分析

在解决具体问题(如负控制场景下的共同签名验证)时，开发团队发现模块守卫缺乏获取额外上下文数据的能力。当前的模块守卫接口仅接收基本交易参数(目标地址、金额、数据、操作类型和模块地址)，无法满足某些高级验证场景的需求。

解决方案探讨

团队提出了三种主要解决方案，各有优缺点：

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

此方案通过在模块守卫的检查函数中增加上下文参数，并在Safe合约中新增支持上下文的重载函数来实现。

优点：

• 模块守卫接口尚未正式发布，修改不会影响现有部署
• 对Safe合约的修改保持向后兼容

缺点：

• 增加Safe合约代码大小(但仍保持在24KB限制内)
• 需要模块开发者适配新接口

方案二：预执行设置上下文信息

此方案利用模块守卫自身的存储(或临时存储)来保存上下文信息。在执行模块交易前，Safe账户通过单独交易或多重发送方式将上下文信息存入守卫。

优点：

• 无需修改Safe核心合约

缺点：

• 守卫需要实现额外的存储管理逻辑
• 增加存储读写带来的gas成本
• 需要额外的预执行调用

方案三：模块自行管理上下文

此方案由模块自行存储上下文信息，守卫通过调用模块接口获取所需上下文。

优点：

• 无需修改Safe合约

缺点：

• 需要模块实现特定接口
• 增加存储访问的gas成本
• 模块与守卫需要约定协议

技术评估与决策

经过深入讨论，团队认为：

1. 上下文需求目前仅出现在特定用例(如负控制)中，尚不具备普遍性
2. 通过多重发送等现有机制已能实现上下文传递
3. 引入标准化上下文协议可能增加开发者复杂度和审计难度
4. 类似功能可通过ERC7579等现有标准实现

基于以上考量，团队决定不修改Safe核心合约，也不强制要求守卫或模块实现特定接口。对于需要上下文验证的特定用例，建议采用方案二的变体(通过多重发送设置守卫上下文)或直接在模块内部实现验证逻辑。

结论

Safe智能账户项目在模块守卫上下文传递问题上进行了全面评估，最终选择了保持核心合约稳定性的方案。这一决策体现了项目对向后兼容性和开发者体验的重视，同时也为特定用例提供了可行的替代实现路径。