ERC4337 审计检查清单

ERC4337 审计检查清单

检查清单

一般

• [x] 审计的合约与 Infinitism 的示例合约 有何不同？
• [x] 项目是否可以在目标 EVM 兼容链上部署，例如通过正确版本的 Solidity 编译器？
  • Code4rena/Ambire/M-04: 项目可能无法部署到不兼容上海硬分叉的链
  • Infinitism 示例中没有问题
• [x] 组件是否支持最新的 EntryPoint 合约？

钱包账户工厂

• [x] 是否使用 CREATE2 创建钱包？
  • ERC-4337: 工厂预期使用 CREATE2 (而不是 CREATE) 来创建钱包
  • Infinitism 示例中没有问题
• [x] 即使钱包已被创建，是否仍然返回钱包账户地址？
  • ERC-4337: 如果工厂确实使用 CREATE2 或其他确定性方法创建钱包，预期即使钱包已经创建，它也应返回钱包地址。
  • Infinitism 示例中没有问题
• [x] 攻击者是否可以通过代表其拥有者部署钱包账户来控制钱包账户？
  • ERC-4337: 出于安全原因，生成的合约地址必须依赖初始签名。这样，即使有人可以在该地址创建钱包，他也无法设置不同的凭据来控制它。
  • Code4rena/Biconomy/H-03: 攻击者可以控制反事实钱包
  • Code4rena/Ambire/L-01: AmbireAccountFactory.deploySafe() 并不能保证没有对已部署合约的调用
  • Infinitism 示例中没有问题
• [x] 工厂是否允许任何人向入口点添加质押？如果是这种情况，unstakeDelay 可能无法更改，否则可能会设置为高值，导致无法撤销质押。

钱包账户

• [x] 钱包账户实现合约是否可以被攻击者初始化，例如通过前置抢购？
  • Code4rena/Biconomy/H-01: SmartAccount 实现被销毁
  • Code4rena/Ambire/M-05: AmbireAccount 实现可以通过特权被销毁
  • Infinitism 示例中没有问题
• [x] 钱包账户能否在未经 EntryPoint 的情况下执行交易，如果可以，访问控制和签名验证是否正确实施？
  • Code4rena/Biconomy/H-04: 由于签名验证不足，可能进行任意交易
  • Code4rena/Ambire/M-03: 可恢复交易在取消后可以重放
  • Code4rena/Ambire/L-02: 回退处理程序不应被允许这样
  • Code4rena/Ambire/L-16: 针对未来随机数签名的交易组合无法取消
  • ZeroDev/Kernel/ZeroDev-wallet-02: Kernel 的 validateUserOp 上可以进行签名重放攻击
  • ZeroDev/Kernel/ZeroDev-wallet-05: 会话验证中的操作类型的验证不完整
  • Infinitism 示例中没有问题
• [x] 钱包账户是否使用不同的签名验证方案，且是否正确实施？
  • ERC-4337: 如果账户不支持签名聚合，它必须验证签名是 userOpHash 的有效签名，并且在签名不匹配时应返回 SIG_VALIDATION_FAILED (而不是回滚)。任何其他错误都应回滚。
  • Code4rena/Ambire/L-03: Schnorr 签名验证可能与预期的签名者不兼容
  • Code4rena/Ambire/L-04: Schnorr 签名长度未检查
  • Code4rena/Ambire/L-15: require(sp != 0); 未能保护 Schnorr 签名验证
  • Infinitism 示例中没有问题
• [x] 钱包账户是否实现了 ERC-1271，如果是，可以在账户之间共享“拥有者”吗？
  • 在大多数简单的 isValidSignature() 实现中（例如，检查 某个 拥有者是否签署了 bytes32 hash），签名可能会在具有共享拥有人之间重放。哈希需要由账户修改（例如，使用 EIP-712），以便签名 仅对特定钱包有效 only valid for a specific wallet。
  • Safe 合约中的正确实现
