在为以太坊增加智能合约钱包（智能账户）的原生支持的多个提案被拒绝或停滞后，ERC-4337 已被接受为（临时）标准，以实现账户抽象（AA）而无需对 EVM 进行协议级别的修改。在过去的几个月里，AA 的一个子集的活动激增，它围绕着这些智能账户的模块化，使它们对用户和开发者来说更容易扩展。这种一般的方法被称为模块化账户抽象，下面的文章旨在概述这一生态系统在过去 3 个月中的发展以及事情的走向。

生态系统的组成部分

下面的部分将概述和讨论模块化 AA 生态系统的不同组件。这些组件是账户、模块、注册表、UI 和开发者工具。这些组件可能不是使这个生态系统长期运作所需的唯一部分，但至少目前充分包含了各团队集中研究和开发努力的不同领域。

模块化账户

模块化账户是指用户可以轻松、安全地扩展的智能账户，而不是只能由开发人员修改并需要重新部署的“静态”账户。这使得用户可以在他们的智能账户中即时切换出、添加或删除功能。

实施方法

目前有两种不同的模块化智能账户的方法，一种是由安全（Safe）架构创建或启发的，另一种是由多面代理（又称钻石）标准（ERC-2535）启发的。这两种方法有不同的发展，可以沿着多个轴线进行对比。

Safe 账户是从 Gnosis 建立的最初的 multisig 演变而来的，并且早于 ERC-4337. 该团队非常强调安全性和可扩展性，而 ERC-4337 的支持在目前只能通过一个模块来实现。然而，也有关于在未来的版本中实现本地支持的讨论。

另一种方法是受 ERC-2535 的启发，在过去的几个月里，不同的团队已经进行了广泛的讨论和追求。这个标准的目的是使智能合约具有可扩展性，通过标准化的方式来存储对模块（称为面）的引用，并使用 delegatecall 操作码来执行这些。虽然围绕这个机会的讨论已经持续了一段时间，但（据我们所知）第一个工作实现是由我们在 ETHDenver 建立的。从那时起，其他几个团队已经发布了不同阶段的实施方案，例如 ZeroDev Kernel，这是一个最小和可扩展的智能账户，从 ERC-2535 中获得了一些灵感。此外，Alchemy 团队已经写出了一个阶段性的 EIP 草案（ERC-6900），旨在从 ERC-2535 中获取灵感，实现模块化智能账户的标准化。Soul Wallet 过去也曾试验过 ERC-2535 账户，尽管他们后来搁置了这些尝试（我们无法链接到这些尝试的任何代码）。

如上所述，这两种不同的方法可以沿着不同的轴线进行对比。其中之一是使用 delegatecall 来执行模块，而不是使用外部调用。使用 delegatecall 允许从调用合约的上下文中执行外部代码，这就意味着外部代码可以修改调用合约的存储，并进行来自调用账户而不是模块的外部调用。这不允许关注点的分离，这意味着一个模块可以覆盖账户上的任何存储槽，这引起了一个主要的攻击媒介。虽然安全账户目前确实允许使用 delegatecall 来调用模块，但这在未来可能会改变，要么完全被删除，要么为模块创建不同的权限级别。使用 delegatecall 来执行模块的一个好处是，模块可以是单子，大大降低了添加模块的 gas 成本。

这些方法的另一个区别是模块的存储方式和交易的路由。ERC-2535 使用从函数选择器到模块地址的映射，这意味着没有两个活动模块可以共享相同的函数名称（选择器是名称和参数的散列）。使用这个路由器的事务流程是在这个映射中查找一个函数签名，然后用这个签名和参数用 delegatecall 调用相应的合同地址。另一方面，安全账户只存储对模块地址的引用，从而使多个模块使用同一个函数选择器成为可能。此外，交易流程可以由安全账户或模块触发，然后模块可以调用安全账户，从那里执行交易。

第三个主要区别是这些实现处理存储的方式。由于 ERC-2535 调用模块的方式，存储不能像在普通智能合约中那样处理。相反，开发人员通常选择使用结构化或“钻石”存储，将数据存储到存储槽，这些存储槽是唯一的、特定模块的标识符的哈希值。这意味着不同的模块不会覆盖对方的存储数据，并导致合同以意想不到的方式行事。虽然安全模块可以使用 delegatecall 来调用，但它们并不要求以这种方式来调用，因此可以处理自己的存储。这意味着存储不需要以上述方式进行结构化，而是可以以 Solidity 存储定位通常实现的常规（顺序）方式或其他任何想要的方式来处理存储。

这些是这些方法之间最大的一些差异，但关于不同方法的另一个评估，请看 Safe 团队写的这篇文章。

模块

