Claude用7天搭建了我们的ERC-4337栈，主网上线前我们重写了这些

ancilartech 发布于 2026-05-30 阅读 117

Ancilar团队记录了一周内使用Claude Code开发生产级ERC-4337钱包栈的实战经验。

我们为何进行这个实验

我们想诚实地了解，在2026年，用 Claude 完成大部分编码工作，交付一个生产级 ERC-4337 钱包栈究竟需要多少成本。不是原型，不是演示，而是我们愿意将真实用户资金置于其后的东西。

概要：智能账户合约、账户工厂、支付主（paymaster）、捆绑器集成以及一个 TypeScript SDK。EVM 兼容，可上线主网，便于审计。使用 Claude Code 作为主要代码生成工具。高级工程师负责审查并最终决定是否发布。

我们给它一周时间。Claude 在第 4 天说完成了。实际发布日期是第 7 天。这是那三天内发生的事情记录。

第 1 天：架构与范围

团队在编写任何代码之前设置了仓库，定义了威胁模型，并规划了合约架构。Claude 根据规范生成了第一版架构文档，协议负责人重写了大约 30% 的内容。重写几乎集中在一个地方：信任边界。

Claude 提出的版本中，validateUserOp 会调用外部辅助合约进行签名检查。而我们发布的版本将签名验证完全内嵌到账户合约中。原因：validateUserOp 中的每一个外部调用，都可能成为恶意支付主、工厂或模块泄露 Gas、破坏执行或违反 ERC-7562 验证阶段规则的地方。该框架明确禁止在验证期间使用某些操作码，而外部调用会让合规性更难证明。

这种决策决定了你的钱包是能在公共 mempool 中工作，还是只能在私有捆绑器上运行。Claude 犯错并非因为能力不足，而是因为仅从规范中看不到这一约束。

第 2 天：智能账户合约

Claude 大约在两小时内生成了一个干净的 ERC-4337 账户合约。它编译通过，部署到本地分叉，基本的 UserOperation 流程也运行正常。从任何表面标准衡量，这部分都让人感觉像未来一样。

高级合约工程师仔细审查后发现三个问题未通过审查：

// 生成版本
function validateUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData) {
    bytes32 hash = userOpHash.toEthSignedMessageHash();
    address signer = hash.recover(userOp.signature);
    require(signer == owner, "invalid signature");
    if (missingAccountFunds > 0) {
        (bool success,) = payable(msg.sender).call{value: missingAccountFunds}("");
        require(success, "transfer failed");
    }
    return 0;
}

问题在于：

  1. 没有 EntryPoint 授权检查。 任何人都可以直接调用 validateUserOp，并诱使账户将 missingAccountFunds 转给攻击者。该函数必须拒绝来自非规范 EntryPoint 地址的调用。
  2. 签名没有绑定 EntryPoint 或链。 哈希仅基于 UserOp 字段计算，未包含 chain ID 和 EntryPoint 地址。相同的签名可以在不同分叉和 EntryPoint 升级中重放。
  3. 验证无条件返回 0。 返回值本应编码有效时间和有效至时间戳，用于限时会话。返回 0 会静默禁用该功能，而 SDK 已经在尝试使用它。

这些问题都在已发布的 ERC-4337 审计检查清单中有记载，但 Claude 的自我审查未能发现。协议负责人重写了这个函数。修复花了两个小时，包括为认证边界编写全新的测试套件。

第 3 天：账户工厂与反事实地址

ERC-4337 中的工厂合约很微妙。工厂使用 CREATE2 在确定性地址部署账户。该地址取决于盐值，而盐值通常取决于所有者的公钥和一个索引。

Claude 生成的工厂确实做到了这一点。但它还做了一件不该做的事：允许盐值在所有者地址之外包含用户提供的任意字节。

Biconomy 竞赛中公开的 Code4rena 漏洞正是这种攻击：如果盐值没有完全绑定控制钱包的凭证，攻击者可以用不同的初始化参数预先计算相同地址，并在合法用户首次存款时抢先交易。用户向钱包充值时，攻击者先调用工厂，钱包就归攻击者所有了。

修复方案：盐值仅由所有者地址和确定性索引计算得出。初始化参数在构造时根据盐值进行验证。我们增加了一个不变量测试，对初始化参数进行模糊测试，并确认无论调用顺序如何，部署的钱包始终由原所有者控制。

这是 Ancilar 工程师全程负责的三个组件中的第一个。

第 4 天：Claude 说“完成了”的那一天

到第 4 天结束时，智能账户、工厂和支付主已部署到测试网。捆绑器集成成功。TypeScript SDK 可以创建钱包、为其充值并发送 UserOperation，最终上链。端到端演示功能正常。

如果我们是在做一个黑客马拉松项目，到这里就会停下来。

但我们并非如此。我们运行了审计前置检查清单。支付主在三个方面未能通过。

第 5 天：支付主重写

