作者：Konrad Kopp 来源：medium

模块化智能账户引入了智能账户的新范例，可实现可扩展性和面向未来的需求。然而，模块化帐户比整体或集成帐户更复杂，并且其安全性需要更多的关注，特别是在安装第三方模块时。去年，有关模块化帐户安全性的讨论一直在进行，例如围绕删除delegatecall 的辩论。这场争论是围绕ERC-2535 钻石代理与智能账户的使用以及相关的安全问题而产生的。除此之外，围绕安全的公开辩论相对较少。

这篇博文的目的是概述保护模块化帐户的不同方法，并概述每种方法的潜在优点和缺点。

设置场景

模块化账户已经存在了一段时间，2023 年之前的主要例子是Safe。随着时间的推移，不同的模块被构建和使用，例如Gnosis Guild 构建的Zodiac 模块集。这些模块大部分是由 DAO 和机构构建的，例如Yearn。因此，主要方法是单个实体为其自己的用例构建和使用模块。

这样做的好处是，除了由模块构建者选择和签约的模块审计员之外，不存在对外部各方的信任依赖。然而，在 ETHDenver 2023 上，我们提出了可定制钱包的想法，该钱包允许用户在智能账户模块的支持下轻松添加和删除其账户中的功能。虽然这一产品愿景已经发展到包括嵌入式钱包的兴起以及使用模块构建更强大、更无缝产品的潜力，但仍然存在一个核心问题：为了加速模块化智能账户创新，我们需要一种更具可扩展性和可组合性的构建和组合方式。使用模块。

一种想法是将模块构建者的角色与模块使用者的角色分开。这可能会将我们引向“模块商店”，类似于 iOS、Android、Vscode 或 Raycast 上的现有应用程序或扩展商店。这意味着开发人员或团队可以构建一个或一组模块，其他开发人员可以使用这些模块来为其产品提供支持，或者用户直接安装在他们的帐户上以启用新颖的钱包功能。然而，这在模块的使用者和构建者之间引入了信任依赖。

因此，解决模块安全是加速智能账户创新的主要解锁点之一。关键问题是我们如何减少信任依赖，并允许用户或开发人员在安装或使用模块之前获得模块安全性的保证。

到目前为止，有两种新兴的模块化帐户安全方法：证明注册表和模块许可系统。尚待进一步深入探索的替代方法包括基于链下监控的断路器或交易共同签名。后者的一个例子是Argent Shield，它提供了一种向您的帐户添加可信共同签名者的方法。

在深入研究这些方法之前，我们将首先检查存在哪些已知的安全问题，以便评估每种方法的优点。

安全问题

围绕模块化帐户安全性的讨论特别围绕确保模块的完整性和允许的操作。虽然这种情况可能在安装之前和使用期间发生，但需要注意的是，本博客并不以帐户本身的构建方式为中心，而是以模块（尤其是第三方）的使用方式为中心。可能出现的一些潜在安全问题是（大致按严重程度排列）：

• 允许代表账户执行的模块可以执行任意执行，例如将所有资金转出账户

• 执行验证的模块可以允许帐户执行任何执行

• 使用 delegatecall 调用的模块可能会自毁帐户

• 对帐户具有存储访问权限的模块（当使用 delegatecall 调用时）可以接管帐户或将其砖化

• 执行验证的模块可以对帐户发起拒绝服务攻击

• 挂钩其他进程的模块可以对帐户发起拒绝服务攻击

• 卸载期间，模块可能会恢复或导致 OOG 恢复，从而可能导致模块“无法安装”

• 卸载期间，模块无法充分清理其配置，从而导致意外行为，甚至可能在重新安装时失去对帐户的访问权限

以上是模块可能出现的一些漏洞示例，但也可能出现许多其他漏洞。此类漏洞的一个例子发生在 Yearn Treasury Safe 上。总而言之，Yearn 构建了一个自定义 Hook（称为 Guard），但忘记正确初始化它。由于不幸的事件组合，攻击者能够从 Hook 中删除交易白名单，从而有效地拒绝对保险箱提供服务。幸运的是，Yearn 找到了一个聪明的方法来移除 Hook，但这一事件却险些导致金库永久堵塞。

