SevenX Ventures：模块化智能合约账户架构和挑战

本文为 SevenX 研究团队原创，仅供交流学习，不构成任何投资参考。如需引用，请注明来源。

原版英文报告于 2023 年 9 月发表于 SevenX 的 Mirror 平台。更多中文投研内容，请关注公众号【SevenXVentures】。

感谢 Safe 的联合创始人 Lukas、Alchemy 的工程主管 Noam、Rhinestone 的联合创始人 Kurt 和 Konrad 以及 HashKey Capital 的投资人 Arnav。

编者按：智能合约账户（SCA）的发展势头强劲，得到了包括 Vitalik 在内的许多核心创业者的支持，然而 SCA 的采用仍面临诸多挑战。账户抽象（AA）的优势在于使用代码自定义功能，但其非互操作性带来了集成和供应商锁定问题。模块化账户抽象旨在创建一个模块化结构，以开发具有多样功能、安全且无缝集成的钱包。

SevenX Ventures 投资人 Rui 指出了采用 SCA 面临的五大挑战，即熊市影响、迁移难度、签名问题、高昂的 Gas 成本和工程难题，并对工程难题做了更进一步的讨论。此外，在对模块化智能合约账户的架构进行分析后指出，模块化 SCA 只是采用难题的一小部分。

为了充分发挥 SCA 的潜力，需要 Layer 2 解决方案提供额外的协议层支持，强大的 bundler 基础设施和点对点内存池、更具成本效益和可行的 SCA 签名机制、跨链 SCA 同步和管理机制，以及开发用户友好的界面等。

在未来，目前的挑战逐步解决，会有更多人采用 SCA，那么接下来又会发生什么？Rui 对此也提出了一些有趣的问题。BlockBeats 将原文编译如下：

从外部拥有账户（EOA）向智能合约账户（SCA）的转变势头强劲，并已经得到了包括 Vitalik 等许多核心创业者的支持。尽管如此，SCA 的采用却并不像 EOA 那样广泛。这其中的主要问题包括熊市带来的影响、eoa 到 sca 的迁移难度、签名问题、Gas 成本过高以及最为关键的开发难题。

账户抽象（AA）的最显著优势是能够使用代码自定义功能。然而，AA 功能的非互操作性带来了主要挑战，这种分散性会阻碍 AA 集成，并且加强了供应商锁定。除此之外，在可升级与可组合同时保障安全性也是重要挑战。

模块化账户抽象的出现是 AA 发展趋势中的一个细分领域，这种创新的方法可以将智能账户与其自定义功能分离。其目标是创建一个模块化结构，来开发具有多样功能、安全、无缝集成的钱包。未来，模块化账户抽象可以实现一个自由的智能合约账户「应用商店」，使钱包和 dApp 专注于改进用户体验，而不必在构建功能上花费太多精力。

简述账户抽象（AA）

在人们接触区块链的过程中，传统的 EOA 带来了许多挑战，如助记词、Gas 费用、跨链操作和多发交易等。

账户抽象利用智能合约账户，允许可编程验证（validation）和执行（execution）。这意味着用户将能够一次性批准一系列交易，而不再需要对每个交易都签名和广播。账户抽象还可以实现更多功能，如改进用户体验（如 Gas 抽象和会话密钥）、降低成本（如批量交易）和提高安全性（如社交恢复、多重签名）。目前，有两种实现账户抽象的方式：

• 协议层：一些协议本身提供了本地账户抽象支持，ZKSync 交易使用单个内存池和交易流程来支持 AA；无论是来自 EOA 还是 SCA 都遵循相同的流程，而 Starknet 已经移除了 EOA，所有账户都是 SCA，并且他们有像 Argent 这样的本地智能合约钱包。