• [x] 钱包是否仅访问与发送者关联的存储字段？否则， 标准打包器 将不支持它
• [x] 钱包是否基于代理？如果是，使用了哪种代理？如果是 ERC1967Proxy，是否符合标准？
  • Infinitism 示例中没有问题
• [x] 智能合约账户是否可以转换为另一种类型的智能合约账户（通过代理模式）？可否 重用 可初始化的存储插槽？
• [x] 钱包账户是否支持模块？如果是，支持什么类型？是否符合规范（例如，如果使用 delegatecall，则没有存储插槽重叠）？审核模块的过程是什么？登记模块的过程是什么？
  • 基于 delegatecall
  • ZeroDev
  • Diamond Pattern EIP-2535
  • Safe
  • 基于 call
  • EIP-6900
  • Universal Profile (略有不同)
• [x] 钱包是否支持会话密钥？
  • Biconomy
  • ZeroDev, 参考
  • MatchboxDAO

Paymaster

• [x] VerifyingPaymaster 签名是否可以被重放？
  • Code4rena/Biconomy/H-05: 付款者的签名可以被重放以耗尽其存款
  • Code4rena/Biconomy/M-03: 跨链签名重放攻击
  • Infinitism 示例中没有问题 Infinitism 示例中没有问题
• [x] postOp() 函数中是否可能出现任意错误消息？
  • 在 v0.6 入口点中存在一个 错误，导致短的回滚消息处理不当。这意味着初始的 postOp() 调用中的回滚可能会回滚整个包，尽管预期会进行第二次 postOp() 调用。

打包器

• [x] 它是否实现了 eth_sendRawTransactionConditional 以支持 L2？（参考：以太坊基金会，Optimism，Arbitrum，Polygon）

签名验证器

• [x] 是否正确验证用户操作中的正确气体数量的用户签名？ 参考

其他链

• [x] 链是否（计划）支持 RIP-7560

应用程序

• [x] 应用程序是否使用 ERC-6492: 针对预部署合约的签名验证？如果是，它们是否符合标准？
• [x] 应用程序是否不依赖 tx.origin 进行签名检查？
• [x] 应用程序是否始终使用气体估算，而不是依赖特定成本的假设（例如 transfer 的固定成本为 21000）？
• [x] 应用程序是否支持批量处理（不是必需的，但可以大大改善用户体验）？
• [x] 应用程序是否支持付款者（例如，用正在转换的代币支付Gas）？

资源

ERC

• ERC-4337: 使用 Alt Mempool 的账户抽象

审计

• EIP-4337 – 以太坊账户抽象审计
• EIP-4337 – 以太坊账户抽象增量审计
• Biconomy - 智能合约钱包竞赛发现与分析报告
• Ambire 钱包 - 邀请性发现与分析报告
• ZeroDev 钱包内核安全评估

出版物

• 通向账户抽象的道路
• ERC 4337: 通过入口点合约规范的账户抽象
• ERC 4337: 无需以太坊协议更改的账户抽象
• ERC-4337 & 账户抽象：全面概述
• 深入探讨 ERC-4337 的主要组成部分：使用 Alt Mempool 的账户抽象 — 第 1 部分
• 深入探讨 ERC-4337 的主要组成部分：使用 Alt Mempool 的账户抽象 — 第 2 部分
• 深入探讨 ERC-4337 的主要组成部分：使用 Alt Mempool 的账户抽象 — 第 3 部分
• 深入探讨 ERC-4337 的主要组成部分：使用 Alt Mempool 的账户抽象 — 第 4 部分
• 智能账户安全：审计账户抽象
• ChainLight 补丁星期四 - 账户抽象安全指南
• 账户抽象：审计员的安全指南
• 统一的 ERC-4337 内存池
• 关于 ERC4337 和智能钱包的安全提示
• Cardex 事件后分析（共享会话签名者钱包在前端暴露）

• 原文链接： github.com/aviggiano/sec...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～