安全方法概述

迄今为止已探索的两种主要方法是证明注册中心和模块许可系统。下面，我们将更深入地扩展这些内容并权衡它们的相对优点，特别是与不同类别的漏洞相关的优点。

认证登记处

模块化帐户安全的一种主要方法是使用链上的证明注册表来允许帐户获得有关即将安装或使用的模块的安全保证。这允许用户或应用程序开发人员确定他们可信的证明者，例如某些审计员，并在链上验证这种信任。从概念上讲，这有点类似于验证您将要交互和使用的合约的审计报告，但有两个关键区别：1）非技术用户可以使用此解决方案，2）验证是在链上运行的，从而使其愚弄人们要困难得多，例如冒充审计员。

实际上，证明注册表是受信任实体（例如审计员）做出的断言的链上存储。为了进行这样的证明，审计人员将编译一些数据，例如审计报告，并将其发布到链上，将其链接到被证明的模块。然后，当用户或开发人员想要安装或使用模块时，该帐户将查询链上注册表并确定受信任的实体是否已证明该模块是安全的。在实践中，我们可以根据我们的用例、智能账户模块定制数据，并包含更多相关数据，例如标准化模块清单和风险评分。

在 Rhinestone，我们一直在开发模块注册表，这是一个无需许可的注册表，我们获得了以太坊基金会的资助，并且 Biconomy 等模块化帐户构建器正在集成该注册表。Safe {Protocol}还包括在使用第三方模块时为用户提供安全性的注册表，并且 Safe 团队还一直在与不同的审计公司（例如OpenZeppelin、 OpenZeppelin、 Acee 区块链安全和 Hats 金融。

粗略地说，模块注册表有两个功能：首先，模块不会故意利用帐户；其次，确保模块按其应有的方式运行，并且即使以不符合规定的方式使用，也不能用于利用帐户。不是模块开发人员有意为之的。因此，模块注册表可以解决所讨论的所有潜在漏洞。尽管如此，这个解决方案也面临着一些挑战。其中包括：构建和维护可以由任何帐户安全使用的注册表、调整激励措施，以便充分激励证明者以确保模块安全、选择帐户信任的适当默认证明者列表以及对用户进行充分教育关于添加或删除受信任实体的安全影响。

此外，用户还可以在使用模块时通过查询注册表来获得持续的安全保证。例如，如果在模块上发现错误或漏洞，证明者可以撤销其在链上的证明，从而阻止模块的使用并阻止潜在的漏洞。使用注册表来实现持续安全的一个挑战是，证明者可以通过撤销关键模块来拒绝向帐户提供服务。虽然这是一个需要面对的重要挑战，但一些解决方案包括针对证明者的信誉系统，或者对安全关键模块使用广泛的独立证明者，这样只有在大多数证明者串通的情况下才能发起攻击。

模块权限系统

模块权限系统最初由ERC-4337 的合著者Yoav 提出，并从操作系统权限中获得了一些灵感。总的来说，这个想法是模块被授予在运行时强制执行的权限。例如，对帐户具有执行权的模块可能只能在一段时间内从帐户中转出一定数量的价值。

ERC-6900标准化了账户的权限系统，并定义了具体的权限。例如，模块可以通过帐户触发执行来使用的函数选择器和目标。模块在权限清单中声明其所需的权限，权限清单是模块字节码的一部分。

最近，我们创建了一个权限挂钩的原型，它可以安装在ERC-7579帐户上，以便在执行者在帐户上创建执行时强制执行类似的附加权限。有关这两个模块化帐户标准的安全性的更详细比较，请阅读下文。

总体而言，权限系统是增强帐户安全性的一种有用方法，但它的目的只是解决一组非常具体的漏洞，即模块可以在帐户上触发的执行。扩展这个想法以验证更多种类的权限的问题在于，其中许多权限在链上运行时验证是不可行的。例如，如果挂钩执行恢复的模块，帐户无法在运行时确定它是否因有效原因而恢复（不应执行执行），或者是否恢复以拒绝向帐户提供服务（在这种情况下，应忽略该情况） ）。这只能在离线审计代码时进行验证。

