注：

• 仅作技术交流，禁止商用
• 如有侵权，请联系删除

目录

背景

• 项目的部分工作账户需要使用多签钱包进行资金管理，最大限度避免账号被盗和个人作恶
• gnosis safe作为著名的多签钱包，其所有组件均开源，适合分析

gnosis safe多签钱包构成

• 链上合约
  • safe.sol和safel2.sol
• web2服务
  • gateway Service, transaction Service, config Service
• client端入口
  • ios app, android app, web

gnosis safe多签交易时序

• gnosis safe多签交易时序（2/3）.png

gnosis safe web2服务架构

• gnosis safe web2服务架构图.png

gnosis safe多签合约分析

• to be continued

gnosis safe web2服务分析

• gateway - to be continued
• transaction service - to be continued
• config service - to be continued

gnosis safe多签钱包重要特性

使用线下签名的方式进行多签，减少gas费用消耗

和常规多签钱包(2/3)的区别

• 常规多签：管理员1和2的每次 “同意” 都发送到链上合约
  • 2次合约交互
• gnosis safe多签：管理员1,2的每次同意都以线下签名的方式记录在web2服务中，由web2服务判断满足阈值要求之后把 2个管理员的 “同意的签名” 发送到链上合约
  • 1次合约交互，仅最后同意的管理员支付gas费用

优点

• 节省gas费用
• 多签交易内容直到提交时才上链，隐私性好

缺点

• 需要依赖web2服务进行线下签名信息的暂存和中转

已发出的交易无法撤销和拒绝

• 即某个nonce值一旦被签名，就必须被执行

• 时序：
  拒绝多签交易的时序

• 构造场景：管理员1发起并同意交易a, 管理员2不同意

  • 管理员2需要点击replace按钮（而不是reject）, 重新构造相同nonce值的另一笔交易，比如transferTo0
  • 管理员2发起该笔相同nonce值的新交易
  • 管理员3在app中看到相同nonce值的2笔交易
    • 管理员1发起的，管理员2发起的
  • 管理员3同意管理员2发起的交易
  • 管理员2发起的交易得到执行，管理员1发起的交易被自动删除

完善的交易通知功能

• 已有交易状态变更时，会在app和web端均进行消息推送

整体架构对web2服务依赖较大，若web2服务宕机会导致用户无法操作账户

• 通过web2服务进行交易消息通知和广播
• 通过web2服务进行签名数据的暂存
• 交易的propsal, confirm, execute, replace等均需要依赖web2服务
  • 也有解决方案：直接访问链上合约
    • 重新收集各个管理员的线下签名（因为web2服务宕机无法获取暂存的签名数据）
    • 编写代码，对对应的链上多签合约发起交易

不支持交易附言的功能

• 管理员只能看到该笔交易的链上信息，不能设置和查看自定义附言
  • 普通交易：转账的对象和金额
  • 合约交易：合约函数和各个参数

交易必须严格按顺序执行

• 要求nonce值必须连续
• 构造场景：当前有效nonce值为5， 此时发起了一个nonce值为8的多签交易，该交易就算所有人都同意也无法执行。
  • 必须等6,7的nonce值的交易执行完毕之后才行

• 示例图

  
  
  nonce值为5558的交易被2个管理员同意，但是因为nonce值=13的交易还未被执行，所以无法执行