模块化智能合约账户设计：解决落地技术难题

撰写：Rui S( SevenX Ventures)

编译：深潮 TechFlow

介绍

从外部拥有账户（EOA）向智能合约账户（SCA）的转变正在蓬勃发展，并得到了许多爱好者的支持，包括 Vitalik 本人。尽管引起了人们的兴奋，但 SCA 的采用并不像 EOA 那样普及。其中的关键问题包括熊市带来的挑战、迁移的担忧、签名问题、Gas 开销以及最关键的工程难题。

账户抽象（AA）最重要的优势之一是能够使用代码定制功能。然而，一个主要的工程挑战是 AA 功能的非互操作性，而这种碎片化阻碍了集成，并为供应商锁定打开了大门。此外，在同时升级和组合功能时确保安全性可能会很复杂。

模块化账户抽象的出现是更广泛的 AA 运动的一个子集，这种创新的方法可以将智能账户与其自定义功能分离。其目标是创建一个模块化结构，以开发具有多样功能的安全、无缝集成的钱包。在未来，它可以实现一个自由的智能合约账户“应用商店”，使钱包和 dApp 不再专注于构建功能，而是专注于用户体验。

AA 简述

传统的 EOA 引入了许多挑战，如种子短语、Gas、跨链和多个交易。我们从未打算引入复杂性，但事实上，区块链对于大众来说并不是一款简单的游戏。

账户抽象利用智能合约账户，允许可编程验证和执行，用户能够一次性批准一系列交易，而不是每个交易都要签名和广播，并实现更多功能。它为用户体验（例如，Gas 抽象和会话密钥）、成本（例如，批处理交易）和安全性（例如，社交恢复、多签名）带来了好处。目前，有两种实现账户抽象的方式：

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

• 合约层：对于以太坊及其等价的 L2，ERC4337 引入了一个单独的事务入口来支持 AA，而不改变共识层。像 Stackup、Alchemy、Etherspot、Biconomy、Candide 和 Plimico 这样的项目正在构建捆绑器基础设施，而像 Safe、Zerodev、Etherspot 和 Biconomy 这样的项目正在构建堆栈和 SDK。

SCA 采用的困境

自 2015 年以来，账户抽象（AA）的话题一直在讨论中，并在今年由 ERC4337 推动到了聚光灯下。然而，部署的智能合约账户数量仍然远远不及 EOA。

让我们深入探讨这个困境：

1. 熊市的影响：

尽管 AA 引入了诸如无缝登录和 Gas 抽象等好处，但当前经历熊市的人们主要由受过教育的 EOA 用户组成，而不是新用户，因此对于 dApp 和钱包来说并没有激励。即便如此，一些领先的应用程序仍在逐步采用 AA，例如 Cyberconnect 通过引入他们的 AA 系统和无 Gas 解决方案，仅一个月就带动了约 360,000 次 UserOps（AA 交易）。

2. 迁移障碍：

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

3. 签名问题：

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

4. Gas 开销：

部署、模拟和执行 SCA 相比标准 EOA 会产生更高的成本。这成为了采用的障碍。然而，已经进行了一些测试，例如将账户创建与用户操作解耦，并考虑消除账户盐和存在性检查，以减少这些成本。

5. 工程难题：

ERC-4337 团队已经建立了 eth-infinitism 存储库，为开发人员提供了基础实现。然而，随着我们在不同的用例中分支出更细致或特定的功能，集成和解码变得具有挑战性。

在本文中，我们将深入探讨第五个问题：工程难题。

模块化智能合约账户以解决工程难题

对于工程难题的进一步阐述如下：

• 碎片化：现在各种功能都以不同的方式启用，无论是通过特定的 SCA 还是独立的插件系统。每个都遵循自己的标准，迫使开发者决定要支持哪些平台。这可能导致平台锁定或重复努力。

• 安全性：虽然账户和功能之间的灵活性带来了优势，但也可能加剧安全问题。功能可能会被集体审计，但缺乏独立评估可能会增加账户漏洞的风险。

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

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

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

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

然而，在任何行业中，建立和推广新的标准都是一个巨大的挑战。在大家都接受主要解决方案之前，初始阶段可能会出现许多不同的解决方案。然而，令人鼓舞的是，无论是 4337 SDK、钱包开发者、基础设施团队还是协议设计师，都在共同努力加快这个过程。

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