其他方法

其他模块化帐户安全方法的探索相对较少。可能受到更多关注的安全帐户或模块措施的一些示例包括模块断路器或受信任的链下监控方的交易共同签名。对于刚接触该领域的人来说，这是一个很好的参与领域，如果您研究过任何这些或其他方法，我们很乐意与您聊天！

不同的模块化账户标准和安全性

目前，模块化账户有两个标准：ERC-7579和ERC-6900。ERC-7579 采用最小的方法来标准化模块化帐户，允许帐户具有互操作性，而不会抑制帐户构建者的创新，包括引入新的安全方法。ERC-6900 对账户架构更具规范性和固执己见，特别规定了账户的大部分工作。

ERC-6900还代表帐户构建者做出一些安全选择，例如引入权限系统。该系统集成到帐户中，需要模块来实现权限清单。安装时，模块的权限存储在帐户中并在执行时进行验证。

相比之下，ERC-7579仅寻求解决模块互操作性，并不强制帐户实施特定的安全解决方案。这并不是因为安全性不重要，而是因为安全性是多方面的，任何单一解决方案都有非常具体的权衡。例如，如上所述，权限系统对于在某些流（特别是在帐户上排队执行的模块）添加安全保证很有用，但在其他情况下（例如当模块尝试拒绝向帐户提供服务时）则没有用。

这两个标准经常在安全方面进行讨论和比较。然而，这是一个有缺陷的比较点。安全性对于这两个标准的实施至关重要，而不仅仅是标准本身。然而，ERC-7579 不会代表帐户构建者做出固执己见的安全选择，因为上述安全系统尚未在生产中使用。因此，在致力于建立一个特定的安全系统之前，我们认为我们应该首先促进创新和实验，以便我们以后可以在需要时标准化具体的实施。在 ERC-7579 的背景下，这将通过扩展来完成。ERC-7484就是一个例子，这是 ERC-7579 的注册表扩展，帐户可以选择遵守该扩展以利用证明注册表。此外，目前正在开发许多许可挂钩，可以将其安装在任何 ERC-7579 帐户上以获得额外的安全性。考虑到安全方面的创新和未来标准化，ERC-7579 可以只专注于一件事：解决供应商锁定和生态系统碎片化问题的基本互操作性，而不会扼杀模块化帐户创新。

由于这种可选性，ERC-7579 帐户可以轻松实现权限系统，无论是直接在帐户中还是作为挂钩模块。ZeroDev Kernel v3 是一个（至少部分）追求前者的帐户示例。后者通常更适合未来，因为它允许对权限系统进行更改和添加（例如新的权限类型），而不需要更改帐户（并且可能需要更改标准）。在这方面，Safe v1.5引入了模块回调挂钩，使权限系统能够监管哪些执行模块可以在帐户上触发。最后，将安全解决方案构建为模块还允许外部开发人员（而不仅仅是帐户构建者）贡献和构建安全解决方案，从而带来更多的选择。

值得注意的一点是，ERC-7579 引入了模块类型：验证器、执行器、钩子、回退处理程序，未来的扩展可能会引入新类型。这本身就是一个非常原始的许可系统。其原因是不同的模块类型被授予不同的访问权限，这些权限由帐户强制执行。例如，只有执行者可以调用帐户来触发执行。这意味着在 ERC-7579 的上下文中，验证器声明其执行权限是毫无意义的，因为它无法创建执行。因此，在 ERC-7579 上，仅在钩子中构建复杂的模块安全系统也变得更加可行，因为这些系统总是在执行器调用帐户时被调用。虽然这有额外执行成本的缺点，

结论

模块化帐户的安全性是一个多方面的挑战，我们才刚刚开始触及可能解决方案的表面。迄今为止探索的两个主要解决方案是证明注册中心和模块许可系统。前者允许在链上验证链下安全审查，例如手动审计、模糊测试、静态分析、形式验证等。后者允许帐户定义模块具有哪些执行权限，并在模块触发执行时验证这些权限。然而，这两种方法都需要在安全覆盖范围、性能、面向未来、去中心化等之间进行微妙的权衡。