EIP-4337：以太坊账户抽象

一键发币： SOL | BNB | ETH | BASE | Blast | ARB | OP | POLYGON | AVAX | FTM | OK

EIP-4337，也称为账户抽象，来自以太坊上将验证机制与交易包含机制分离的想法。 分离或抽象这两种机制可以在用户体验方面实现多项关键改进，包括：赞助 Gas 成本、以 ERC20 代币支付 Gas 费用，以及支持 ECDSA 之外的替代验证机制等。 在讨论用例之前，我们先讨论一下 EIP-4337 是如何诞生的。

以太坊在推出时决定有两种类型的账户：

• 外部拥有账户 (EOA)
• 智能合约账户（合约账户）

EOA 可以被视为普通用户帐户。 它们由私钥控制，重要的是可以通过创建和签署交易来发送消息。 这些是大多数钱包用来发起交易的账户类型。 如果你曾经使用过 Metamask 或 coinbase 钱包与 dApp 进行交互，那么你就使用过 EOA。

与 EOA 不同，合约账户本质上是反应性的。 合约账户代码可以读取和写入内部存储，甚至可以发送其他消息，但只能在收到初始消息时进行。 这是一个重要的区别，稍后我们会看到原因。 目前，请记住，EOA 本质上是唯一可以在不先接收消息的情况下实际创建和发送交易的账户类型。

除了这两种类型的账户架构之外，以太坊虚拟机的创建者还决定不在 EVM 本身中包含交易验证逻辑。 他们为什么做出这个决定？ 嗯，首先，人们担心如果一笔交易被证明无效，如何管理gas和计算成本。 例如，如果矿工必须先处理一笔交易，然后才能确定该交易是否有效，那么这种计算开销可能会成为拒绝服务向量。

1、以前的EIP

账户抽象的潜在好处在以太坊发展的早期就已经被看到了。 事实上，早在 2016 年就有提案提出了一种抽象形式。 以下时间表涵盖了 EIP-4337 的一些关键前身：

• EIP-86 和 EIP-208 (2016-2017) — EIP-86 建议创建转发合约。 在EIP86下，如果交易的签名为v=r=s=0，则该交易被认为是有效的，并且发送地址被设置为特定的入口点。 然后，交易可以从此入口点开始，然后调用合约帐户，该帐户将保存发送其他消息的逻辑。 问题是，这些 EIP 并没有保留交易哈希的唯一性，而且还创建了拒绝服务向量，其中单个交易可能会使内存池中的整个交易堆栈失效。
• 2017 年的非正式提案——2017 年出现了一些实现账户抽象的想法，其中一些开始类似于 EIP-4337（Panic + PAYGAS）。 尽管如此，这些都没有解决可能由单个无效事务引起的拒绝服务向量。
• 2018 年的非正式提案 - 2018 年的一个想法浮出水面，主要通过修改 EVM 以在交易执行的验证部分检查帐户是否读取或写入其自己帐户之外的事物状态来解决拒绝服务向量。 如果是这样，那么这笔交易将被丢弃。 这将使内存池中的有效交易变得无效的唯一方式是交易本身导致无效状态。
• EIP-2938 (2020) — EIP-2938 采用了之前关于账户抽象的想法，并将它们捆绑成一个正式的 EIP。 它提出了 EIP-86 中描述的新交易类型和入口点，利用了 2017 年的 Panic + PAYGAS 思想，并建议在交易执行的验证部分期间防止帐户读取或写入其他帐户的状态（如 2018）。 虽然这确实开始看起来像 EIP-4337，但这里的主要区别在于 EIP-2938 是协议层的更改。 最后，决定支持帐户抽象的更高层实现。

2、EIP-4337概述

EIP-4337 的核心思想是实际上实现与 EIP-2938 相同的结果，但无需对共识进行任何基本协议更改。 它通过允许帐户将他们想要采取的操作打包到 UserOperation 结构中而不是在协议层创建新类型的事务来实现这一点。 然后， UserOperation对象可以发送到专用内存池，捆绑器可以在其中抓取它们并将它们全部放入捆绑交易中，该交易对全局入口点合约进行一次调用。 该过程概述如下：

这里有一个基于全球入口点合约和开放的、类似 MEV 的市场的系统，该系统将多个操作安排到单个包装交易中，验证所有这些交易，然后执行它们。

请注意，入口点合约放置在链上。 钱包必须单独选择信任此入口点合约，以便代表其用户与其进行交互。

让我们一步步进一步探讨这个过程：

2.1 UserOperation对象创建

