探索账号抽象2023——第二部分

探索账户抽象 2023 — 第2部分

1. ERC-4337 不是终极解决方案

1.1. ERC-4337 的当前问题

ERC-4337 在无需更改协议的情况下成功实现了账户抽象的初步目标。然而，正如第一部分所讨论的，账户抽象和 ERC-4337 的采用仍处于初步阶段。一个原因是 ERC-4337 还不是一个完善的解决方案。目前，ERC-4337 存在以下三个主要缺点。

1.1.1. 用户操作成本高 用户操作（UserOps）的成本，比起 ERC-4337 中的常规交易高出 2 到 3 倍。这是因为对签名和随机数等验证过程的成本被添加了，这是因为它们是在独立的内存池中执行的，而最初在协议层级中进行处理。实际上，用户操作的处理需要一个非常复杂的验证过程。

用户操作验证过程，来源：ERC-4337 通过替代内存池的账户抽象

因此，在以太坊内，由于上述成本问题，ERC-4337 几乎没有被使用，自 ERC-4337 引入以来，以太坊网络上的用户操作总数一直保持在 20,000 左右。

与此同时，使用以太坊作为 Layer 1 的乐观 Rollup中的交易成本结构问题也很显著。通常，乐观 Rollup中的交易成本由以下两个部分组成：

• L2 执行成本： 在 L2 上执行交易和记录状态变化的收费。在 ZK Rollup的情况下，这还包括生成 ZK 证明的成本。
• L1 安全成本： 以 calldata 的形式将交易提交到 L1（以太坊）的成本。这个成本与 calldata 的长度成正比。

ERC-4337 的用户操作在第二种成本上产生了显著的费用。这是因为用户操作的 calldata 相较于常规交易要长得多。

交易 vs 用户操作 Calldata，来源：Jiffyscan

如果假设一个传统交易的调用路径为[用户 → 合约 A]，在 ERC-4337 中，它涉及更复杂的调用路径[聚合器 → 入口合约 → 用户的合约账户 → 合约 A]。此外，如果要使用支付方，还必须在交易中包含这方面的信息。换句话说，必须表示这些额外的信息，使得交易不可避免地变长。通过检查 Arbitrum 中用户操作的平均Gas成本，可以发现所产生的成本高于预期。

通过用户操作在 Arbitrum 发送 ETH 的平均成本，来源：BundleBear

在 Biconomy 部署的合约账户中，即便是像发送 ETH 这样非常简单的操作，用户操作在 Arbitrum 中的成本有时也会超过 1 美元。此外，当用户操作与外部合约如 ERC20 交互时，成本会变得更加高昂。

通过用户操作在 Arbitrum 中发送 ERC20 代币的平均成本，来源：BundleBear

在 ERC20 代币转账的情况下，截至去年 12 月，Biconomy 和 ZeroDev 的账户每次用户操作的平均成本都超过了 1 美元。当然，如果 Dencun 更新应用了 EIP-4844，绝对的Gas费用将会降低，但用户操作仍将消耗相当于常规交易平均Gas费用的 2 到 3 倍的成本。

如果用户操作的成本很高，这不仅成为合约账户用户的负担，也成为通过支付方提供Gas费用赞助的应用的负担。换句话说，无论是在 L1 还是 L2，均需要一种能够降低用户操作成本的替代方案。

1.1.2. MEV 中心化与审查 以太坊验证者有权在块内调整交易顺序，这使他们能够通过套利、抢跑交易和三明治攻击获利，这些统称为可最大提取价值（Maximal Extractable Value，MEV）。如果交易顺序调整的权力集中在特定的验证者中，可能导致这些验证者垄断 MEV 市场，以及出现交易审查等问题。

因此，以太坊试图通过诸如 PBS（提议者-构建者分离）和 crList（审查抵抗列表）等解决方案来确保 MEV 市场的去中心化和抵抗审查。然而，由于 ERC-4337 中使用的内存池存在于链外并经历了单独的验证，因此在协议内实施 PBS 和 crList 将不会有效。这可能导致聚合器垄断 MEV 利润或者用户的用户操作被审查。当然，可以在这个内存池中为 ERC-4337 实施独立的 PBS 和 crList，但这将引入额外的复杂性，这并不可取。

