对 ERC-4337 的误解与合理的担忧

在 ZeroDev，我们的工作是帮助开发者学习和采用 AA，所以很自然地，我们遇到了很多问题、担忧和反对意见。

在这篇文章中，我想总结一些针对 ERC-4337 和 AA 的常见抵触，我将它们分为三类：

• 误解：完全不真实的事情。
• 是也不是：有几分真实，但实际情况很微妙。
• 合理的担忧：需要解决的实际问题。

让我们深入探讨吧！

AA 没什么大不了的，因为 SCW 已经存在很多年了

在没有 AA 的情况下，像 Safe/Argent 这样的智能合约钱包并不是区块链上的“一等公民”，这意味着你不能直接从它们发起交易。相反，你必须执行以下操作之一：

• 从 EOA 调用 SCW，所以你仍然必须先拥有一个加粗愚蠢加粗的钱包才能拥有一个智能钱包。
• 依赖中心化的中继服务来中继你的交易，这会让你面临审查、停机等风险。

然而，有了 AA，你可以像从 MetaMask 直接发送交易一样，从 SCW 直接发送交易。这使得使用 SCW 作为你的唯一钱包成为可能，这正是未来十亿 Web3 用户将要做的事情。

你仍然需要一个 EOA 来拥有 AA 钱包

这个常见的困惑源于这样一个事实，即今天大多数 AA 钱包都由私钥拥有（就像 EOA 钱包一样），但这是被误导的，因为：

• 私钥 ≠ EOA。虽然每个私钥都有一个对应的 EOA，但密钥本身只是一个密钥，可以用来签署东西。一个典型的 AA 钱包会像 MetaMask 一样存储和保护一个私钥，并使用该密钥为智能合约账户签署交易。对应的 EOA，如果存在的话，仅用作验证签名的公钥。
• 由于 AA 允许使用智能合约验证交易，因此验证逻辑可以是任意的，所以你甚至不需要一个私钥。这是一个使用指纹代替私钥的概念验证。

如果我们有 MPC，我们就不需要 AA

思考 MPC 与 AA 的最佳方式是：

• MPC 改善了密钥管理体验。
• AA 改善了交易体验。

有了 MPC，你实际上拥有一个“虚拟私钥”，而无需将其存储在任何地方，这比必须写下 12 个单词的助记词的现状有了巨大的改进。

AA 关注的是当你发送交易时会发生什么——谁支付 gas？使用什么 token 支付 gas？谁签署交易？所有这些都可以用 AA 抽象出来。

正如你所看到的，MPC 和 AA 实际上可以很好地互补——MPC 避免了用户处理密钥，而 AA 使交易顺畅。事实上，正是通过将 MPC 与 AA 相结合，我们才能够提供 社交 AA 钱包。

AA 交易更贵

由于 AA 使用智能合约钱包，因此与同等的 EOA 交易相比，每笔交易必然有一些开销。还有将智能合约钱包部署到链上的成本。

但是，有多种因素降低了 AA 的交易成本：

• SCW 具有批量处理交易的能力，因此通常需要 EOA 进行多次交易的操作，使用 SCW 可能只需要一次交易。一个经典的例子是你与 DeFi 协议交互时，每个操作通常涉及多个交易（例如，批准 → 交换 → 存款）。在 AA 中，所有这些都可以在一个原子交易中完成，从而节省 gas。
• ERC-4337 支持签名聚合，因此多个 AA 交易可以有效地“共享”一个签名，从而降低了每个交易的成本。这里有一些来自 Vitalik 的数据。
• ERC-4337 在用户的第一次交易之前不会部署智能合约账户。在此之前，该账户以“反事实”的方式存在——它有一个地址，即使它实际上没有被部署。因此，你的用户即使不支付任何部署成本也可以接收资产。

因此，AA 交易或普通交易花费更多的 gas 实际上取决于工作负载。对于某些应用程序（尤其是 DeFi），AA 交易最终可能会更便宜！

AA 还没有为生产做好准备

毫无疑问，今天在 AA/ERC-4337 上构建任何东西的人都是开拓者——没有太多的先例可以参考或模式可以借鉴。从这个意义上讲，在 AA 上构建东西肯定比构建经典的 DApp 涉及更多的技术风险。

