(更新：我们发布了一篇后续博客文章。Alchemy 的 Noam 发布了一份回应。)
账户抽象作为一个领域，很大程度上接受了“模块化智能账户”的概念——即智能账户的逻辑可以通过插件动态定制。迄今为止，已部署的所有智能账户中，超过 90% 都是模块化的，其中 Kernel 是最受欢迎的选择。
然而，不同的模块化智能账户不兼容，这对开发者来说是一个巨大的挑战。例如，如果你正在构建一个 DApp，并且想要使用会话密钥，你需要选择一个特定的会话密钥实现，该实现只能与一个特定的智能账户实现一起工作。如果你使用，例如，OpenFort 的会话密钥，你的 DApp 将无法与基于 Kernel 的钱包一起工作，反之亦然。这是目前 AA 主要仅在嵌入式钱包的上下文中找到 PMF 的一个重要原因，在嵌入式钱包中，DApp 可以严格控制其用户使用的账户实现。
为了应对这一挑战，Alchemy 在 2023 年 4 月提出了 ERC-6900 作为模块化账户标准。我们最初对这项工作非常热情，并且打算支持它。然而，随着时间的推移，我们对 6900 的发展方向感到悲观，因此我们与 Rhinestone、Biconomy 和 OKX 共同撰写了 ERC-7579，我们认为该标准更好地体现了我们与 Web3 相关联的开放性、互操作性和创新精神。
在这篇文章中，我们将描述我们对 ERC-6900 存在的问题，以及为什么我们决定基于 ERC-7579 构建。
TLDR
如果你没有时间，以下是重点：
ERC-6900 是一个伪装成标准的实现。 采用 ERC-6900 意味着采用 Alchemy 做出的一些实现决策，这些决策远远超出了确保模块兼容性的范围。
另一方面，ERC-7579 是一个最小的接口，它只解决一个问题：模块应该在智能账户之间兼容。 除此之外，智能账户可以自由地做出自己的设计决策。
如果你不相信我们，只需比较 ERC-6900 和 ERC-7579 的长度即可。
一个好的类比可能是 Mac OS 与 Linux。虽然 Mac OS 是一个很棒的操作系统，但它不应该成为一个标准。一个标准应该像 Linux 一样最小化，这样人们就可以在它之上构建不同的操作系统（包括 Mac OS），同时保持彼此兼容。
现在让我们看看我们对 ERC-6900 存在的问题。
技术问题
模块可组合性
Kernel 的一个关键目标是简化安全地开发模块。换句话说，模块开发者应该尽可能难以搞砸。
这就是 Kernel 在设计时考虑到模块可组合性的原因。模块可组合性是指 UserOp 应该能够调用多个模块的想法。因此，模块开发者可以保持其模块非常简单，并通过将简单的模块放在一起来实现复杂的验证逻辑。
然而，这在 ERC-6900 中是不可能的，因为每个执行函数都必须与单个验证模块相关联。因此，如果使用 Kernel，你可以开发插件 A 和插件 B，并且为了实现 A+B，你只需要一起使用 A 和 B，而使用 ERC-6900，你必须开发一个结合了 A 和 B 逻辑的新插件。这会导致冗余代码和难以审计的复杂、单体模块。
离线启用模块
Kernel 的一个“杀手级功能”是离线启用模块的能力。例如，你可以仅通过签署消息来创建会话密钥。在实际使用会话密钥之前，实际上不会支付任何 gas 费用来启用会话密钥。这对于限价单等用例至关重要。例如，当我为一个协议创建一个会话密钥来为我执行限价单时，并不清楚该订单是否会被执行（例如，如果价格从未达到我期望的数字）。因此，不预先支付 gas 费用，而仅在执行订单时支付 gas 费用的能力对于用户体验至关重要。
为了离线启用模块，ZeroDev 将模块的“批准”和模块本身的签名数据都打包到模块使用的第一个 UserOp 的 signature 字段中。但是，这在 ERC-6900 中是不可能的，因为它规定 UserOp 必须按原样传递给模块。因此，除非对模块进行显式编程以忽略签名的一部分，否则它将无法解析它。但是这样做会在模块和智能账户实现之间引入依赖关系，而这正是模块化账户标准应该避免的事情。
这就是为什么 ERC-6900 中的会话密钥必须显式地在链上启用，从而使大量需要创建会话密钥而不能保证交易执行的用例失效。
聚合器
“聚合器”是 ERC-4337 中一个不太为人所知的功能，用于验证聚合签名，例如 BLS。通常，它对于涉及全局存储的任何验证过程都很有用；例如，我们一直在研究一种利用聚合器的基于 ZK 的恢复过程，其中验证 ZK 证明涉及访问一些全局存储。
然而，ERC-6900 彻底禁止了聚合器。我们不清楚原因，但在任何情况下，如果有人对聚合器有问题，你可能会认为更合理的方法是提出对 ERC-4337 本身的规范更改，而不是提出一个禁止 ERC-4337 一部分的账户标准。
非技术问题
ERC-7579 是由实际经验驱动的；ERC-6900 则不是
如果我们考察这两个标准是如何产生的，那么 ERC-7579 比 ERC-6900 是一个设计更好的标准也就不足为奇了。
ERC-6900 是 Alchemy 团队的创意，他们是我们非常尊重的杰出工程师。然而，它是在 AA 普遍以及模块化智能账户特别缺乏吸引力的时候构思的。虽然 Alchemy 一直在与其他人合作设计 6900，但总体架构仍然与 Alchemy 团队设置的初始设计保持一致。
另一方面，ERC-7579 是在 ERC-6900 之后近 8 个月构思的。当时，已经部署了 200 多万个模块化智能账户，因此 ERC-7579 的作者能够借鉴模块开发者和智能账户开发者的实际经验。
重要的是，ERC-7579 的作者包括 Kernel (ZeroDev)、Biconomy 和 OKX 的作者，它们是当今使用最广泛的三种模块化账户。因此，该标准Incorporates了一系列不同的意见。
关于 ERC-6900 的决定由 Alchemy 主导
如果我们对 ERC-6900 有这么多问题，你可能会问，为什么我们不尝试为该标准做出贡献，而是创建一个新的标准？
事实上，我们有。在该标准的早期，我们向 Alchemy 提供了很多反馈，我们得到的回复往往是“这是一个很好的观点——我们将在内部讨论它”。换句话说，很明显 Alchemy 将自己视为账户标准的最终仲裁者。
现在，我们完全尊重其他团队对如何构建智能账户有不同的意见。而这正是标准的意义所在——它应该在尊重不同设计决策的同时实现互操作性。然而，我们觉得我们的意见被简单地否决了，而该标准朝着Incorporates由特定团队做出的一组特定设计决策的方向发展。我们认为这不是构建标准的正确方式。
尽管说出来让我们感到痛苦，但在 Web3 中，推动一个实际上只是巩固特定产品的“标准”是一种常见的做法。虽然我们倾向于认为这不是 ERC-6900 的意图，但我们所看到的并没有给我们带来强烈的信心。
ERC-6900 的未来
再说一次，我们尊重 ERC-6900 作为一个实现——它做出一系列设计决策，虽然我们不同意所有这些决策，但总体上是合理的和合乎逻辑的。它只是不应该成为一个标准。
如果 ERC-6900 要作为一个标准存在下去，我们希望看到它成为 ERC-7579 之上的扩展（请注意这是如何可能的，但反之则不然）。这样，与 ERC-6900 的特定设计决策保持一致的开发者可以采用它，但为了实现模块兼容性，采用 ERC-7579 就足够了。
最后的话
标准化是一种平衡行为——必须寻求提高不同产品之间的互操作性，同时允许产品差异化和创新。后者尤其重要，因为考虑到所有因素，现在仍然只是账户抽象的早期阶段。这就是为什么我们正在基于 ERC-7579 这个最小的互操作性标准来构建我们的产品，以便我们可以继续向最终用户交付出色的产品，而这最终才是最重要的。