此外，当前的聚合器没有采用无许可的结构，这种情况显得更加不理想。迄今为止，没有任何聚合器提供商实施了允许任何人参与打包过程的公共内存池。换句话说，当前的 ERC-4337 生态系统依赖于中心化的聚合器，用户的用户操作在信任单个聚合器不会恶意提取 MEV 或审查他们的前提下提交。

1.1.3. 向合约账户迁移率低

尽管兼容 ERC-4337 的更多钱包正在发布，并且在 ERC-4337 之间的 dApp 生态系统中进行各种实验，但使用该系统的用户保留率并不是很好。

ERC-4337 兼容钱包的用户保留率，来源：BundleBear

从上述数据可以看出，创建钱包一个月后（4 周），返回该钱包使用的用户比例不超过 1%。

这个问题可以归因于两个主要因素：

1）缺乏杀手应用

如果我们将原因归结于应用，可能有几个原因：

• 利用账户抽象的应用对用户没有显著吸引力。
• 应用只在短期事件中使用了账户抽象。

实际上，像 ZTX 这样的应用仅在活动期间使用 ERC-4337 钱包，表明每个钱包的用户操作平均数量接近 1。

2）合约账户被困在应用内部 使用账户抽象的应用共有一个特点，即它们只支持一种钱包提供商。因此，用户最终为每个应用创建不同的合约钱包，而不是在多个应用之间使用同一个合约钱包。因此，用户在另一个环境中不断使用在一个应用中创建的钱包变得困难。

合约钱包缺乏标准可以被认定为这个问题的一个原因。如果 Biconomy 和 ZeroDev 的账户是兼容的，应用将很容易整合两种钱包的 SDK。不幸的是，现有的钱包提供商并不兼容。因此，合约钱包需要一个标准。

2. ERC-4337 的改进

目前正在 ERC-4337 内部推进解决这些问题的行动，可以分为三个主要类别：

2.1. 聚合器标准和公共内存池

目前，Pimlico、Biconomy 和 Alchemy 等生产级聚合器各自使用自己的 UserOp 内存池。这意味着所有用户操作都由一个中心化的单一聚合器处理，所有具有合约账户的用户必须信任聚合器在发送交易请求时不采取恶意行为。

为了解决这个问题，由 ERC-4337 作者组成的 eth-infinitism 团队正在提议聚合器标准，并促进公共内存池的形成。聚合器标准的必要性在于，如果聚合器规范不同，它们无法共享同一内存池。这方面的标准可以在eth-infinitism 的 GitHub 上找到，由 ERC-4337 的作者组成。

多个聚合器提供商也在为公共内存池合作。目前，Candide 创建的 Voltaire、Etherspot 的 Skandha 和 Vid Kersid 的 Silius 在 Sepolia 测试网上形成了公共内存池以测试该公共内存池。

在 Sepolia 中存在的共享内存池，来源：Partha 的 Twitter

此外，当前在主网上运行的 Alchemy 和 Stackup 也计划实现 P2P 接口。一旦 P2P 接口实施，聚合器之间将能够进行通信，并共享同一公共内存池，从而实现去中心化的用户操作打包。如果测试网的实验确认稳定性和效率，聚合器的公共内存池将很快不仅在以太坊，而且在 Polygon 和 Arbitrum 等主网上创建。这将有助于防止聚合器的中心化，并增强 ERC-4337 架构内的抵制审查能力。

2.2. 通过 BLS 钱包降低成本

使用 BLS 钱包，可以将来自不同实体的签名聚合成一个单一签名，有可能显著降低用户操作的成本。然而，目前在生产级的钱包中，没有任何使用 BLS 签名机制的钱包。唯一的实验是以太坊基金会 PSE（隐私与扩展探索）团队创建的一个 BLS 钱包演示。

WAX 钱包，来源：WAX GitHub

BLS 签名聚合是一个非常有意义的解决方案，因为它可以降低用户支付的Gas费用。然而，由于 BLS 签名本身的性质，实际引入这项技术并不容易。与传统的 ECDSA 签名相比，BLS 在验证时需要更多的资源。然而，BLS 可以高效，因为它允许同时验证多个签名。换句话说，在没有多个签名的情况下，BLS 的成本要求高于传统的签名系统。

为了在 ERC-4337 中实现 BLS 的高效性，一个捆绑必须包含大约 10 个或更多的用户操作。然而，鉴于账户抽象的引入仍处于初级阶段，聚合器在一个捆绑中收集多于 10 个的用户操作很不容易，因此 BLS 的引入面临挑战。然而，随着未来用户操作数量的增加，BLS 钱包的商业化有潜力。

