Account Abstraction（ERC-4337）在生产环境中：它真正解决了什么，又解决不了什么

ERC-4337 上线时间足够长，已经不再是一个思想实验。我们已经为客户在生产环境中交付了 账户抽象 钱包（参见 我们的 AA 案例研究 以及 MetaMask Snap 工作）。诚实的总结是：AA 是 UX 上的进步，不是安全上的进步。它解决了用户长期抱怨的一长串小痛点，同时引入了一份较短的、让工程师抱怨的新攻击面清单。这篇文章就是拆解：它修复了什么，没修复什么，以及客户在投入前常问我们的问题。

用一段话讲清楚 ERC-4337 是什么？

这是一项标准，允许智能合约充当用户账户，无需修改底层 EVM 协议。用户签署一个 UserOperation，bundler 将其打包，paymaster 可以选择代付 gas，entry-point 合约负责验证并执行。最终效果是：用户无需持有 ETH 即可交易，可以用 passkey 或社交恢复代替助记词，并且可以把多个动作合并成一次授权。ERC-4337 是标准，具体的钱包实现（Safe、Kernel、Biconomy、Alchemy 的 Light Account、ZeroDev）在其之上叠加各种功能。

AA 在生产中到底解决了什么？

• 通过 paymaster 实现 gasless UX。用户不需要持有 ETH。由别人（你自己、赞助合约、代币内换 gas）来支付 gas。这一项改变就堵住了 EVM 产品最大的入门缺口。
• 批量交易。授权加 swap，一次签名搞定。授权加存入加质押，一次签名搞定。提示更少，流程放弃率更低。
• 社交恢复。守护人可以轮换签名密钥而不动用资金。用户不再因为弄丢助记词而失去钱包。
• Session keys。有时间和范围限制的签名权限。用户签一次，dapp 在限制范围内可以继续行动，无需再次提示。对游戏和高频产品来说意义巨大。
• 基于角色的消费策略。“在这个 DEX 每天交易最多 $500，其他都需要守护人签名。”钱包里有真正的策略引擎，而不是应用里。
• Passkeys 与 WebAuthn。用指纹或设备 passkey 签名，而不是助记词。对非加密原生用户来说是巨大的 UX 提升。

AA 没有解决什么？

• Bundler 中心化。大部分生产流量经过少数几家 bundler 运营商。审查风险和可用性风险集中在那里。
• Paymaster 经济模型。gas 最终总要有人付。如果是你来付，你需要预算、配额和女巫防护策略。
• 社工型恢复攻击。如果你的恢复流程信任邮箱或手机号，那就是你新的最弱环节。恢复听起来很安全，但只取决于你选的守护人是否安全。
• 多链钱包 UX。每条链都有自己的 AA 部署、自己的 bundler、自己的 paymaster。面向用户的钱包把这些隐藏起来，但工程团队感受得到。
• Dapp 签名 UX 的混乱。EIP-712 typed data 对大多数用户来说仍然让人困惑。AA 并没有改变用户被要求签署的内容。
• 根本上“这笔交易到底做什么”的问题。批量的 UserOperation 比单笔转账更难安全地展示。UX 工作仍然必不可少。

AA 引入了哪些新的攻击面？

不是“更小”，而是“不同”。值得列出来，因为我们在那些跳过严肃威胁建模的项目里见过这些问题。

1. Paymaster 伪造。如果你的 paymaster 校验逻辑松散，攻击者可以通过触发本不该获得赞助的操作来掏空 paymaster 预算。
2. 签名聚合器的微妙问题。聚合签名方案存在微妙的可塑性和重放问题。它们需要独立的审计。
3. Init-code 钓鱼。钱包首次部署包含 init code。恶意 dapp 可以建议一段 init code，从第一天就给钱包留后门。
4. UserOperation 模拟漂移。bundler 模拟时看到的状态可能与执行时的状态不一致。处理不当，这就会变成骚扰向量。
5. Session key 授权过宽。授予容易，遗忘也容易。我们见过 dapp 请求的 session key 范围远大于它实际需要的。
6. 守护人串谋。社交恢复把信任从助记词转移到守护人集合。请相应地选择。

快速对比：EOA 与 AA

"AA 是 UX 上的进步，不是安全上的进步。这样定位，你就能正确划定它的范围。"

问答：我们还需要 EOA 吗？

目前还需要。EOA 仍然更简单、单笔交易更便宜，审计面也小得多。对于技术用户的高频低风险交易，EOA 没问题。对于面向消费者的入门流程，AA 才是正确的默认值。我们经常交付混合产品：消费者流程用 AA，资深用户或运营人员流程用 EOA。

问答：AA 更便宜还是只是更好用？

就每笔交易而言，AA 比 EOA 消耗更多 gas，因为 entry-point 和钱包合约要做额外的验证工作。用户体验更便宜（签名提示更少，不必预先购买 ETH）。只有当你在一个 UserOperation 中批量打包足够多操作，使每个操作的均摊成本低于 EOA 对应的成本时，费用经济才会反转。批量打包就是 gas 数学的胜利所在。

问答：我们能自己跑 bundler 吗？

可以。已经有多个开源 bundler（Pimlico 的 Alto、Stackup、ETH Infinitism 参考实现）。自跑 bundler 给你抗审查能力和可预测的性能，同时也给你 24/7 的运维负担、节点基础设施账单和 DDoS 目标。对于大部分产品，使用托管 bundler 是务实的答案。对于把抗审查作为核心承诺的产品，自托管是值得的。

问答：EIP-7702 怎么算？

EIP-7702（自 Pectra 起上线）让 EOA 能暂时表现得像智能账户。这改变了取舍：对于很多主要想要 AA 用于批量打包和赞助 gas 的产品来说，EIP-7702 在不引入新钱包合约的情况下交付了大部分 UX 上的好处。ERC-4337 仍然是完整社交恢复、session keys 和策略丰富钱包的正确答案。我们会根据产品本身，而不是潮流，帮客户在两者之间做选择。

问答：AA 与其他链上的智能合约如何交互？

每条链都需要自己的 AA 部署。entry-point 地址、bundler 和 paymaster 合约都是按链来的。用户看到的是一个钱包，工程团队看到的是 N 套部署。跨链钱包抽象工具正在追赶，但还很粗糙。请提前规划。

问答：我们需要自定义钱包合约吗？

通常不需要。Safe、Kernel、Light Account 等实现都经过良好审计，覆盖了 90% 真实产品需求。当你有特定的策略引擎、签名方案或恢复模型，而现有实现不支持时，自定义钱包合约才合适。自定义更贵，审计负担也更重。参见我们的区块链工程服务了解我们如何对此进行范围界定。