但是，构建完整的 AA 应用程序所需的一切（特别是 ERC-4337 本身）已经在生产/主网上运行。我们正处于一个拐点，你要么在构建最后的非 AA 应用程序之一，要么在构建第一个 AA 应用程序之一。 选择权在你。

AA 与现有的 DApp 不兼容

在 AA 之前，有“元交易”，它可以通过使用中继器代表用户提交交易来移除 gas (或用 ERC20s 支付 gas)。然而，主要问题是 DApp 合约必须使用像 _msgSender() 这样的辅助函数而不是更直观的 msg.sender 来获取交易发送者的地址。毋庸置疑，大多数 DApp 没有这样做，因此元交易的兼容性受到严重限制。

然而，AA 没有这个问题，这使得它与绝大多数 DApp 兼容。然而，兼容性中断的地方是当 DApp 要求钱包签署消息时。事实证明，EOA 签名和智能合约钱包签名不能以相同的方式验证，因此有一个标准 ERC-1271，DApp 应该实现该标准以与智能合约钱包兼容。这是一个按是否支持 ERC-1271 分组的不完整且可能过时的 DApp 列表。

如果 DApp 需要消息签名但不支持 ERC-1271，那么 AA 确实无法与 DApp 一起使用。幸运的是，该领域完全一致，需要支持 ERC-1271，并且今天编写的新 DApp 如果使用像 OpenZeppelin 这样的库，通常默认支持 ERC-1271。

ERC-4337 不是真正的 AA。我们应该等待真正的 AA

当有人说 ERC-4337 不是“真正的”AA 时，他们通常指的是 ERC-4337 没有集成到区块链协议本身中。相反，像 zksync 和 StarkNet 这样的新网络已经将“enshrined”AA 作为其协议的一部分。

以太坊和大多数其他 EVM 链没有 enshrined AA 的原因有两个：

• Enshrining AA 会破坏协议，因此需要进行硬分叉。
• 对于实施 AA 的最佳方法没有达成共识，因此甚至不清楚我们应该 enshrined 什么。

将 AA enshrined 到协议本身也意味着每个 EVM 链都必须实施这种破坏性的更改，这可能需要很长时间。相反，由于 ERC-4337 是作为智能合约实现的，因此部署到新链实际上是部署一些智能合约的问题。这就是为什么 ERC-4337 今天已经在所有 EVM 链上运行的原因。

无论如何，“真正的 AA”和“ERC-4337 AA”之间的区别对于最终用户来说无关紧要。从他们的角度来看，他们的交易无论如何都可以“正常工作”。因此，鉴于社区对 ERC-4337 的认可程度，这是我们在短期内在 EVM 区块链上实现 AA 的最佳希望。

ERC-4337 现在相当中心化

理论上，ERC-4337 的设计使得任何人都可以启动中继器（又名“bundler”），这与以前通常由单个实体运行的中继器网络不同。

然而，在实践中，除了 StackUp 之外，大多数 bundler 实现都没有为生产做好准备，因此今天大多数 ERC-4337 流量都通过 StackUp。这与大多数以太坊流量都通过 Geth 类似。希望这种情况会随着其他 bundler 投入生产而改变。

ERC-4337 可能仍然会更改

虽然 ERC-4337 已经部署在主网上，但从技术上讲，它还没有最终确定。EIP 仍然处于草案状态，核心团队已经承认 EIP 和智能合约仍然可能更改。

幸运的是，预计对 EIP 和核心智能合约的任何更改都不会影响核心帐户接口，因此今天与 ERC-4337 兼容的钱包很可能在将来仍然与 ERC-4337 兼容。

ERC-4337 尚未经过形式化验证

虽然 ERC-4337 已经过审计，但它尚未经过形式化验证，因此不能完全排除存在一些关键安全问题的可能性。

幸运的是，有一些团队正在进行 ERC-4337 的形式化验证（我们自己的 taek 是主要贡献者）。当 ERC-4337 经过形式化验证后，我们预计它会最终确定。

毫无疑问，今天在 AA 上构建的任何人都将是承担技术风险的开拓者。但风险伴随着回报——如果执行得当，你的项目将在可用性方面让你的竞争对手相形见绌。

在 ZeroDev，我们开发了一个 AA 框架，可以大大缩短开发人员在 AA 上构建钱包和 DApp 的时间——并降低风险。查看 ZeroDev 并立即开始构建 Web3 的未来！

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