2.3. 在汇总中降低成本：Calldata 压缩

如问题 1 中所提到的，在乐观 Rollup中，将交易的 calldata 上传到 L1 的成本会导致用户操作Gas费用的显著消耗。为了解决这个问题，正在积极研究的一种方法是压缩用户操作的 calldata。最近，Pimlico 和 Daimo 有过合作，发布了解决方案。

用户操作的 calldata 压缩，来源：Pimlico Twitter

聚合器获取用户的用户操作，并通过入口点合约生成交易。由于此调用需要大量数据，因此用户操作交易的 calldata 很长且成本高。然而，如果有一种 Inflate 合约接收压缩的 calldata，在调用的前端将其转换为正确的 calldata 格式，然后将调用发送给入口点呢？

用户操作捆绑压缩，来源：Daimo 博客

通过以这种结构发送用户操作，可以通过使用压缩形式的 calldata 显著降低Gas费用。尽管解压可能会增加一点Gas费用，但由于 calldata 压缩导致的Gas费用降低要大得多，从而大幅减少整体Gas费用。

通过 calldata 压缩和 BLS 签名聚合变化的Gas费用，来源：WAX 中的 4337 压缩

上述数据显示，是 PSE 团队进行的研究结果的一部分，显示了通过 BLS 签名聚合和 calldata 压缩可以节省多少Gas费用。根据研究，用户操作的Gas费用可以减少约 82% 至高达 90%，这大约是 EOA 所产生的Gas费用的一半多。

如果钱包提供商未来支持这样的 calldata 压缩和 BLS 签名聚合，像 Arbitrum 或 Optimism 这样的乐观 Rollup中使用 ERC-4337 将变得非常实惠。

然而，从上面的图片中可以看出，用户操作的 calldata 压缩导致 Layer 1 成本的增加。为了降低 Layer 1 的成本，必须采取如下面将介绍的原生账户抽象等解决方案。

3. 在汇总中实施原生账户抽象：RIP-7560

3.1. 为什么要原生账户抽象？

解决 ERC-4337 的成本、复杂性和账户留存问题的一个方法是引入“原生账户抽象”。这意味着在协议内部支持账户抽象，正如 EIP-2938 和 EIP-3074 所提出的。将账户抽象纳入协议可以提供以下优势：

Gas费用减少

• 用户发送的不是交易，而是用户操作（UserOps），聚合器验证后再作为交易发送。
• 作为回报，聚合器向用户收取费用。发送费用给聚合器或修改随机数的过程消耗大量Gas。
• 目前在 ERC-4337 中发送用户操作的过程如上图和描述所示复杂。如果集成到协议中，则能够降低由于传输用户操作而产生的Gas费用。

节省开发资源并提高协议稳定性

• 新应用于协议的 PBS 和 crList 解決方案可以应用于用户操作。
• 这减少了在 ERC-4337 应用的解决方案所需的研发资源，并有助于协议稳定性的提高。

虽然像 EIP-3074 这样的提议由于需要复杂的协议变更先前被拒绝，而这些话题的讨论现在在更明显地进行。那么，为什么一开始没有在协议中实施账户抽象，而采取 ERC-4337 等链外机制呢？

自 2022 年以来，“实施原生账户抽象”已成为以太坊的路线图之一。然而，这一过程复杂且需要大量工程资源。当时，以太坊需要首先实现被认为更重要的功能，如 protodanksharding、PBS、Verkle trie 等，因此原生账户抽象相对较低的优先级，而目前仍然如此。

ERC-4337 除此之外作为一项中间方案出现。在 ERC-4337 发布大约一年后，由于其系统的稳定性得到了初步验证，关于在协议内进行原生账户抽象的讨论开始了。在这次讨论中，最引人瞩目的发展是“RIP-7560”。

3.2. 什么是 RIP

在深入了解 RIP-7560 之前，让我们先了解什么是 RIP。RIP 代表 Rollup Improvement Proposal，指的是用于讨论那些以以太坊为 Layer 1（L1）的各类汇总之间的兼容性或合作的提案。这是由以太坊基金会于去年 10 月发起的 RollCall 中开始讨论的。