委托调用和代理合约

外部调用和委托调用：

虽然 delegatecall 与 call 类似，但它不是在自己的背景中执行目标合约，而是在调用合约的当前状态下执行目标合约。这意味着目标合约所做的任何状态更改都会应用到调用合约的存储中。

为了实现可组合和可升级的结构，需要一种基本的知识，称为“代理合约”。

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

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

安全架构

Safe 是一种领先的模块化智能账户基础架构，旨在提供经过实战验证的安全性和灵活性，使开发人员能够创建多样化的应用程序和钱包。值得注意的是，许多团队正在构建在 Safe 之上或受其启发。Biconomy 通过在 Safe 上扩展原生 4337 和 1/1 多签名来推出其账户。Safe 已经部署了超过 164,000 个合约，并锁定了超过 307 亿的价值，毫无疑问，Safe 是该领域的首选。

Safe 的结构

1. Safe 账户合约：主代理合约（有状态）

Safe 账户是一个代理合约，因为它通过委托调用（delegatecall）一个单例合约。Safe 账户包含所有者、阈值和实现地址，这些都被设置为代理的变量，从而定义了其状态。

2. 单例合约：集成中心（无状态）

单例为 Safe 账户提供服务，并集成和定义了不同的集成，包括插件、Hook、函数处理器和签名验证器。

3. 模块合约：自定义逻辑和功能

模块非常强大。作为一种模块化类型，插件可以定义不同的功能，如支付流、恢复机制和会话密钥，并通过获取链外数据作为 Web2 和 Web3 之间的跨链桥。其他模块，如 Hook 作为安全保护，以及函数处理器响应任何指令。

当我们采用 Safe 时会发生什么

1. 可升级合约：

每当引入新的插件时，需要部署一个新的单例。用户保留了升级 Safe 到所需单例版本的自主权，以符合其偏好和要求。

2. 可组合和可重用的模块：

插件的模块化特性使开发人员能够独立地构建功能。然后，他们可以根据自己的用例自由选择和组合这些插件，促进高度可定制的方法。

ERC-2535 Diamond 代理

关于 ERC2535 和 Diamond 代理

ERC2535 标准化了 Diamond 代理，这是一种模块化的智能合约系统，可以在部署后进行升级/扩展，并且几乎没有大小限制。到目前为止，许多团队都受到了它的启发，比如 Zerodev 的 Kernel 和 Soul Wallet 的实验。

Diamond 结构是什么

1. Diamond 合约：主代理合约（有状态）Diamond 是一个代理合约，通过委托调用（delegatecall）从其实现中调用函数。

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

当我们采用 Diamond 时会发生什么

1. 可升级合约：Diamond 提供了一种系统化的方法来隔离不同的插件并将它们连接在一起，并通过 diamondCut 函数直接添加/替换/删除任何插件。随着时间的推移，可以向 Diamond 添加的插件数量没有限制。

2. 模块化和可重用的插件：一个已部署的插件可以被任意数量的 Diamond 使用，从而大大降低部署成本。

Safe 智能账户和 Diamond 方法之间的区别

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

然而，主要区别在于逻辑合约的处理。以下是更详细的说明：

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

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

3. 成本：Diamond 方法中固有的灵活性与增加的安全性问题相伴而生。这增加了成本因素，需要在每次添加新插件时进行全面审计。关键是确保这些插件不会干扰彼此的功能，这对于努力维护强大安全标准的中小型企业来说是一个挑战。

“Safe 智能账户方法”和“Diamond 方法”是涉及代理和模块的不同结构的示例。如何平衡灵活性和安全性至关重要，这两种方法在未来有可能相互补充。

模块顺序：验证器、执行器和 Hook

让我们通过介绍 Alchemy 团队提出的标准 ERC6900 来扩展我们的讨论，该标准受到 Diamond 的启发，专门针对 ERC-4337 进行了调整。它通过提供常见接口并协调插件和钱包开发人员之间的工作，解决了智能账户中的模块化挑战。

当涉及到 AA 的交易过程时，有三个主要过程：验证、执行和 Hook。正如我们之前讨论的那样，通过使用代理账户调用模块，可以管理这些步骤。虽然不同的项目可能使用不同的名称，但把握相似的基本逻辑是很重要的。

