将 10 亿人引入链上的正和博弈

积极和博弈以将 10 亿人带入链上

Noam Hurwitz

关于模块化账户标准的技术评论

向智能账户的过渡是将主流用户引入链上的关键一步。在过去的一年中，我们看到了智能账户领域的创新井喷，以及模块化智能账户的出现，这些账户可以通过插件安装来扩展链上账户功能。最近，在模块化账户标准领域围绕 ERC-6900 和 ERC-7579 这两个标准展开了大量讨论。我们认为这两者的基本原理都很好，并推动了生态系统的发展，并希望分享关于从此处进一步讨论的想法，并提供关于这两个标准的技术评论。

我们注意到围绕这些标准存在许多误解，并希望首先尝试高亮显示其中一些最新的想法。在我们这样做之前，请注意。围绕这两个标准的讨论很棒，并且绝对有必要推动生态系统的发展，我们感谢这里的广泛视角和意见，它们促进了伟大的讨论。也就是说，一旦它变成团队互相攻击，它就会变成零和游戏，而不是建设性的。对我们来说，并且希望对你们所有人来说，保持框架和讨论的积极性以继续扩大蛋糕非常重要。

因此，我们很失望地看到了 ZeroDev 博客文章 (https://learnblockchain.cn/article/16191) 的语气和内容，据传闻，这篇文章一直在推动许多这些误解。我们认为看到如此多的团队在该领域进行迭代，并贡献资源和资本来进一步发展公共领域是很棒的，并希望以建设性的态度鼓励和继续参与其中。

在本文中，我们涵盖：

• 对 ZeroDev 博客文章的技术纠正。

• 7579 与 6900 的快速架构概述，超越权限。

• 正在进行的努力的总结，以简化 7579 和 6900 之间的接口和方法，以最大程度地减少未来采用这两种标准时可能遇到的工作 - 包括向 7579 社区提出的开放技术问题。

• 关于权限的说明，为什么它们很重要，以及它们如何融入更广泛的智能账户安全故事中。

• 对 ZeroDev 博客文章的程序性更正。

• 结论中的摘要。

对“为什么选择 7579 而不是 6900”的技术更正

博客文章的作者可能忽略了一些问题，我们想澄清：

• 聚合器在 6900 中并未被禁止，并且验证函数可能会返回它们。混淆可能来自预验证Hook，这些Hook可能不会返回它们，因为账户没有明确定义的方式一次使用多个聚合器。

• 使用当前 7579 规范无法将 6900 作为 7579 的扩展来实现。ERC-6900 插件取决于将执行函数与特定验证函数连接。ERC-7579 要求遵守特定的安装流程，但使验证和执行函数的关联不明确，这使得原子配置关联的验证和执行函数成为不可能。下面“没有将执行与验证相关联的标准方法”中有更多内容。

• 可以在验证期间安装插件。已发布的 ERC-6900 多所有者插件默认情况下不执行此操作，但是 6900 允许在验证期间执行插件安装。有一系列单元测试证明了这一点，示例在此处 (https://github.com/alchemyplatform/modular-account/blob/v1.0.1/test/account/phases/AccountStatePhasesUOValidation.t.sol#L811)。

7579 的架构审查

一般主题

由于 ERC-7579 如此注重向账户开发者授予灵活性，因此它没有充分标准化账户行为，以致于插件无法在不同的账户实现之间进行推广。也就是说，为一个 7579 账户开发的插件不一定适用于其他 7579 账户，这限制了互操作性，并且无法解决供应商锁定问题。

深入研究

没有将执行与验证相关联的标准方法

• 7579 没有说明 (https://eips.ethereum.org/EIPS/eip-7579#validation) 如何决定可以使用哪些验证器来验证哪些调用。因此，你可能会有两个不同的符合 7579 的账户，其中：

  • 一个账户表示可以使用任何已安装的验证器来批准任何调用（验证器全局应用于任何执行函数）。

  • 另一个账户具有某种指定某些调用需要某些验证器的方式，因此它能够拥有，例如，所有者验证器和会话密钥验证器，其中某些执行需要某些验证器。

• 问题在于，由于 7579 未规定如何关联验证和执行，因此无法编写一个模块（插件），该模块要求以在所有账户实现中都有效的方式将特定执行与特定验证一起使用。

• 我们认为这是互操作性的一个严重问题。到目前为止，我们编写的每个插件（多所有者，会话密钥，冷存储）都需要将验证与执行相关联，这是其核心功能的一部分。

• 这不能留给每个账户的实现而定：为与一个账户一起使用的插件将不能与其他账户一起使用。

• 这里要考虑的两个示例场景：

  • 插件想要添加只能在它自己定义的验证之后发生的执行行为，例如会话密钥验证。

  • 插件想要添加只能在由其他插件定义的验证之后发生的执行行为，例如所有者密钥验证。

• 尝试标准化插件可以指定每种执行行为的方式可能会导致与 6900 清单的执行函数和依赖项部分类似的路径。

没有传递给Hook的标准数据格式

• 一个 “hook” 插件可以定义一个 `preCheck` Hook，该Hook将传递给智能账户的 `msgData` 。但是该标准将此数据的结构留给每个账户的实现而定，其中数据可能以某种方式指示哪个执行模块应该执行某些操作并对该模块的数据进行编码。因此，必须为特定的 calldata 解释编写 hook 模块，并且该模块与特定的账户实现相关联。

没有验证Hook

• 这使得实现通用 gas 限制变得困难或不可能。如果攻击者能够验证任何操作，则未仔细限制 gas 支出的账户极易被耗尽资金。在 7579 下，每个验证函数都需要构建自己的防御措施来抵御这种情况。

• 可能是意图你可以向某个事物添加多个验证，并要求它们全部通过，基本上将验证视为一个验证Hook。如果是这样，则没有标准化的方式来执行此操作，这意味着一个账户适用的插件不适用于其他账户。

• 公平地说，目前在 6900 也不完全可能实现通用 gas 限制，但是可能性更高（只需添加适用于任何执行函数的验证Hook）。

没有仅运行某些Hook的标准方法

• 插件作者可能希望其Hook仅围绕某个调用运行，但是没有标准的方法可以让Hook指示这一点。这意味着没有比所有调用都运行所有Hook更好的标准机制（并且每个Hook在不适用于该调用时都不执行任何操作），这会浪费 gas。虽然账户可以实现自己的允许Hook配置的方式，但围绕一种此类机制构建的Hook将不适用于其他Hook。

努力融合 7579 和 6900

有一个工作流程正在努力简化 ERC-7579 和 ERC-6900 之间的接口，以便在某些情况下插件可以与这两种标准兼容。通常，目标是共同发展围绕模块化智能账户这个令人兴奋但规模较小且新兴的生态系统。到目前为止，大多数的对话都集中在权限模型上。无论是否有权限，还有其他一些方法可以改进这两种提案，值得追求。下面将详细介绍权限组件。

我们要感谢 Rhinestone 的 Konrad 启动了这个工作流程，并提供了一份高亮显示现有差异的文档在此处 (https://docs.google.com/document/d/1hsGJGPd2micBbgFKgPbFioD6HEO56p0SEnsJ_U8NQ3U/edit#heading=h.9eou8tfgez2)。请参阅**此处** (https://docs.google.com/document/d/17MIK1oELTdBdknnDd56cT8MyVBTg6bDd9Doe3INRJ8s/edit) 的持续讨论。

权限和模块化智能账户安全性

每个人的目标都是为最终用户提供具有插件的最大安全智能账户。安全性很复杂，没有万能的解决方案 - 没有一个解决方案可以使账户系统突然变得“安全”。因此，考虑从应用程序构思到 UserOperations 的运行时执行以及介于两者之间的所有内容的总体验证故事是有用的。

ERC-6900 风格的权限如何帮助保护账户

ERC-6900 权限很重要，可以限制插件在运行时可以访问的范围，并且此限制是在安装插件后立即定义的。这不是全面的，只是总体验证故事的一部分（尽管是关键的一部分），因为它限制了任意第三方软件可以在用户账户上执行的操作。

将此插件安装到账户的流程类似于当今将应用程序安装到 Android 等操作系统中的方式。插件从账户请求权限，就像 Android 应用程序从用户设备上的 Android 操作系统请求权限一样。例如，当我安装像 WhatsApp 这样的应用程序时，操作系统会请求一组应用程序 WhatsApp 需要正确执行的权限，例如我的位置、访问我的相机、访问我的麦克风、访问我的联系人等。我，用户，更关心应用程序，并认为它与授予的一组权限相关联。目前在 ERC-6900 中，这些都是永久权限（只要安装了该插件），但是也有一个提案 (https://github.com/erc6900/resources/issues/33) 来支持每次使用权限（例如，每次我打开 WhatsApp 时都请求使用我的位置）。

为了从不同的应用程序添加插件，你需要限制其信任要求 - 否则，如上所述，它们能够在用户的账户上执行任意软件，这可能会导致完全损失。如果没有某种账户强制执行的权限，则无法最大程度地减少这种信任要求。每个插件都可以在账户中执行任何操作，因此你只能添加你真正信任的插件。使用权限模型，你无需太在意插件的作用，只要它只能与你授权给它的合约进行交互即可。没有权限系统的账户将需要某种形式的许可插件商店。

智能账户的其他安全注意事项

正如我们在任何智能合约中看到的那样，始终存在大量的安全注意事项和无数的风险向量。当你处理用户账户时，这只会变得更加复杂，并且始终需要采用多方面的安全方法。

审计

到目前为止，并且在可预见的将来，审计将是智能合约安全性的主要组成部分。看到像 Quantstamp 和 Spearbit 这样的顶级公司通常都在加强智能账户方面的背景知识，这真是令人难以置信。他们的（和其他公司的）相关背景知识会随着时间的推移而不断积累，从而不断加强整个生态系统。权限并不能完全消除对审计的需求，尤其是对于所有权等关键流程。不过，它们很好地分层 - 允许用户配置自己的权限的一大原因是允许他们通过为自己选择的限制性权限来自信地安装插件。例如，如果我可以强制执行它只能与一个合约对话并且最多花费 10 美元，那么我可能愿意安装一个未经审计的插件。

漏洞赏金计划

漏洞赏金计划已被证明是利用经验丰富的白帽黑客来识别漏洞并最大程度地减少持续威胁暴露的有效机制。它为研究人员创建了激励机制，让他们在问题有可能影响最终用户之前发现并报告问题。我们与 HackerOne 启动了一个漏洞赏金计划，针对模块化账户的关键漏洞，奖励高达 100,000 美元的美元。

自动化安全测试

通过自动化测试和工具来增强审计将加快并降低开发过程的成本。有许多有前途的工具使开发人员能够在发布之前测试安全性不变性并分析其代码。列举一些：

• Slither 是一种静态分析工具，具有一套漏洞检测器，可以快速检查已知的反模式。我们强烈建议所有 Solidity 和 Vyper 开发人员将其包含在他们的 CI 管道中。

• Halmos 是 a16z 的一种开源形式验证工具。虽然并非所有内容都可以通过形式验证进行测试，但可以测试某些封闭属性，例如安装/卸载前后的状态。

• Octane 通过在包含过去漏洞的训练数据的现有代码库上训练 AI 模型来提供安全服务。这些模型非常强大，从我们的经验来看，它们检测到了审计中发现的许多问题（以及更多问题）。

• Fuzz 测试。我们这里还没有选择的工具，但是 fuzz 测试的基本概念是尝试使用随机或伪随机输入作为交易的参数，以查看我们是否可以达到意外状态。这是对形式验证等工具的很好的补充，因为它允许你概率性地测试开放属性。

插件注册表和证明

插件注册表提供了一个 “去中心化应用商店” 模型，团队和个人可以在其中证明插件的使用情况。这些团队的范围可以从审计师和安全供应商（如上面列出的那些）到已安装和使用该插件的用户。如果用户决定信任证明人来保证其安全性，则用户可以安装插件。虽然尚未构建任何插件注册表（据我们所知），但我们很高兴今年能看到一些插件注册表投入生产。在 Rhinestone 的 ERC-7484 中了解更多信息，或查看 Ditto Network，他们正在朝着类似的方向努力。

运行时验证

当用户构建、签名和发送交易时，存在许多风险向量。如今，许多公司都提供基本工具来确保用户可以信任他们签名的消息，这些消息Historically以无法读取的十六进制字符串的形式呈现。如今，像 Blockaid 这样的公司提供复杂的模拟，利用链上和链下数据来最大程度地减少运行时欺诈的威胁。

这也可以与基于插件的系统结合使用，以强制执行用户签名的模拟结果是在链上执行的结果，并使用 postExecution Hook来强制执行等效性。

实时威胁检测

如果我们已经走了这么远并且仍然存在漏洞，那么最好能够在任何恶意攻击者之前检测到它们。像 Forta 这样的协议会监视实时模式，以尝试在新的风险向量被利用之前检测到它们。人们也可以在此处想象一个插件，如果像 Forta 这样的协议注意到用户的账户可能存在漏洞，则能够暂时 “关闭” 用户的账户。

我们希望看到的其他方法是基于用户在链上的状态的实时模糊测试。这会不断发展模糊测试模型，以便仅针对有效的起始状态进行测试。

还有更多！

众所周知，安全性是一个难题，对于不可变的智能合约尤其如此。如果你正在考虑或构建安全领域，我们很乐意与你聊天！

对 “为什么选择 7579 而不是 6900” 的程序性更正

为了开始整理思路，我们想回到 ZeroDev 的博客文章，并就我们不同意的声明提出一些程序性更正。

• Alchemy 孵化 ERC-6900 的动机是与生态系统合作，以帮助推动智能账户的采用。为此，自从共同作者公开构建以及与以太坊基金会、Circle、Quantstamp、Spearbit、Collab.Land、Maple Finance、Decipher 和无数其他团队合作以来，该标准及其贡献者集都发生了显着的变化。为了使这项工作能够公开进行，我们会尽力做到这一点。我们与客户和团队（例如来自机构或 web2 领域的客户和团队）进行的一些讨论通常是在 NDA 下进行的，虽然我们需要将他们的反馈纳入设计中，但我们无法公开讨论其来源。仅仅因为它不可见并不意味着它没有发生。无论如何，如果存在反馈，则将这些批评锚定在技术优点上比锚定在感知到的贡献上更具有建设性。

• ERC-6900 周围的支架已经设计完成 - 包括 Github 存储库、 社区电话会议 s 和 标准 TG 频道，以及作为首批消息在那里列举的目标和指南 - 以促进公开贡献和对话，并且成为共同作者的标准自 2023 年 6 月以来已客观地定义并 公开。已经加入了多位共同作者，他们都有效地推动了该标准的发展。在标准最终确定之前，大门始终敞开。

结论

为了总结以上所有内容：关于模块化智能账户架构的讨论和各种意见对生态系统而言非常棒。我们很高兴看到在公共论坛上讨论了一系列想法，并希望支持那些正在推动链上可能实现的界限的构建者，以便将下一个十亿用户引入链上。我们希望这些对话保持建设性和客观性，以确保我们专注于帮助彼此扩大蛋糕。我们对快速发展的 ERC-6900 生态系统感到兴奋，并继续认为权限模型是解决安全领域特定问题的重要方法。我们也明白一切都有权衡，并很高兴看到开发人员探索 ERC-7579。希望以上一些反馈可以用于继续迭代该规范。最后，我们希望简化接口，以便开发人员可以在某个时候最大程度地利用两者的经验。

如果你有兴趣开始使用模块化账户抽象，请查看我们的快速入门指南在此处 (https://accountkit.alchemy.com/smart-accounts/modular-account/getting-started.html)。如果你想聊天，请随时通过 Telegram 或 X 联系 @probablynoam，或通过 Farcaster/Warpcast 联系 @noam - DM 始终开放。

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