汇总各自尝试以他们自己的方式利用以太坊的安全性，并且通常提供不同的工具和功能。例如，Starknet 和 zkSync 支持原生账户抽象，而其他汇总则不支持。

这对 dApp 开发者带来了问题，他们必须根据链的不同实现不同的解决方案。例如，如果一个 dApp 希望集成 L1-L2 桥，它必须根据每个汇总的不同桥接接口来编写代码。

为了解决这个问题，汇总之间的合作是必要的。RIP 旨在成为这样的讨论的中立论坛。虽然汇总之间的差异是不可避免的，但目标是将不兼容性最小化。此外，RIP 不是一个强制性的过程，这意味着每个在 RIP 中提出的话题不必被每个汇总实现。

3.3. RIP-7560：用于 L2 的原生账户抽象

RIP-7560 是一个 RIP，提议了一种用于在汇总中实现原生账户抽象的新交易类型。尽管在 zkSync 和 Starknet 中已经实施了原生账户抽象，但它与 ERC-4337 不兼容。RIP-7560 的目标是在保持与 ERC-4337 兼容的同时，在协议中实现账户抽象，创造一个基于 ERC-4337 的钱包提供商能够顺利集成的环境。

RIP-7560 引入了一种新的交易类型 “AA_TX_TYPE” 用于账户抽象交易。变化包括：

1) 独立的随机数管理 在传统合约中，随机数仅在使用 CREATE 操作码时增加，即，从该合约部署另一个合约时。然而，随着 RIP-7560 的应用，合约账户发送 AA_TX_TYPE 交易时，随机数必须在每个交易中递增。否则，可能导致签名重放攻击和被盗窃账户资金的风险。

保持合约账户中的唯一随机数的一种方法是使用外部拥有账户（EOAs）中的随机数系统。由于每个 EOA 在每次交易时都会将其随机数增加 1，将此系统应用于合约账户可以区分每个交易并检查签名的重用，从而防止像签名重放攻击这样的风险。

然而，这一解决方案有几个边缘情况。如果一个账户由多个用户操作，则重叠的随机数可能导致混淆。因此，RIP-7560 引入了一个 NonceManager 合约来处理来自合约账户的交易的独立随机数。这意味着常规 EOA 和合约账户的随机数序列并不会直接相互跟随。

2) 新的费用系统 传统交易设定为消耗 21,000 Gas。然而，通过引入 AA_TX_TYPE，验证机制可以根据应用意愿进行设计，并且还必须考虑与支付方的交互。因此，RIP-7560 引入新的费用（如 paymasterGasLimit），而交易费用的计算将依据以下逻辑。

此外，像 _ethsendTransaction 这样的 RPC 方法被修改为接受 AA_TX_TYPE。

3) 独立的内存池 由于 AA_TX_TYPE 交易具有不同的验证和执行逻辑，因此它们在一个单独的内存池中处理。然而，协议级的区块构建者将批处理这些，从而使它们可以与常规交易一起纳入区块。

4) 验证与执行的分离 在传统的 ERC-4337 中，由区块构建者执行聚合器的角色。区块构建者会将 AA_TX_TYPE 交易批的验证与执行分开，在一次交易中纳入区块，类似于在 ERC-4337 中多个用户操作被纳入单次交易。

带有分离的验证和执行的 AA_TX_TYPE 交易，来源：RIP-7560 官方文档

5) 构建者费用 这个过程需要区块构建者消耗比处理传统交易更高的计算资源。如果由于这个原因，区块构建者拒绝处理 AA_TX_TYPE 交易，该怎么办？

为了防止这种情况，AA_TX_TYPE 的发送方可以在其交易中附加构建者费用，以补偿这一点，同时确保其交易在区块中优先处理。这个概念跟 EIP-1559 中的 priorityFee 有点相似。

RIP-7560 仍然处于反馈阶段，尚未正式注册为 RIP。此外，还需要大约两个后续 RIP，关于 AA_TX_TYPE 交易在内存池中的验证将如何进行以及 ERC-4337 支持的签名聚合将如何实施。

尽管在汇总中原生账户抽象的讨论仍处于早期阶段，但由于其可能为用户提供的巨大价值，备受关注。值得注意的是，由 Coinbase 建造的 Base 链已经提议将合约钱包作为其 2024 路线图的一部分。

Base 在其路线图中宣布支持合约账户，来源：Base Twitter

