Safe智能账户迁移合约的通用化改进

背景与问题分析

在Safe智能账户项目中，从1.3.0版本到1.4.1版本的迁移合约存在一个设计限制：它通过检查目标合约的地址来验证迁移的有效性。具体来说，迁移合约要求目标合约必须是预定义的Safe或SafeL2合约地址之一。

这种设计在常规EVM链上运行良好，但在zkSync等Layer2解决方案中却遇到了问题。由于zkSync的特殊架构，部署的Safe合约地址与主网不同，导致现有的地址验证机制无法正常工作。

解决方案探讨

针对这一问题，开发团队提出了三种可能的解决方案：

1. 通用迁移库合约方案：创建一个不检查目标地址的通用迁移库合约，完全移除地址验证机制。

2. 代码哈希验证方案：改用目标合约的代码哈希进行验证，而非地址验证。通过比较目标合约的运行时字节码哈希与预定义的Safe/SafeL2合约哈希值来确保安全性。

3. 扩展地址白名单方案：在现有地址验证机制基础上，增加对zkSync特定地址的支持。

经过技术评估，团队最终选择了代码哈希验证方案，因为它既保持了安全性，又提供了更好的兼容性。

技术实现细节

在具体实现上，代码哈希验证方案采用了以下技术手段：

1. 预计算合约哈希：在合约部署时预先计算Safe和SafeL2合约的标准代码哈希值。

2. 运行时验证：在迁移函数中，通过extcodehash操作码获取目标合约的代码哈希，与预存的标准哈希值进行比较。

3. 多重验证支持：可以同时支持多个版本的合约哈希验证，只需扩展预存的哈希值列表即可。

这种方法的优势在于：

• 不依赖于特定链的部署地址
• 能准确识别合约的实际功能，而不仅仅是部署位置
• 对合约升级和跨链部署更加友好

安全考量

虽然移除了地址验证，但代码哈希验证同样能确保安全性：

1. 合约真实性保证：只有与标准Safe合约完全一致的字节码才能通过验证。

2. 防篡改性：即使攻击者知道标准合约的代码哈希，也无法在不改变功能的情况下生成匹配的替代合约。

3. 可扩展性：可以轻松添加对新版本合约的支持，只需扩展哈希值列表。

最佳实践建议

对于开发者使用迁移合约，建议：

1. 测试环境验证：在正式迁移前，先在测试网络上验证迁移流程。

2. 多重签名确认：对于重要账户的迁移，应使用多重签名机制进行确认。

3. 监控与回滚准备：准备好在迁移出现问题时能够回滚的方案。

总结

Safe智能账户项目通过引入代码哈希验证机制，解决了原有迁移合约在zkSync等Layer2网络中的兼容性问题。这一改进不仅解决了当前的技术障碍，还为未来的多链扩展奠定了基础，体现了项目团队对兼容性和安全性的双重重视。