希望利用 EIP-4337 的用户首先从常规 EOA 创建一个 UserOperation 对象，该对象将与其帐户合约进行交互。 该对象的目标是取代常规交易，因此这些字段将属于账户合约而不是 EOA。  UserOperation 对象及其字段如下所示：

请注意，发送者被设置为合约帐户，除了接收和执行调用数据之外，该帐户本身还将验证签名。

2.2 UserOperations 的捆绑和执行

UserOperation 对象被发送到一个专用的内存池，其中一组捆绑器负责处理这些对象并将它们包含在入口点合约的单个事务中。

在 UserOperation 符合事务包含条件之前，捆绑器必须首先运行一组健全性检查，以验证 UserOperation 是否使用其字段的有效输入正确形成。 如果这些检查通过，则捆绑程序将运行模拟以确定 UserOperation 是否确实有效并且能够为其执行付费。 这是通过调用 EntryPoint.simulateValidation() 来完成的：

这又调用 ender.validateUserOp() 作为验证的一部分。  validateUserOp() 函数还检查签名本身是否有效。 该函数的基本实现如下所示：

如果所有这些检查都通过，那么该函数将恢复预期的错误， UserOperation 将被视为有效，并且捆绑器会将其添加到专用内存池中。 此 UserOperation 现在可以进行捆绑和交易包含。 这就是 Bundlers 通过向 EntryPoint.handleOps() 函数提交（作为 calldata）一组 UserOperations 来发挥其魔力的地方：

这将依次使用 UserOperation.calldata 调用 UserOperation.sender。 由合约账户来实现处理和响应此呼叫数据的工作流程。 通常，账户将实现一个 execute()函数，该函数将调用数据解析为合约账户要进行的一系列一个或多个调用。

了解创建和包含标准 EIP-4337 交易的流程后，我们来讨论一些可以包含在 EIP-4337 交易中的额外功能。

2.3 扩展

EIP-4337 中有两个扩展值得一提：Paymasters 和签名聚合。 付款人是可以代表其他用户付款的合同帐户。 这用于赞助或以其他方式向用户提供无gas交易。 稍微修改后的工作流程如下所示：

签名聚合器也是辅助合约账户，但它们不是代表其他用户付款，而是验证多个交易的聚合签名，从而提高验证过程的效率。 例如，由多个唯一密钥生成的 BLS 签名可以聚合为单个签名，然后可以在单个步骤中验证该签名。 可以在此处找到此类聚合器的基本实现。

3、EIP-4337用例

EIP-4337 为用户和协议带来了许多优势：

• Gas 支付可以由协议赞助，为用户提供无 Gas 体验
• Gas 支付可以使用 ERC20 代币进行，因此用户不再需要直接拥有或使用原生 ETH
• 除了 ECDSA 之外，还可以支持替代验证机制。 如果量子计算导致 ECDSA 被破坏，这对于以太坊的未来验证是有利的
• 通过实施更细粒度的帐户权限（例如基于角色的帐户访问）改善了用户体验
  多重签名账户可以成为一等公民，因此可能会得到更广泛的采用

从广义上讲，账户抽象被广泛视为以太坊走向大规模用户采用之路的重要垫脚石。

4、安全考虑

EIP-4337相关的安全风险考虑如下：

• 入口合约：从 EIP-4337 的结构方式来看，大部分安全风险都存在于入口点合约中。 这充当每个符合 EIP-4337 的帐户的中央信任点。
• 合约账户：对于智能钱包开发人员来说，在实施 EIP-4337 账户时需要考虑一些事项。 这些帐户必须实现自己的验证功能，以准确检查签名（或等效的身份验证机制）、增加随机数并支付费用。 还应特别注意确保帐户上的功能遵循最小特权原则。 添加一个要求 msg.sender 作为入口点合约的修饰符是一个好主意，以确保敏感交互只能由入口点本身调用。

5、结束语

EIP-4337 的高级帐户抽象实现为用户和协议提供了多种优势。 协议可以通过赞助交易费用为用户提供更好的体验，用户甚至可以利用 EIP-4337 直接使用 ERC-20 代币进行支付。 重要的是，EIP-4337 是在以太坊上创建抗量子计算机交易的第一步。 虽然大部分安全责任在于入口点合约，但账户开发人员也应该意识到他们必须自己实现一些功能。 我们建议通过将尽可能多的敏感操作限制在入口点合约来最大程度地减少威胁面。

原文链接：EIPs Explained: EIP-4337

DefiPlot翻译整理，转载请标明出处