3.4. ERC-4337 不是唯一的答案：EIP-3074

随着 ERC-4337 缺陷的显现及关于将账户抽象引入协议本身的讨论日益具体，之前提出的协议级账户抽象方法正在被重新审视。特别是，关于在多条链中融入 EIP-3074 的讨论正在进行。

EIP-3074 提议允许外部拥有账户（EOAs），如 MetaMask 使用的那种，委托某些权限给合约。为支持这一点，EIP-3074 引入了两个新的操作码：AUTH 和 AUTHCALL。用户流下的步骤如下所示：

EIP-3074 的调用流程，来源：Nethermind 博客

首先，用户用私钥签名包含他们希望委托钱包的合约的消息，并将其发送给中继者。中继者将该签名转发给称为 Invoker 的合约，后者使用 AUTH 操作码验证签名。一旦该过程完成，Invoker 合约便获得对用户钱包的权限，可以代表用户发送交易。当 Invoker 合约使用 AUTHCALL 操作码发送交易时，交易的发送者地址被设置为授予权限的用户钱包地址。

EIP-3074 的主要优点是用户在使用 AUTHCALL 发送交易时无需支付Gas费用，因为这些交易的Gas费用由中继者承担。这类似于 ERC-4337 中默认拥有的支付方。

EIP-3074 可以涵盖大多数由 ERC-4337 支持的特性。根据 Invoker 合约的结构，它可以实施各种功能，如交易批处理、会话密钥、社交恢复等。此外，EIP-3074 允许现有用户享受合约账户所能提供的好处，而无意识迁移自 EOA 到合约账户，因为它要求较少的Gas，由于架构相对简单，相比 ERC-4337。

然而，EIP-3074 也存在一些缺点。它需要对协议的变更（添加新的操作码），因此必须为了多链支持在多个链上进行应用。它仍然依赖于 EOAs，这意味着用户必须谨慎管理其私钥，并且仅支持 ECDSA 签名。尽管 EIP-5003 已提出，以实现在实施 EIP-3074 的钱包迁移到合约账户，但关于迁移过程中安全的讨论仍需进行。

尽管如此，EIP-3074 提供一种强大的特性，使 EOAs 能够像合约钱包一样工作。因此，关于将账户抽象引入协议的诸如 RIP-7560 的提案之外，EIP-3074 也在持续深入讨论。有关该话题的更多细节将稍后提供。

4. 账户标准化：ERC-6900 和 ERC-7579

为了解决之前讨论的合约账户留存率低的问题，已经对合约账户本身的标准化进行了大量讨论。如果账户得以标准化，用户将能够在不同的应用间继续使用同一钱包。目前，在这方面已提出两种 ERC。

4.1. ERC-6900：模块化智能合约账户和插件

ERC-6900 是 Alchemy 提出的合约账户标准。该 ERC 的一个关键特性在于，它允许应用在账户中自由安装和卸载，类似于智能手机。在 ERC-6900 中，安装在账户上的应用被称为插件（Plugins）。

插件的典型示例可能是游戏中的合约账户所必需的会话密钥功能，它会赋予账户一定的权限。与传统合约账户在部署时就内置该功能不同，ERC-6900 采取了一种方法，创建并安装执行会话密钥功能的插件。

这种方法允许用户自由地为他们的账户增加或删除功能，从而增强了账户的可重用性。因此，这也使得应用更容易集成合约账户。

例如，考虑一个需要会话密钥的链上游戏。在目前的场景中，如果该游戏希望集成合约钱包，它必须选择单一的类型钱包，因为会话密钥的实现因钱包而异，从而使得通过不同类型的钱包一致地发送交易变得困难。虽然可以开发逻辑以相应地与每种类型的会话密钥交互，但这为应用增加了复杂性，而这一点并不可取。

如果像 ERC-6900 这样的合约钱包和模块（插件）的标准化已实现，将能够解决这些问题。在这种情况下，应用能够开发其希望使用的会话密钥插件，允许用户将其安装到他们的钱包中。

ERC-6900 的强点和弱点在于其彻底的安全措施。查看 ERC-6900 的参考实施表明，它在一定程度上旨在应对恶意插件，通过多种安全措施进行保障。然而，彻底的安全检查会增加用户在与传统钱包相比需要支付的Gas费用，并增加合约结构的复杂性，使得开发变得更加困难。