模块，有时称为插件或面，是旨在扩展智能账户功能的智能合约。例如，一个模块可能允许所有者使用不同的签名方案来控制他们的钱包，或者在每次代币被转移到另一个账户时触发某个动作。与到目前为止存在的、上面已经讨论过的模块化账户的不同实现方式有关，有不同的构建和执行模块的方式。因此，今天存在的模块要么是为安全架构建立的，如这些或这些，要么是为钻石启发的架构建立的，如 ZeroDev 的内核或我们在 ETHDenver 建立的一些演示模块。

正如上文详细解释的那样，一个模块的结构取决于它所要使用的账户实现。一个主要的区别是，为安全基础设施构建的模块需要（除非通过委托调用）回调到安全账户，以便从账户的上下文中初始化一个函数调用。相比之下，为钻石启发账户建立的模块不需要这样做，因为它的代码是从智能账户本身中执行的。在此基础上，还存在一个标准，建立在安全架构之上的模块可以使用，称为 Zodiac 标准。该标准旨在将模块化账户的不同组成部分分开，称为头像、护卫和模块，因此旨在为构建智能账户模块创建一个通用框架。一些使用该标准的模块的例子可以在这里找到。

Permissive 是一个正在为智能账户构建公共模块的团队的一个例子。到目前为止，他们的重点是为智能账户建立一个授权框架，主要集中在允许更细化的访问控制，即用户可以给不同的实体以具体的权限来执行账户的特定动作。他们已经发布了一个 Safe 账户的模块，并正在努力将其移植到不同的模块实现上。

注册表

到目前为止，许多智能合约和智能账户的模块实现都是在用户和模块开发者之间建立了强大的信任假设。这就是 ERC-2535 今天几乎完全被使用的方式，允许开发者团队管理大型和复杂的代码库。然而，智能账户生态系统的更大愿景是消除这种信任假设，允许第三方开发者建立非技术用户可以安全地添加到他们的钱包的模块。虽然信任假设不能完全取消（毕竟有人需要证明一个模块的安全性），但我们可以将单个用户和模块开发者之间的所有信任假设捆绑到一个单一的实体，即模块注册表。这意味着，用户现在只需要信任这个单一的实体，而不是需要信任他们想要使用的模块的每一个开发者。

虽然这种思路导致了中心化登记处的结论，但这远远不是我们所追求的愿景。相反，我们目前正在设计一个类似于超结构的注册中心的原型，这意味着它是开放的、不可阻挡的，而且最重要的是，没有许可。这意味着具有不同安全假设的各方可以坐在这个注册表之上，由用户来选择在什么情况下信任哪一方。目前，我们正在对不同的实现方式进行原型设计，并得到了不同团队的有益投入和合作，例如 Safe 和 EF 的 4337 团队成员。一旦我们有了关于不同实现方式和激励设计的更多具体细节，我们将开始更公开地分享这些细节，并开放基础代码。

用户接口

正如 Yoav 之前所指出的，模块化 AA 的一个较少被探索的方面是类似的模块化前端设计。这是必要的，因为 UI 组件需要通过了解函数选择器、参数编码和（潜在的）执行何种前端或后端逻辑来专门构建以触发某些链上功能。到目前为止，我们还不知道有哪个团队在这个问题上取得了重大进展，尽管我们正慢慢开始探索建立在上面讨论的注册表之上的参考实现。从我们的初步研究来看，一个允许外部模块开发者的模块化前端的安全设计是不难的。

开发者工具

虽然存在开发者工具，供 dapp 或钱包开发者将模块化的 AA 集成到他们的应用程序中，但很少有指南或工具来帮助开发者构建模块。Safe 有一个指南在这里，ZeroDev 有一个在这里，但除了这些，我们不知道有什么更实质性的东西可以让开发者轻松了解如何建立一个模块。随着这个领域的成熟，我们相信会有更多的指南和实际的工具出现，大大降低模块开发者的门槛。

结论

模块化 AA 是更广泛的 AA 运动的一个子集，其目的是将智能账户模块化，以使其可以为用户定制，并允许开发人员轻松建立独立的智能账户功能，而不是需要建立一个完整的账户。上述文章的目的是对这一领域的现状做一个广泛的概述，以及强调正在取得进展的地方。我们还试图包括我们所知道的尽可能多的相关进展链接，但如果我们遗漏了什么，请与我们联系，以便我们能够包括它们。最后，有一个 Telegram 小组，这个空间的许多正在进行的讨论都发生在其中。如果你有兴趣了解最新情况和/或作出贡献，请随时加入。如果你有任何问题，请随时联系我或上面提到的任何团队。

鸣谢

感谢 Kurt、ZeroKnots、Lukas 和 Derek 帮助我，提供的宝贵反馈。