作者:康拉德·科普，由林恩·马斯比特编译。
在增加智能合约钱包(智能账户)对以太坊的本机支持的几个提案被拒绝或停滞后，ERC-4337已被接受为实现账户抽象(AA)而无需EVM的协议级修改的(临时)标准。在过去的几个月里，AA的一个子集的活动激增，这围绕着这些智能帐户的模块化，使它们更容易为用户和开发者扩展。这种通用方法被称为模块化账户抽象。下面这篇文章旨在勾勒出这三个月来这个生态系统的发展，以及事情的走向。
生态系统的组件以下部分将概述和讨论模块化AA生态系统的不同组件。这些组件是帐户、模块、注册表、用户界面和开发工具。这些组件可能不是这个生态系统长期运行所需的唯一部分，但至少在目前，它们完全覆盖了团队专注于研发工作的不同领域。
模块化账户(Modular accounts)模块化账户(Modular accounts)是指用户可以轻松、安全地扩展的智能账户，而不是只能由开发者修改、需要重新部署的“静态”账户。这使得用户可以即时切换、添加或删除智能账户中的功能。
实现方法
目前，有两种不同的方式来模块化智能帐户，一种是由安全架构创建或启发的，另一种是由多面钻石标准(ERC-2535)启发的。这两种方法有不同的发展，可以沿着多个轴进行比较。安全账户是由灵知建立的最初的multisig演化而来的，它比ERC-4337更早。该团队非常重视安全性和可扩展性，目前只能通过一个模块来实现对ERC-4337的支持。然而，也有关于在未来版本中实现本地支持的讨论。
另一种方法是受ERC-2535的启发。在过去的几个月里，不同的团队进行了广泛的讨论和追求。该标准的目的是使智能合约可扩展，以标准化的方式存储对模块(称为平面)的引用，并使用delegatecall操作码来执行这些。虽然围绕这个机会的讨论已经进行了一段时间，但是第一个工作实现(据我们所知)是由我们在ETHDenver中建立的。自那以后，其他几个团队发布了不同阶段的实现，如ZeroDev Kernel，这是最小的可扩展智能帐户，并从ERC-2535中获得了一些灵感。此外，Alchemy团队还撰写了一份阶段性的EIP草案(ERC-6900)，旨在从ERC-2535中获得灵感，实现模块化智能账户的标准化。灵魂钱包过去曾尝试过ERC-2535账户，尽管他们后来搁置了这些尝试(我们无法链接到这些尝试的任何代码)。
如上所述，这两种不同的方法可以沿着不同的轴进行比较。其中之一就是使用delegatecall来执行模块，而不是使用外部调用。使用delegatecall允许从调用协定的上下文中执行外部代码，这意味着外部代码可以修改调用协定的存储，并从调用帐户而不是模块进行外部调用。这不允许关注点的分离，这意味着一个模块可以覆盖帐户上的任何存储槽，这导致了一个主要的攻击媒介。虽然安全帐户目前确实允许delegatecall调用该模块，但这在将来可能会改变，要么完全删除，要么为该模块创建不同的权限级别。使用delegatecall执行一个模块的一个好处是，这个模块可以是一个列表，这大大减少了添加一个模块的gas开销。
这些方法之间的另一个区别是模块的存储模式和事务的路由。ERC-2535使用从函数选择器到模块地址的映射，这意味着没有两个活动模块可以共享相同的函数名(选择器是名称和参数的散列)。使用这个路由器的事务流程是在这个map中找到一个函数签名，然后用这个签名和参数用delegatecall调用对应的契约地址。另一方面，安全帐户只存储对模块地址的引用，这使得多个模块可以使用同一个函数选择器。此外，交易过程可以由安全帐户或模块触发，然后模块可以从那里调用安全帐户来执行交易。
第三个主要区别是这些实现处理存储的方式。由于ERC-2535调用模块的方式，存储不能像在普通智能合约中那样处理。相反，开发人员通常选择使用结构化或“菱形”存储来将数据存储在存储槽中，存储槽是特定模块标识符的唯一哈希值。这意味着不同的模块不会覆盖彼此存储的数据，也不会导致契约以意想不到的方式运行。尽管安全模块可以被delegatecall调用，但它们并不需要以这种方式调用，因此它们可以处理自己的存储。这意味着存储不需要以上述方式构造，而是可以以常规(顺序)方式或以坚固性存储定位通常实现的任何其他期望方式来处理。
这些是这些方法之间的一些最大差异。
模块化模块，有时称为插件或接口，是旨在扩展智能账户功能的智能合约。例如，一个模块可能允许所有者使用不同的签名方案来控制他们的钱包，或者在每次令牌被转移到另一个帐户时触发一个操作。模块的构建和执行有不同的方式，这与目前已经存在的、上面已经讨论过的模块账户的不同实现方式有关。所以，现在存在的模块要么是为安全架构构建的，比如这些或者这些，要么是为钻石启发的架构构建的，比如ZeroDev的内核或者我们在ETHDenver中构建的一些演示模块。
正如上面详细解释的，模块的结构取决于它将要使用的帐户实现。一个主要的区别是，为安全基础结构构建的模块需要回调到安全帐户(除非通过委托调用)，以便从帐户的上下文发起函数调用。相比之下，为钻石启发帐户建立的模块不需要这样做，因为它的代码是从智能帐户本身执行的。在此基础上，还有一个标准，可以使用基于安全架构的模块，叫做十二宫标准。该标准旨在分离模块化账户的不同组件，称为化身、守卫和模块，因此它旨在创建一个用于构建智能账户模块的通用框架。在这里可以找到一些使用这个标准的模块的例子。
Permissive是一个为智能账户构建通用模块的团队的例子。到目前为止，他们的重点是建立一个智能账户的授权框架，主要集中在允许更详细的访问控制，即用户可以赋予不同的实体特定的权限来执行账户的特定操作。他们发布了一个安全账户的模块，并试图将其移植到不同的模块实现中。
登记处
到目前为止，智能合约和智能账户的许多模块实现已经在用户和模块开发者之间建立了强信任假设。这就是今天ERC-2535几乎完全被使用的方式，允许开发团队管理大型复杂的代码库。然而，智能帐户生态系统的更大愿景是消除这种信任假设，并允许第三方开发人员构建非技术用户可以安全添加到他们钱包中的模块。虽然不能完全取消信任假设(毕竟需要有人来证明一个模块的安全性)，但是我们可以将单个用户和模块开发者之间的所有信任假设绑定到一个实体上，即模块注册表。这意味着用户现在只需要信任这个单一的实体，而不是信任他们想要使用的模块的每一个开发者。
虽然这种想法导致了集中式注册中心的结论，但这与我们的愿景相去甚远。相反，我们目前正在设计一个超级结构化注册表的原型，这意味着它是开放的，不可阻挡的，最重要的是，没有许可。这意味着具有不同安全假设的各方可以坐在这个注册表上，用户可以选择在什么情况下信任哪一方。目前，我们正在对不同的实施方法进行原型开发，我们得到了不同团队的有益投入和合作，如外管局和英孚的4337团队成员。一旦我们有了关于不同实现和激励设计的更具体的细节，我们将开始更公开地分享这些细节，并开放基本代码。
用户界面正如Yoav之前指出的，模块化AA的一个较少探索的方面是类似的模块化前端设计。这是必要的，因为UI组件需要专门构建，以通过了解函数选择器、参数编码和(潜在地)要执行哪种前端或后端逻辑来触发链上的一些函数。到目前为止，我们不知道有任何团队在这个问题上取得了重大进展，尽管我们正在慢慢开始探索基于上面讨论的注册表的参考实现。从我们的初步研究来看，设计一个允许外部模块开发者的模块化前端并不难。
开发者工具虽然有供dapp或钱包开发者将模块化AA集成到应用中的开发者工具，但帮助开发者构建模块的指南或工具却很少。Safe这里有一个指南，ZeroDev这里有一个，但是除此之外，我们不知道有什么更实质性的东西可以让开发者轻松理解如何构建一个模块。随着这个领域的成熟，我们相信会有更多的指南和实用工具出现，会大大降低模块开发者的门槛。
结论模块化AA是更广泛的AA运动的子集，其目的是将智能账户模块化，以便可以为用户定制，并允许开发者轻松建立独立的智能账户功能，而不是建立完整的账户。上述文章的目的是对这一领域的现状作一个广泛的概述，并强调正在取得进展的领域。
本网站声明:网站内容来源于网络。如有侵权，请联系我们，我们会及时处理。
温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信，我们会及时处理和回复。
原文地址"模块化运作，什么是模块化账户抽象服务"：http://www.ljycsb.cn/qukuailian/216180.html。
微信扫描二维码投放广告
▲长按图片识别二维码