4.2. ERC-7579：最小模块化智能账户

ERC-7579 也是一个为合约钱包标准化而提出的 ERC，由 Rhinestone、ZeroDev、Biconomy 和 OKX 的合作开发，采用一种根据用户需求安装和卸载模块的机制。虽然在某些方面与 ERC-6900 类似，但最大的区别在于安全性和成本。

正如其名称所示，ERC-7579 提出了合约账户的最小标准，专注于兼容性和互操作性，而不妨碍每个钱包的自治。因此，ERC-7579 提供了以较小限制易于开发的优势，从而实现多样化的实现。事实上，尽管处于演示阶段，ERC-7579 的实施表明，在“原生转账”和“ERC20 转账”中，其Gas费用差异仅比其他经过优化的生产级钱包多出几千。

ERC-7579 与其他钱包之间的Gas费用比较，来源：aa-benchmark GitHub

然而，与 ERC-6900 相比，ERC-7579 可能允许从安全角度看存在风险的元素。模块化架构中最危险的方面是恶意模块被安装进账户。因此，ERC-6900 实施了各种方法来确保账户的安全性，例如创建限制插件（模块）能够访问的外部合约的功能。另一方面，ERC-7579 并不检查这些问题。尽管 其参考实施 建议引入 ERC-7484，其涉及一个模块注册表，预设开发者和审计师检查模块是否恶意或存在安全缺陷，依赖于预设委员会并不是最终解决方案。

总之，ERC-6900 和 ERC-7579 都提出了模块化合约账户的标准。个人认为这两种标准将会共存。在 security 和资金紧俏的地方，例如 DeFi 或支付，遵循 ERC-6900 标准的钱包可能更加合适，而在需要广泛互动的领域，例如游戏或社交，遵循 ERC-7579 标准的钱包则更加合适。

这些标准经过广泛开发和反馈，利用这些标准的合约账户要么即将上市，要么已经进入市场。最近，ZeroDev 发布了与 ERC-7579 兼容的钱包 SDK，允许用户和应用开发者开发符合 ERC-7579 标准的模块或在主网上使用该钱包。此外，ERC-6900 目前正接受社区反馈，并预计会迅速进行审计并推出生产级应用。随着这些标准的商业化，预计用户将能够在多个应用中使用单一合约账户，而不是为每个应用使用不同的钱包。

5. 账户抽象 + 意图：ERC-7521

5.1. 意图的定义及其问题

目前，在以太坊中发送交易时，用户必须指定要发送到何处、发送多少 ETH、使用多少Gas等。这是个很复杂的任务，尤其是对于像 DEX 上的代币交换等交易，考虑到 MEV 等因素，需要准确设置气体和交换金额。

意图的概念应运而生，旨在消除这种复杂性，改善用户体验。应用将意图应用于 Web3，允许用户无需准确指定交易的发送目标和发送的代币数量；相反，它们解释用户的“意图”，并代表用户构建交易。实际上，意图作为用户对交易执行施加的一系列约束，表达例如希望在交换时获得的最小代币数量的期待。应用接收意图，并构建符合这些条件的交易，这一任务由名为求解者（Solver）的主体执行。

自去年以来，意图已经成为区块链生态系统中受到关注的概念。借助意图，可以创建各种用例，比如限价单，表达“在明天将 1 ETH 转换为 USDC，但我希望至少能获得 2000 USDC”。目前，CoWSwap、UniswapX、Flashbot、Anoma 等协议正在开发利用意图的协议。

然而，随着各种协议开发各自的意图标准，可能会出现兼容性问题，可能导致用户在不同意图服务之间的碎片化。使用意图的机制中最重要的一个方面是求解者的去中心化，因此这种情况可能会造成问题。求解者作为代表用户构建交易的强大实体，在中心化时可造成显著影响。考虑如下场景：

想象一下，一个 DEX 实现了意图机制，但只有一个求解者。用户通过意图提交了一项交换请求，表述“我想将 1 ETH 交换为至少 2,300 USDC”。如果只有一个求解者，即使当前 ETH 的价格为 2,400 USDC，求解者也可能只给用户提供 2,300 USDC，并将 100 美元的差价据为己有。

因此，使用意图的应用程序总是采取分散求解者之间的拍卖结构。这促使求解者为用户构建最有利的交易，防止中心化求解者垄断利润。