• 验证：确保调用者对账户的真实性和权限。

• 执行：执行账户允许的任何自定义逻辑。

• Hook：作为在另一个函数之前或之后运行的模块。它可以修改状态或导致整个调用被撤销。

根据不同的逻辑将模块进行分离是至关重要的。标准化的方法应该规定智能合约账户的验证、执行和 Hook 函数应该如何编写。无论是 Safe 还是 ERC6900，标准化有助于减少针对特定实现或生态系统的独特开发工作的需求，并防止供应商锁定。

模块的发现和安全性

一个正在蓬勃发展的解决方案涉及创建一个允许用户发现可验证模块的地方，我们可以称之为“注册表”。这个注册表类似于一个“应用商店”，旨在促进一个简化但繁荣的模块化市场。

Safe{Core}协议

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

• 账户：在 Safe{Core}协议中，账户的概念是灵活的，不受特定实现的限制。这使得各种账户服务提供商可以参与其中。

• 管理器：管理器在账户、注册表和模块之间充当协调者。它还负责安全性，作为权限层。

• 注册表：注册表定义安全属性，并强制执行诸如 ERC6900 之类的模块标准，旨在为发现和安全性创造一个开放的“应用商店”环境。

• 模块：模块处理功能，并以各种初始类型提供，包括插件、Hook、签名验证器和函数处理程序。只要满足既定的标准，开发人员就可以为其做出贡献。

Rhinestone Design

这个过程的展开如下：

• 创建模式定义：模式作为预定义的数据结构，用于证明。企业可以根据其特定的用例自定义模式。

• 基于模式创建模块：智能合约被注册为模块，获取字节码并选择模式 ID。这些数据随后存储在注册表中。

• 获取模块的证明：证明者/审计员可以根据模式为模块提供证明。这些证明可以包括唯一标识符（UID）和其他证明的引用，用于链接。它们可以在链上传播，并验证目标链上是否满足特定的阈值。

• 使用解析器实现复杂逻辑：解析器是可选设置在模式中的。它们可以在模块创建、证明建立和撤销过程中被调用。这些解析器允许开发人员在保持证明结构的同时，融入复杂多样的逻辑。

• 用户友好的查询访问：查询提供了一种用户从前端访问安全信息的方式。在这里可以找到 EIP。

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

• 证明者：可信任的实体，如 Safe，可以作为内部模块的证明者与 Rhinestone 合作。同时，独立的证明者也可以加入进来。

• 模块开发者：随着一个开放市场的形成，模块开发者有可能通过注册表将他们的工作商业化。

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

“模块注册表”的概念为插件和模块开发者提供了盈利的机会。它还可能为“模块市场”铺平道路。其中一些方面可能由 Safe 团队监督，而其他方面可能表现为去中心化市场，邀请所有人进行贡献并提供透明的审计记录。通过采用这种方式，我们可以避免供应商锁定，并通过提供更好的用户体验吸引更广泛的受众来支持 EVM 的扩展。

虽然这些方法保证了单个模块的安全性，但智能合约账户的整体安全性并非绝对可靠。结合合法模块和证明它们没有存储冲突可能是一个挑战，强调了钱包或 AA 基础设施在解决此类问题中的重要性。

总结

通过利用模块化的智能合约账户堆栈，钱包提供商和 dApp 可以摆脱技术维护的复杂性。与此同时，外部模块开发者有机会提供针对个体需求量身定制的专业服务。然而，需要解决的挑战包括在灵活性和安全性之间取得平衡，推动模块化标准的进步，并实施标准化的接口，使用户能够轻松升级和修改他们的智能账户。

然而，模块化智能合约账户（SCA）只是采用的拼图中的一部分。要充分实现 SCA 的潜力，还需要来自第二层解决方案的协议层支持，以及强大的捆绑器基础设施和点对点内存池、更具成本效益和可行性的 SCA 签名机制、跨链 SCA 同步和管理，以及开发用户友好的界面。

我们设想一个广泛参与的未来，引发了一些有趣的问题：一旦 SCA 订单流程变得足够有利可图，传统的矿工可提取价值（MEV）机制将如何进入领域，构建捆绑器并捕获价值？当基础设施成熟时，如何让账户抽象（AA）成为“基于意图”的交易的基础层？请持续关注，这个领域正在不断发展变化。