• 合约层：对于以太坊及类似的 L2，ERC 4337 引入了一个单独的 mempool，以在不改变共识层的情况下支持 AA。像 Stackup、Alchemy、Etherspot、Biconomy、Candide 和 Plimico 正在构建 bundler 基础设施，而像 Safe、Zerodev、Etherspot 和 Biconomy 正在构建 bundler 和 SDK。

  采用 SCA 面临的困境

  自 2015 年以来，账户抽象（AA）的话题一直被讨论，并在今年由 ERC 4337 进一步将其推进人们的视线中。然而，已部署的智能合约账户数量仍然远远不及 EOA。

  让我们深入研究这个困境：

  1. 熊市的影响

  尽管 AA 拥有了诸如无缝登录和 Gas 抽象等优势，在当下的熊市，所有用户都是已被教育的 EOA 用户，而没有太多新用户，因此 dApp 和钱包并没有动力去采用 SCA。即便如此，一些领先的 dApp 在逐步采用 AA，例如 Cyberconnect 通过引入他们的 AA 系统和无 Gas 解决方案，仅一个月就带动了约 36 万次 UserOps（AA 交易）。

  2. 迁移障碍

  对于已经积累了用户和资产的钱包和应用程序来说，安全、便捷地迁移资产仍然是一个挑战。不过，像 EIP-7377 这样的方案可允许 EOA 发起一次性迁移交易。

  3. 签名问题

  智能合约本身无法签署消息，因为它没有像 EOA 那样的私钥。类似 ERC 1271 的尝试使之成为可能，但消息签名在第一笔交易之前不起作用的，这又对于使用反事实部署的钱包提出了挑战。由 Ambire 提出的 ERC-6492 是 ERC-1271 向后兼容的继任者，也许能够解决之前的问题。

  4. Gas 成本

  与标准 EOA 相比，部署、模拟和执行 SCA 会产生更高的成本，这也成为了采用障碍之一。不过，目前已经进行了一些测试，例如将账户创建与用户操作分离、消除与某个账户相关的 "salt" 等。

  5. 工程难题

  ERC-4337 团队已经建立了 eth-infinitism repo，为开发人员提供了基础实现。然而，随着开发者针对不同的用例扩展到更细致和具体的功能时，集成和解码会面临更多挑战。在本文中，我们将深入探讨工程难题。

  通过模块化智能合约账户来解决工程难题

  工程难题可进一步阐述为碎片化、安全性和可升级性三个方面。

  • 碎片化

    现在可以通过多种方式启用功能，无论是通过特定的 SCA 还是通过独立的插件系统。每个平台和服务商都遵循自己的标准，促使开发者决定支持哪些平台和服务商。这可能导致潜在的平台（供应商）锁定或冗余工作。

  • 安全性

    虽然账户和功能解耦带来了灵活性的优势，但也可能使安全问题更严重。因为所有功能可能会被一同审核，而缺乏独立评估可能会增加账户漏洞的风险。

  • 可升级性

    随着账户的发展，保持添加、替换或删除功能的能力非常重要，重新部署现有功能的每次更新都会引入复杂性。

    为了应对这些问题，我们需要可升级的合约以确保安全高效的升级、可复用的核心以提高整体开发效率、以及标准化的接口来确保合约账户能够在不同的前端之间平稳过渡。

    这些术语汇聚于一个共同的概念：构建模块化账户抽象架构（模块化 AA）。

    模块化账户抽象是广泛的 AA 发展中的一个细分领域，它设想将智能账户模块化，以定制化地为用户提供服务，并使开发者能够在最小限制下无缝增强功能。

    然而，在任何行业中建立和推广新的标准都是一个巨大的挑战。在大家都接受同一标准之前，初始阶段可能会出现许多不同的解决方案。令人鼓舞的是看到那些致力于完善和推广账户抽象的人们，无论是 4337 SDK、钱包、基础设施团队还是协议层设计师，他们都在共同努力加快这一进程。

    模块化结构：主账户和模块

    账户如何调用模块实现功能

    委托调用（Delegate call）和代理合约（proxy contract）

    外部调用和委托调用：

    关于委托调用

    虽然「委托调用」与「调用」类似，但它不是在目标合约的 context 中执行，而是在调用合约的当前状态的 context 执行它。这意味着目标合约所做的任何状态更改都会更改调用合约的存储。

    代理合约和委托调用

    要实现可组合、可升级的结构，需要引入一个基础概念「代理合约」。

    • 代理合约：普通合约存储其逻辑和状态，部署后无法更新。而代理合约使用委托调用（delegate call）部署到另一个合约。通过引用实现函数，在代理合约的当前状态下执行它。

    • 使用案例：虽然代理合约保持不变，但您可以在代理后面部署新的实现。代理合约实现了可升级性，且在公共区块链上的部署和维护成本更低。

      Safe 架构

      Safe 架构

      什么是 Safe ：

      Safe 是领先的模块化智能账户基础设施，旨在提供经过实战考验的安全性和灵活性，它使开发人员能够创建多样化的应用程序和钱包。许多团队正在 Safe 基础上（或受 Safe 启发）构建应用。例如，Biconomy 在推出其智能合约账户时，使用原生 4337 和 1/1 多重签名来拓展 Safe。Safe 见证了超过 164, 000 份合约的部署并锁定了超过 307 亿美元的价值，毫无疑问是该领域的佼佼者。

      Safe 的结构包括安全账户合约、单例合约、模块合约。

      • 安全账户合约（proxy contract）：主代理合约（Stateful）

        安全账户是一个代理合约，这是因为委托调用是一个单例合约。安全帐户包含所有者、阈值和实现地址都设置为代理的变量，基于这些定义其状态。

      • 单例合约（singleton contract）：Integration Hub（无状态）

        单例合约服务于 Safe 账户，并定义了不同的模块合约集成，包括 Plugin、Hook、Function Handler 和 Signature Validator。

      • 模块合约（modules）：自定义逻辑和功能

        模块合约功能强大。插件作为模块化类型可以定义不同的功能，例如支付流、恢复机制和会话密钥，并且可以通过获取链外数据作为 Web2 和 Web3 之间的桥梁。其他模块如作为安全防护的 Hook 和 Function Handler 可响应任何指令。

        采用 Safe 后带来的改变：

        • 可升级合约：每当引入新插件时都需要部署新的单例。用户保留将 Safe 升级到所需单例版本的自主权。

        • 可组合、可重用的模块：插件的模块化特性使开发人员能够独立地开发功能。他们可以根据自己的用例自由选择和组合这些插件，从而形成高度可定制的方法。

          ERC-2535 Diamond 代理

          关于 ERC 2535、 Diamond 代理：

          • ERC 2535 标准化的 Diamond 模型，这是一种模块化智能合约系统，可以在部署后升级/扩展，且几乎没有大小限制。目前，很多团队如 Zerodev 的 Kernel、Soul Wallet 的实验都受到了 Diamond 结构的启发。

            什么是 Diamond 结构：

            • Diamond 合约：主要代理合约（有状态）Diamond 是一种代理合约，它使用 委托调用方法从其实现中调用函数。

            • 模块/插件/ Facet 合约：自定义逻辑和功能（无状态）模块或所谓的 Facet 是一种无状态合约，可以将其功能部署到一个或多个 Diamond。它们是单独的、独立的合约，可以共享内部函数、库和状态变量。

              采用 Diamond 后带来的改变：

              • 可升级合约：Diamond 提供了一种系统的方法来隔离不同的插件并将它们连接在一起，在它们之间共享数据，还可以使用 diamondCut 功能直接添加/替换/删除任何插件。随着时间的推移，可以添加到 Diamond 的插件数量将没有限制。

              • 模块化且可复用的插件：已部署的插件可以被任意数量的 Diamond 使用，从而极大地降低部署成本。

                Safe 智能账户与 Diamond 方式的区别：

                Safe 和 Diamond 架构之间存在很多相似之处，两者都依赖于其核心的代理合约并引用逻辑合约来实现可升级性和模块化。

                两者的主要区别在于逻辑契约的处理。具体来说：

                • 灵活性：在启用新插件的情况下，Safe 需要重新部署其单例合约（Singleton）以实现其代理中的更改。相比之下，Diamond 直接通过其代理合约中的 diamondCut 函数来实现这一点。这种方法上的差异意味着 Safe 保留了更高程度的控制，而 Diamond 则引入了增强的灵活性和模块化。

                • 安全：目前在两种结构中使用的，可以允许外部代码操纵主合约的存储。在 Safe 架构中，委托调用指向单个逻辑合约，而 Diamond 则在多个模块合约-插件中使用委托调用。因此，恶意插件有可能覆盖另一个插件，从而引入存储冲突的风险，损害代理的完整性。

                • 成本：Diamond 方法中，灵活性与安全隐患同时存在。这增加了成本，每次添加新插件都需要进行全面审核。关键是要确保这些插件不会干扰彼此的功能，这一目的具有挑战性，特别是对于努力维持高安全标准的中小型企业而言。

                  「Safe 智能账户方法」和「Diamond 方法」是涉及代理和模块的不同结构的示例。如何平衡灵活性和安全性至关重要，这两种方法未来也将会不断演变、相互补充。

                  模块顺序：验证器（Validator)、执行器 (Executor) 和挂钩 (Hook)

                  让我们通过介绍 ERC-6900 来进一步讨论，这是 Alchemy 团队提出的、受 Diamond 启发、专门为 ERC-4337 量身定制的标准。它通过提供通用接口来解决智能账户模块化的挑战，并协调插件和钱包开发人员之间的工作。

                  说到 AA 的交易流程，主要有三个流程：验证、执行、挂钩。正如我们前面所讨论的，这些步骤都可以通过使用代理帐户调用模块来管理。虽然不同的项目可能使用不同的名称，但掌握相似的底层逻辑很重要。

                  不同设计中的函数名称

                  • 验证 (Validator)：确保帐户调用者的真实性和权限。

                  • 执行 (Executor)：执行帐户允许的任何自定义逻辑。

                  • 挂钩 (Hook)：充当在另一个函数之前或之后运行的模块。它可以修改状态或撤销整个调用。

                    ERC 6900 

                    根据不同的逻辑来分离模块至关重要。标准化方法应该规定如何编写智能合约帐户的验证、执行和挂钩函数。无论是 Safe 还是 ERC-6900 ，标准化都有助于减少特定于某些实施或生态系统的独特开发工作的需求，并防止供应商锁定。

                    模块发现和安全

                    如何以开放的方式查找和验证模块：一个正在推进的解决方案涉及创建一个允许用户发现可验证模块的区域，可以将其称为「注册表」。该注册表的功能类似于「应用程序商店」，旨在培育一个简化但蓬勃发展的模块化市场。

                    Safe{Core} 协议

                    Safe{Core} 协议是一种针对智能合约账户的开源、可互操作的协议，旨在增强各种供应商和开发人员的可访问性，同时通过明确定义的标准和规则来保持强大的安全性。

                    • 账户：在 Safe{Core} 协议中，账户的概念是灵活的，不受特定实现的约束。这使得不同的账户服务提供商能够参与其中。

                    • 管理器：管理器充当帐户、注册表和模块之间的协调员。它还作为许可层负责安全性。

                    • 注册中心：注册中心定义安全属性并执行 ERC 6900 等模块标准，旨在创建一个开放的「应用程序商店」环境，以实现可发现性和安全性。

                    • 模块：模块处理功能并具有各种初始类型，包括插件、挂钩、签名验证器和函数处理程序。只要符合既定标准，开发人员就可以参与其中。

                      Rhinestone 设计

                      该过程展开如下：

                      • 创建架构定义（schema）：架构提供预定义数据结构。人们可以对其进行定制，以符合其特定的用例。

                      • 基于架构创建模块（modules）：注册为模块的智能合约获取字节码并选择架构 ID，数据就会被存储在注册表中。

                      • 获得模块的证明（attestation）：证明者/审核员可以基于架构为模块提供证明。这些证明可包括唯一标识符 (UID) 以及对用于链接的其他证明的引用。它们可以跨链传播并验证目标链是否满足特定阈值。

                      • 使用解析器（resolver）实现复杂逻辑：解析器（可选设置）开始发挥作用。它们可以在模块创建、证明建立和撤销期间被调用。这些解析器允许开发人员整合复杂且多样化的逻辑，同时维护证明结构。

                      • 用户友好的查询访问（query）：查询为用户提供了一种从前端访问安全信息的方法。

                        虽然该模式还处于早期阶段，但它具有以分散和协作的方式建立标准的潜力。注册表使开发人员能够注册他们的模块，审计员能够验证其安全性，钱包能够进行集成，并使用户能够轻松找到模块并验证其证明信息。未来的几种用途可能是：

                        • 证明者（attestor）：像 Safe 这样值得信赖的实体可以与 Rhinestone 合作，共同作为内部模块的证明者。同时，独立证明者也可以加入。

                        • 模块开发人员（module developer）：随着开放市场的形成，模块开发人员有可能通过注册表将他们的工作货币化。

                        • 用户：通过用户友好的界面（例如钱包或 dApp）进行参与，用户可以检查模块信息并将信任委托给不同的证明者。

                          「模块注册表」的概念为插件和模块开发人员开辟了盈利途径。它可以进一步为「模块市场」铺平道路。某些方面可能由 Safe 团队监督，而其他方面可能表现为去中心化市场，邀请所有人做出贡献并提供透明的审计记录。整合这一点可以避免供应商锁定，并通过添加能够吸引更广泛受众的增强用户体验来支持 EVM 的扩展。

                          虽然这些方法能保证单个模块的安全，但在更广泛的安全性方面，智能合约账户并不是万无一失的。与合规模块结合并证明它们没有存储冲突可能是一个挑战，这凸显了钱包或 AA 基础设施在解决此类问题方面的重要性。

                          总结

                          通过利用模块化智能合约账户堆栈，钱包提供商和 dApp 可以从技术维护的复杂性中解放出来。同时，外部模块开发人员有机会提供个性化的专业服务。然而，需要解决的挑战包括在灵活性和安全性之间取得平衡，推动模块化标准，以及实施标准化接口，使用户能够轻松升级和修改其智能帐户。

                          此外，模块化智能合约账户（SCA）只是采用难题的一小部分。为了充分发挥 SCA 的潜力，需要 Layer 2 解决方案提供额外的协议层支持，例如强壮的 bundler 基础设施和点对点内存池、更具成本效益和可行的 SCA 签名机制、跨链 SCA 同步和管理机制，以及开发用户友好的界面。

                          未来，将会有更多人采用 SCA，但也会引发一些有趣的问题：一旦 SCA 订单流变得有足够利益可图，传统的矿工可提取价值 (MEV) 机制将如何进入该领域构建捆绑器并获取价值？当基础设施成熟后，账户抽象（AA）如何作为「基于意图」交易的基础层？让我们拭目以待。