目前各协议定义的意图标准之间存在兼容性问题。如果协议内的求解者各自操作独立的意图内存池，这比在一个统一的单一内存池中操作会导致更大的中心化。因此，迫切需要意图的标准。

5.2. ERC-7521 和 Essential

成立于 2023 年 5 月，Essential 旨在为意图提供基础设施，并提出一个基于 ERC-4337 的意图标准。虽然 ERC-4337 和账户抽象机制并不是使用意图的机制，但它们提供了有利于与意图结合的条件。

意图中使用的求解者与 ERC-4337 中的聚合器执行非常相似的任务。两者都将包含用户签名的数据显示（意图/用户操作）从链下转化为交易形式。因此，如果求解者利用现存的 ERC-4337 基础设施，则意味着可以将意图的效果应用于当前的合约账户，而无需进行重大更改。

在意图架构中，验证用户是否正确签署该意图及意图的条件是否得到准确满足时（验证），以及如何将其构成交易（执行）是至关重要的。受 ERC-4337 的验证和执行过程启发，ERC-7521 提议通过入口合约处理意图。机制详细如下：

ERC-7521 的架构，来源：Essential 博客

当用户将其意图和签名发送至 UserIntent 内存池时，求解者基于此构建解决方案（交易）。

在 ERC-4337 入口合约中处理的全集意图，来源：Essential 博客

然后，求解者调用入口合约中的 handleIntents 函数。该函数验证用户在意图中包含的签名，并检查由求解者构建的解决方案是否符合用户所述意图的条件。接着，它执行解决方案以进行用户请求的操作。

这里一个重要的方面是每个意图的形式。由于意图可以根据其用途采用不同的形式，将其固定在合约中会大大减少灵活性。ERC-7521 通过允许注册意图标准来解决这个问题。

ERC-7521 的意图注册机制，来源：Essential 博客

通过这种方式，ERC-7521 Facilitate 为合同账户轻松使用意图，同时确立意图处理的标准，防止求解者网络的碎片化。

然而，也存在一些缺点。首先，ERC-7521 需要对 ERC-4337 规范的更改。它需要将意图验证和执行的功能添加至入口点，并注册意图标准，需要社区及开发者对此更新达成共识。此外，现有的 ERC-4337 兼容钱包必须升级以支持该意图标准。因此，实施该标准需与各方利益相关者及社区进行讨论，而考虑到以太坊社区的性质，这可能是一个漫长的过程。

6. 结论与展望

通过账户抽象的第一和第二部分，我们探讨了过去一年账户抽象生态系统的发展和未来的方向。基于此，我们推测账户抽象生态系统未来可能的发展及可能面临的技术进步和障碍。

6.1. 利用账户抽象出现的杀手级应用即使账户抽象或 ERC-4337 从技术上有所进展，但最终，应用程序对这种技术的采用至关重要。到目前为止，采用账户抽象的应用要么缺乏吸引力，要么只是为了事件而使用账户抽象。然而，展望未来，预计 ERC-4337 本身的可用性提升，例如通过 calldata 压缩降低成本，将使更多应用采用它。

个人而言，我相信游戏行业可以在 ERC-4337 的应用中实现最大的协同效果。在游戏中有交易签名弹窗的用户体验是不可取的，可以通过 ERC-4337 支持的功能如会话密钥来解决。然而，迄今为止，Web3 游戏领域没有任何应用广泛利用账户抽象来生成多种 UserOperations。虽然基于 Arbitrum Orbit 的游戏应用链 Xai 收到了很多关注，但游戏能否成功并持续生成交易还有待观察。

我希望在 2024 年，应用包括游戏在内的各种采用账户抽象的应用能够出现，为用户提供更高的 UX。

6.2. 合约账户的重用

如果实现了以 ERC-6900 和 ERC-7579 为代表的账户标准化，将创建一个环境，用户可以通过单个合约账户利用多个应用，而不是为每个应用使用不同的合约账户。

最近，ZeroDev 宣布了一种基于 ERC-7579 账户的模块化账户架构。这标志着未来账户将保持兼容性并以模块化形式轻松重用的开始，使用户可以继续使用单个合约账户。

为了加速这一进程，需要 SDK 轻松将各种合约账户集成到应用中。对于传统的 EOA 钱包，已有像 RainbowKit 这样的工具，允许 dApp 开发者轻松将多种钱包，如 MetaMask 和 Coinbase Wallet，集成到他们的应用中。

