揭秘模块化智能账户安全

深入探讨模块安全的不同新兴方法

特别感谢 Clem、Derek、Sachin 和 Adam 的反馈和审查。

模块化智能账户为智能账户引入了一种新的范式，它允许扩展性和面向未来。然而，模块化账户比单体或集成账户更复杂，它们的安全性需要更多的关注，尤其是在安装第三方模块时。过去一年里，关于模块化账户安全的讨论一直在进行，例如围绕移除 delegatecall 的辩论。这场辩论围绕着在智能账户中结合使用 ERC-2535 Diamond Proxies 以及相关的安全问题展开。除此之外，围绕安全性的公开辩论相对稀少。

本博客文章的目标是概述保护模块化账户的不同方法，并概述每种方法的潜在优点和缺点。

场景设定

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

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

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

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

到目前为止，模块账户安全有两种新兴方法：证明注册表和模块权限系统。尚未深入探讨的替代方法包括断路器或基于链下监控的交易联合签名。后者的一个例子是 Argent Shield，它提供了一种向你的账户添加受信任的联合签名人的方法。

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

安全问题

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

• 允许代表账户执行的模块可以执行任意执行，例如将所有资金从账户中转出
• 执行验证的模块可以允许账户执行任何执行
• 使用 delegatecall 调用的模块可以 selfdestruct 账户
• 在账户上具有存储访问权限的模块（使用 delegatecall 调用时）可以接管账户或使其损坏
• 执行验证的模块可以对账户发起拒绝服务攻击
• 钩住其他进程的模块可以对账户发起拒绝服务攻击
• 在卸载期间，模块可能会回滚或导致 OOG 回滚，这可能会导致模块“无法卸载”
• 在卸载期间，模块可能无法充分清理其配置，从而导致意外行为，甚至在重新安装时可能导致失去对账户的访问权限

以上是一些可能出现的模块漏洞的示例，但可能出现许多其他漏洞。这种漏洞的一个例子发生在 Yearn 金库 Safe 上。总而言之，Yearn 构建了一个自定义 Hook（称为 Guard），但忘记正确初始化它。由于一系列不幸的事件，攻击者能够从 Hook 中删除交易白名单，从而有效地拒绝了 Safe 的服务。幸运的是，Yearn 找到了一种巧妙的方法来删除 Hook，但该事件差点永久损坏金库。

安全方法概述

到目前为止，已经探索的两种主要方法是证明注册表和模块权限系统。下面，我们更深入地探讨这些方法，并权衡它们的相对优点，尤其是在与不同类别的漏洞相关的方面。

证明注册表

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

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

在 Rhinestone，我们一直在开发 模块注册表，这是一个无需许可的注册表，我们获得了以太坊基金会的资助，并且像 Biconomy 这样的模块化账户构建者正在集成它。Safe{Protocol} 还包括注册表，以便在使用第三方模块时为用户提供安全性，并且 Safe 团队还一直在开发 ERC-7512，该标准与不同的审计公司（例如 [OpenZeppelin、Ackee Blockchain Security 和 Hats Finance]）一起，标准化了审计报告上链的方式。

粗略地说，模块注册表有两个功能：首先，模块不会故意利用账户，其次，确保模块按预期运行，并且即使以模块开发人员未想到的方式使用，也不会被用来利用账户。因此，模块注册表可以解决讨论的所有潜在漏洞。尽管如此，此解决方案并非没有其自身的挑战。其中包括：构建和维护一个可以安全地被任何账户使用的注册表，对齐激励措施，以便充分激励证明者以确保模块安全，选择账户信任的适当的默认证明者列表，以及充分教育用户有关添加或删除受信任实体的安全含义。

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

模块权限系统

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

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

最近，我们创建了一个 权限Hook原型，该Hook可以安装在 ERC-7579 账户上，以便在执行者在账户上创建执行时强制执行类似的和其他权限。有关这两种模块化账户标准的安全性更详细的比较，请继续阅读下文。

总的来说，权限系统是强制执行账户安全性的有用方法，但它仅旨在应对一组非常特定的漏洞，即模块可以在账户上触发哪些执行。将此想法扩展到验证更大范围的权限的问题在于，其中许多权限无法在链上运行时进行验证。例如，如果钩住执行的回滚模块，则账户无法在运行时确定它是否因有效原因（不应进行执行）而回滚，或者它是否回滚以拒绝向账户提供服务（在这种情况下应忽略）。这只能在链下审计代码时进行验证。

其他方法

模块化账户安全的其他方法尚未得到充分的探索。一些可能受到更多关注的安全账户或模块措施的示例包括模块断路器或受信任的链下监控方对交易进行联合签名。对于进入该领域的新手来说，这是一个很好的参与领域，如果你已经研究过这些或其他方法，我们很乐意与你聊天！

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

目前，模块化账户有两种标准：ERC-7579 和 ERC-6900。ERC-7579 采用最小方法来标准化模块化账户，允许账户互操作而不会扼杀账户构建者的创新，包括引入新的安全方法。ERC-6900 对账户架构更具规范性和主观性，特别是强制规定账户的各个大部分如何工作。

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

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

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

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

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

结论

模块化账户的安全性是一项多方面的挑战，我们才刚刚开始触及可能的解决方案的表面。到目前为止，已经探索的两种主要解决方案是证明注册表和模块权限系统。前者允许链下安全审查（例如手动审计、模糊测试、静态分析、形式验证等等）在链上进行验证。后者允许账户定义模块具有哪些执行权限，并在模块触发执行时验证这些权限。但是，这两种方法都需要对安全性覆盖范围、性能、前瞻性、去中心化等之间的权衡做出细致的选择。

如果你是一名开发人员或审计师，并且你想参与智能账户安全方面的前沿研究和开发，我们很乐意与你聊天。此外，你应该参与社区，例如 4337 Mafia 或 模块化账户标准 群聊。要了解有关模块化账户、互操作性或安全性的更多信息，请查看我们的 博客 并关注我们的 Twitter 以获取最新信息。

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