支付主是 ERC-4337 中最难做对的组件，Claude 的版本也体现了这一点。生成的代码：

  • 使用单一签名密钥验证 UserOps，没有轮换机制
  • 没有对每个发送方进行速率限制，意味着一个恶意账户可以在几个区块内耗尽支付主存款
  • 没有强制执行 ERC-7562 验证规则，特别是禁止在验证期间访问其他账户的存储
  • 将验证签名地址存储在可变存储中，且更改没有时间锁

这些都不是罕见问题。关键在于 ERC-4337 支付主有特定的风险特征，“看起来合理”并不等于“遵守了验证规则——如果违反，捆绑器会静默丢弃你的操作”。

Ancilar 工程师重写了支付主：

  • 2-of-3 签名者集合，带时间锁的轮换机制
  • 每个发送方每个时间窗口的存款上限，带有显式回退原因并传播到 SDK
  • 验证阶段严格避免禁用操作码以及支付主自身槽位之外的存储访问
  • 紧急暂停权限仅限于单独的多签
  • 不变量测试模拟对抗性 UserOps，旨在利用已发布漏洞赏金中的每种模式

两天的工作。这是三个全程负责组件中的第二个。

第 6 天：SDK、捆绑器客户端以及 validateUserOp 测试套件

Claude 编写的 TypeScript SDK 坦率地说很不错：类型清晰、有文档、覆盖了快乐路径测试。我们的工程师增加了三项改进：

  1. SDK 层的重放保护。 签名的 UserOps 显式包含 chain ID 和 EntryPoint 地址，并在构造时进行健全性检查。
  2. 故障模式覆盖。 原始 SDK 在收到捆绑器拒绝时抛出通用错误。我们为每类拒绝（规则违反、存款不足、模拟回退）添加了具体的错误类型，以便应用代码做出相应反应。
  3. validateUserOp 测试套件。 这是 Ancilar 工程师全程编写的第三个组件。一个基于属性的测试套件，对 validateUserOp 运行数百种变体：格式错误的签名、跨分叉的重放尝试、来自非 EntryPoint 地址的调用、限时会话边界情况、部分签名损坏。当属性被破坏时，每个测试都会归结为一个可复现的失败用例。

这个套件是我们首先交给审计人员的成果。它告诉审计人员我们已经验证了什么，让他们把一周时间花在发现我们遗漏的东西上。

第 7 天：主网上线准备审查

最终检查清单。字节码验证。部署脚本由第二位工程师审查。多签配置确认。测试覆盖率报告生成并签署。审计人员已接入，正式审查与部署并行进行。

钱包栈在第 7 天发布上线。它没有在第 4 天上线的理由是：第 4 天是 Claude 输出看起来完整的那一刻。第 5 到第 7 天的工作决定了你的钱包能否在真实 mempool、真实对手和真实审计中存活。

我们实际学到的东西

Claude 在 ERC-4337 方面确实令人印象深刻。它了解规范，了解模式，能编写干净的代码。如果没有 AI 辅助，一支资深工程师团队完成 7 天的工作大约需要三周。加速效果是真实的。

但加速也有其边界。我们的工程师全程负责的三个组件（工厂、支付主和 validateUserOp 测试套件）正是故障模式在 ERC-4337 中特有、且在已发布漏洞赏金中有所记载的部分。AI 工具生成的代码在这些组件上能通过快乐路径测试，但无法可靠地生成能经受对抗性测试的代码。

工程问题不是“AI 能写 ERC-4337 代码吗？”它当然能。问题是“你把人工审查放在哪里，哪些组件需要全程负责？”对我们来说答案很明确：信任边界（validateUserOp）、部署表面（工厂）和经济表面（支付主）。其他所有组件都可以在高级审查下通过 AI 辅助来完成。但这三个组件必须由人类负责。

Ancilar 如何参与

我们与在 ERC-4337 和 EIP-7702 上发布智能账户基础设施的团队合作。我们提供的服务通常包括：

  • 信任边界审查。 validateUserOp 是新的攻击面。我们绘制所有经过它的代码路径，并验证授权、签名绑定和验证规则合规性。
  • 工厂与反事实地址审查。 Biconomy 式的抢先交易攻击是反复出现的问题。我们验证你的盐值方案是否正确绑定了凭证。
  • 支付主经济学与规则合规性。 我们根据已发布的验证规则和对抗性存款耗尽模式重写或审计你的支付主。
  • 预审计测试套件。 外部审计人员第一天就能运行的基于属性的测试。通常是合作中最有价值的产出。

对于正在决定在多大程度上通过 AI 辅助交付钱包栈的创始人或 CTO，这项工作正是第 4 天演示与第 7 天上线的区别。

如果你在发布智能账户产品，或者你已经做了一个原型，而“我们如何加固它以便主网上线”的问题摆在面前，那就是我们准备好的对话。

预约 Ancilar 的钱包栈审查： www.ancilar.com/services/smart-contract-audit

  • 原文链接： medium.com/@ancilartech/...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论