RainbowKit SDK，来源: Rainbow Twitter

然而，合约账户的 SDK 几乎不存在。目前，由 Pimlico 创建的 permissionless.js 是为数不多的产品之一，旨在为合约账户提供类似 RainbowKit 的功能。

Permissionless 初学者套件，来源: Pimlico Twitter

Permissionless.js 目前支持 ZeroDev、Safe 以及 ERC-4337 参考实现中的 SimpleAccount，方便将这些钱包轻松集成到应用中。如果这个 SDK 能够集成更多钱包，可以预期应用对合约账户的采用将变得更加容易。

6.3. 协议内的原生账户抽象

Vitalik 在今年初宣布的以太坊路线图 提供了以太坊基金会对账户抽象的看法，尤其是在路线图的“The Splurge”部分中突显出来。

The Splurge: 以太坊路线图，来源: Vitalik Buterin Twitter

目前，我们已进入 ERC-4337 的推出阶段，在自愿 EOA 转换（用户将其钱包迁移到合约账户）后，计划实施原生账户抽象。

考虑到这一路线图，最近提出的 RIP-7560 可以被视为旨在促进自愿 EOA 转换。与以太坊协议更新漫长讨论的特点不同，rollup 中的更新通常由中心化基金会更迅速地执行。这种方法的目标是首先在 EVM 兼容的 rollup 中快速提供原生账户抽象，并鼓励大量用户迁移至合约账户。

通过 RIP-7560 在 rollup 内部引入账户抽象，预计可以因节省 gas 而享受各种功能。在 2024 年，预计将有更多 rollup 提供与 RIP-7560 一致的原生账户抽象。

6.4. EIP-3074 的进展

EIP-3074 是一个强大的 EIP，将合约账户的功能添加到 EOA 中。尽管其缺点是使用户依赖于 EOA，但在过去几个月里对实施 EIP-3074 的支持不断增长。Polygon 在去年九月的论坛上通过 PIP-22 提出了将 EIP-3074 引入协议，且在讨论 Dencun 后即将进行的即将到来的布拉格更新的 以太坊核心开发会议 中，围绕 EIP-3074 的讨论异常广泛。

尽管目前没有任何链或服务提供商支持 EIP-3074，但随着以太坊或 EVM 兼容链未来开始支持它，预计将形成一个新的生态系统。

此外，由于 EIP-3074 和 ERC-4337 的方法并不重叠，使用两者的解决方案可能会出现。一个典型例子是将 EIP-3074 的 Invoker 函数制作成 ERC-4337 账户。通过将 Invoker 合约视为传统的 ERC-4337 账户并向其发送 AUTH 签名，可以在非常低的成本下利用 ERC-4337 的功能。

在 2024 年，希望能够涌现出多个支持 EIP-3074 的链，并开发利用 EIP-3074 的有趣用例和应用程序，例如上述例子。

6.5. 账户抽象与意图结合的早期阶段

账户抽象和意图都是旨在改善区块链不便 UX 的技术，最近提出的 ERC-7521 创建了一个可以在 ERC-4337 内轻松支持意图的标准。这两种技术的结合可能会导致提供非常高水平用户体验的应用出现。

然而，关于这种结合的讨论仍处于非常早期的阶段。目前，意图仅在像 CowSwap 和 UniswapX 等平台的“交换”中应用，尚无许多用例。未来，需要开发更多可以更普遍应用意图的环境，如 Anoma 和 SUAVE，并且需要展开更多关于如何将 ERC-7521 应用于当前 ERC-4337 架构的讨论。

参考文献

• 使用智能账户的费用是多少？
• BundleBear 仪表盘
• 捆绑压缩 | Daimo 博客
• WAX 中的 4337 压缩
• 以太坊能否妥协于将更多内容铭刻在协议中？
• 今天和明天的以太坊钱包 — EIP-3074 与 ERC-4337
• RIP-7560 GitHub
• ERC-6900 官方文档
• 揭秘 ERC-6900
• ERC-7579 官方文档
• 关于 EIP-3074 的说明
• 介绍 ERC-7521: 智能合约钱包的一般化意图
• 基于资产的意图标准：数字资产世界的意图标准
• EIP-3074 和 ERC-4337 可以一起使用吗？

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