以太坊账户抽象路线图 I：EIP-3074，EIP-5806 和 EIP-7702

观察到 Deneb 升级对以太坊所引入的显著变化后，我们开始展望下一个硬分叉 Pectra 将会带来什么。为了帮助塑造未来的讨论，我们寻求描述与以太坊及其 Rollup 生态系统相关的当前账户抽象景观，可能会绘制出一条清晰的前进道路。

本报告提供了以太坊当前账户模型的概述，特别是它们对交易有效性的影响，账户抽象究竟包含了什么，以及关于这一点的推理框架。然后我们将通过评估 EIPs 5086、3074 和 7702 来专注于 EOA 可编程性的方法，并总结这一切对以太坊上交易未来的影响。

关于账户抽象的定义仍有很多混淆，我们在这一系列文章中的框架是，任何允许账户重定义其有效性规则中任何部分的机制都是账户抽象的机制。此外，我们提供了这些机制的分类，因为它们大多模糊相似并有所重叠。

以太坊中的账户抽象概述

账户抽象旨在改善整个以太坊生态系统中用户和开发者的体验。除了使链上体验对用户来说更加可访问和愉悦，它还使开发者能够在以太坊上做出更强大的事情，以更有意义的方式服务用户。

我们对账户抽象方法的分类如下：

1. EOA 增强/可编程性：这包括协议级的更改，使 EOA（外部拥有账户）能够重定义其有效性规则的执行逻辑部分。众所周知，EOA 通常与最终用户相关联。因此，属于这一方法的解决方案将使终端用户账户对他们可以授权的操作类型拥有更大的控制权，与目前的管理方式相比。
2. EOA 转换/迁移：该方法包括寻求将 EOAs 完全转换为 CAs（合约账户）的提案。这种方法的核心思想是，合约账户已经提供了智能账户所提供的大部分好处，因此无需再复杂化；每个人都应该简单地使用合约账户作为其主账户（通过智能合约钱包）。该方法具有允许 EOA 转变为 CA 的机制，而无须移动其资产，例如 EIP 7377 和 EIP 5003（当与 EIP 3074 一起考虑时）。
3. 智能账户：这一组提案包括设计，使得 EOAs 和 CAs 都能作为“智能账户”运作，因为它们能够完全重定义其有效性规则。过去曾提出多种智能账户的创建和账户抽象在协议级上确立的提案；EIP-86 和 EIP-2938 是其中较受引用的提案。然而，由于这种设计带来的复杂性以及过半的观点认为以太坊尚未准备好接受这种复杂性，因而曾遭到大量反对。

在 Vitalik 在合并后重提该主题后，ERC-4337 被提议为智能账户标准的一种自愿选用版本，类似于 MEV（最大可提取价值）的 PBS（提议者-构建者分离）基础设施。因此，寻求访问智能账户好处的用户可以简单地使用 ERC-4337 流程，以在称为 UserOperation（或简称 UserOps）的结构中重定义其账户的逻辑和交易有效性规则。

ERC 4337 带来了智能账户的好处至今的以太坊，而不需确立任何复杂性，作为一种超出协议的选择。 但这并不意味着该基础设施在其当前状态下是最佳的，因为它自身的复杂性仍然是一个相当大的失败点。

为了解决这种复杂性，RIP 7560 被起草为 ERC 4337 基础设施的集成版本，覆盖以太坊及其 L2，这样它可以继承网络的 Sybil 抵抗机制，而不必定义一套新的规则（正如 ERC 4337 与 ERC 7562 一起所做的那样）。

在本报告中，我们将专注于探索 EOA 可编程性，评估描述此方向解决方案的各种 EIP，并讨论其优缺点。在该系列的第 2 部分和第 3 部分中，我们将涵盖以太坊中所探讨的账户抽象的其余两类方法。

以太坊账户和交易入门

为了探索可以抽象出来的内容，我们需要对当前的账户设计有（在某种程度上）全面的了解。本节将主要作为对以太坊账户实际是什么以及它们的交易是如何被验证和执行的复习。

以太坊账户是拥有以太（ETH）余额并能够在以太坊区块链上发送交易的实体。它们被表示为一个 42 字符的十六进制“地址”，作为指向该账户持有资产和交易的唯一指针。

地址作为进入区块链状态试图的关键。这个试图的叶节点是可以被分解为四个字段的账户数据结构：

1. nonce：用于指示账户发起的出站交易次数的线性计数器。它也在防止重放攻击中至关重要。
2. balance：账户所拥有的以太（ETH）的 wei 计量金额。
3. codeHash：包含在账户中的 EVM 可执行代码的哈希。EVM（以太坊虚拟机）是负责处理复杂状态转换而不只是简单“发送”交易的以太坊专属执行环境。一个账户的代码内容被不可变地编程，以在以太坊区块链上通过 EVM 执行特定形式的状态转换。
4. storageHash：账户存储根的哈希，用于将账户的存储内容表示为默克尔帕特里夏试图的根节点的 256 位哈希。简单地说，它是与账户代码内容相关的状态变量数据的哈希。

这四个字段的内容用于定义账户的类型，并最终定义其功能的范围。因此，以太坊有两类账户：

1. 外部拥有账户 (EOAs) - 其初始化为一个密码学密钥对：

   • 一个 私钥，即一个可加密且可证明随机的 64-十六进制字符，以及其互补的对应密钥；
   • 一个 公钥，该公钥是通过使用 ECDSA（椭圆曲线数字签名算法）从私钥导出的。

EOA 具有空的 codeHash 和 storageHash 字段，仅能被拥有私钥的人所控制。可以通过在账户公钥的 keccak-256 哈希的最后二十个字符前添加“0x”来获得其地址。

2. 合约账户 (CAs) - 只能由预先存在的 EOA 创建。由于 EOA 在 EVM 上部署可执行代码内容，从而初始化它们。存储为 codeHash 的代码内容被集成在 EVM 中，并负责通过定义其逻辑和交互来控制该账户。

它们的交易完全是基于拉取的，并以它们已部署代码的逻辑为基础。

由于这些账户只能由其代码内容控制，因此不需要私钥，只有公钥。因此，任何具有更新/更改合约账户代码内容能力的代理，都能够访问其余额。

CA 的地址来源于其创建者的地址和合约部署时的 nonce。

交易

我们近期描述账户为拥有在以太坊上发送交易能力的实体。因此，我们可以理解账户的主要目的就是发送和接收交易，而区块链则充当记录交易历史的分类账，同时描述交易如何根据区块链协议规范中描述的规则更改账户字段。

那么这些“交易”到底是什么？

交易是从账户发送的操作，它们会导致网络的“状态”发生变化。它们是账户的密码学签名指令，在执行时会导致全网状态更新。

无权限性带来了扭曲的激励，因此必须为这种环境中的交互定义严格的指南（或有效性规则）。

在这种情况下，交易必须遵循一定的有效性规则才能被认为有效并得到执行。这些有效性规则大多数通过对发送交易的账户施加约束来实现，并根据账户类型的不同而有所不同。

账户和交易有效性

在以太坊中，EOA 在可用性上得到了优化，因为它们面向最终用户。它们拥有以特定方式 发送交易 的能力，并能够完全自主操作。它们也可以本地创建，常见方法是使用诸如 MetaMask、Rainbow、Rabby 等钱包提供商。

另一方面，合约账户只能发送其逻辑允许的交易，必须在“ 调用 ”后执行。此外，它们只能由拥有足够余额支付其状态存储费用的 EOA 创建。

更高层次的描述是，EOA 只能持有余额，而 CA 可以持有余额和规定如何支出该余额的逻辑。

这些属性源于以下逻辑参数，它们定义了账户交易必须遵循的规则：

1. 身份认证逻辑 - 用于定义账户在更改其余额和/或逻辑时，如如何向网络证明其身份。
2. 授权逻辑 - 用于定义账户的访问策略，即谁能够访问和更改账户的余额和/或逻辑。
3. Nonce 逻辑 - 定义了交易从账户执行的顺序。
4. Gas 付款逻辑 - 用于定义负责结算交易Gas费用的各方。
5. 执行逻辑 - 用于定义账户可以发送什么形式的交易，或如何执行交易。

这些参数对于 EOA 设计得相对严格，因此：

• 身份认证和授权由基于 ECDSA 的私钥提供，即希望从其 EOA 发送交易的用户必须使用其私钥以访问账户，从而证明他们有权执行对其余额的任何更改。
• nonce 逻辑实现了顺序计数器机制，只允许每个唯一 nonce 按顺序执行一次交易。
• Gas 付款逻辑规定交易的Gas费用必须由发送/原始账户来结算。

• 执行逻辑指定了 EOA 仅能发送以下形式的交易：

  1. 两个 EOAs 之间的常规转账。
  2. 合约部署。
  3. 针对已部署合约账户逻辑的合约 调用。

更一般来说，EOA 的执行逻辑限制了它们每次有效签名只能进行一次交易。

另一方面，CA 在这些参数的控制上具有更大的灵活性：

• 身份认证不是必须的，因为它们的交易本质上是后效/拉取型的。

• CA 的授权可以采取两种形式：

  1. “ 调用 ” CA 内容代码的能力（或执行其智能合约），这依赖于账户智能合约的逻辑及其不变性。
  2. 对 CA 内容代码进行更改的能力，这在很大程度上取决于内容代码是否可升级。

在大多数实际案例中，所采用的逻辑是多重签名方案，规定特定账户（通常是 EOA）需要提供 M 的 N （其中 M < N）个有效签名，以使 CA 的逻辑更改有效。

• 其交易排序是松散的基于 nonce。CA 本身能够向多个不同的 调用者 发送出任意数量的交易，但每个调用者的限制则基于他们自身的能力。
• Gas 付款通常由 CA 的逻辑的 调用者 来处理。
• CA 的执行逻辑更加多样化，以支持用户体验改善，如多重调用交易和原子交易。

评估这些特性，我们观察到每种类型的账户在自主性和可编程性之间设计上都有一个权衡。

EOA 具有完全的自主性但有限的可编程性；它们可以在想要时授权并发送交易，但这些交易必须遵循严格格式才会被视为有效。CA 具有完全的可编程性（仅限于 EVM 的设计限制），但自主性有限；它们的交易不必遵循任何严格格式，但只能由于其逻辑被首先调用后才得以发送。

在接下来的小节中，我们将探索这些设计选择的影响，以便全面理解在本系列中讨论的每个 EIP 的提案。

以太坊的账户困境

现在我们已经对不同账户的功能有了较为简明的了解，我们可以轻松识别它们的卖点，同时也能发现它们在以太坊用户和开发者体验中带来的问题。

正如我们之前提到的，EOA 被设计为一类面向最终用户的一等账户。应用程序设计成能轻松与它们互动，几乎没有复杂性，当然，创建一个也没有成本。然而，它的简单性伴随着显著的创新损失，因为它们被设计为严格确定性。

关于它们的一些关注点包括：

1. 易受量子攻击的影响 – 其密钥对使用的 ECDSA 签名方案不是量子抗性方案，考虑到工业量子系统在 5 到 10 年内实现的乐观时间线，这对依赖于 ECDSA 方案进行密码学证明和安全的以太坊和其应用构成了严重威胁。
2. 缺乏表达能力 – EOA 有效性规则的严格格式消除了用户通过诸如交易原子性、批处理和交易代理等功能更简练地表达其交易的能力。
3. 自我可持续性 – 每个人在交易中都有过“我没气了”的经历。这是因为 EOA 被要求自己结算交易的气体，这在不能将以太（ETH）仅作为可接受的气体货币的情况下不算多大的要求。虽然这在基于账户的状态机（甚至基于 UTXO 的状态机）中是普遍问题，但以太坊始终希望有所不同。

并非每个人都想（或能够）总是持有 ETH（看看那价格走势），因此可行的解决方案是提供多种气体货币（难度太大，打破过多的 invariant，如“货币”章节所描述 这里），或者允许通过非交易原始账户的其他账户结算Gas费用。

在账户光谱的另一端，CA 面向开发者和更加技术化的用户基础。它们是智能合约的载体（即，我们认为智能合约是它们所包含的逻辑或代码内容），因此可以实现由 EVM 赋能的新型交易格式。

然而，所有这些特性使它们成为了被美化的二等账户，因为它们没有自主权。它们的一些缺点如下：

1. 完全缺乏自主权 – CA 不能发起交易，它们只能在以特定方式被调用时发送交易。
2. 逻辑中易受人为错误影响 – 缺乏严格性往往导致不变性的错误定义和其他相关逻辑问题，这导致因智能合约漏洞和黑客攻击造成数十亿美元的损失。然而，这几乎是一个完全不同的话题，超出了我们在此的范围。

在审查了导致本小节所定义问题的设计选择后，我们现在可以着手评估提出的解决方案。

账户抽象的时间线

账户抽象（至少通过智能账户的方式）的概念一直是以太坊路线图的重要组成部分。传说是其实现周围的复杂性威胁到了以太坊的进一步推出，因此它被构建为提供不同功能的不同账户的现有设计。由于以太坊对合并的重点，index2此项再次被推迟，现在正重新浮现为该网络下一个重大升级 Pectra 的重要组成部分。然而，其复杂性仍然被认为是阻碍其确立的重要缺点，特别是以太坊已转向以 Rollup 为中心的路线图。

现在的要求是双重的：

1. 账户标准必须更具表现力，但不失去自主性。一个新标准应当弥合 EOA 和 CA 标准之间的差异。
2. 新标准必须弥补 EOA 和 CA 之间的差距，同时在以太坊及其 L2 生态系统中保持全面兼容。

直观地说，这一概念在链抽象和互操作性的背景下发挥着更大作用，但本报告的范围限于为实现账户抽象所采取的技术举措。

账户抽象旨在整合 EOA 和 CA 的最佳特性为一种新的账户标准——智能账户，允许任何账户的有效性规则完全或部分分离为验证逻辑和执行逻辑；这样账户可以自定义其有效性规则——由 EVM 许可，正如合约账户一样，同时保持与外部拥抱账户一样的完全自主性。

对于智能账户和智能合约钱包之间的差异常常产生混淆，因此我们将清楚地描述这些差异如下：

• 智能账户是以太坊账户，旨在提供同等比例的可编程性和自主性。想法是 EOAs 和 CAs 都可以通过利用某些机制（例如 ERC 4337）而成为智能账户，让它们可以根据自己的需要替换网络强制的有效性规则。
• 而智能合约钱包只是一个钱包提供者，充当对合约账户的接口（是的，钱包并不是账户）。

智能合约钱包的商业化促进了 CAs 被更广泛市场接受，允许不太技术化的用户利用它们提供的功能。然而，它们仍面临与 CAs 相关的陷阱。

回到讨论中；我们之前讨论了用于定义账户交易有效性规则的参数：

• 身份认证
• 授权
• Nonce 逻辑
• Gas 付款逻辑
• 执行逻辑

前四个参数的值可统称为账户的验证逻辑，这些是在交易执行开始之前进行的检查。

最后一个参数定义交易执行的方式。

在引言中，我们提供了当前 AA 领域的高层概览，以一种分类的形式对子提出的各种设计进行了分类。我们现在将重点关注以太坊账户困境的第一类解决方案——EOA 可编程性。

可编程 EOA

以太坊的最大吸引力在于其年轻但充满活力的 DeFi 生态系统，拥有多种去中心化应用程序，作为其主要的流动性汇聚器。这些 DApp 大多数针对 EOA 进行了优化，因此它们很难与 CA 进行接口，最终也难以与智能账户连接。虽然智能合约钱包确实帮助了解中 CAs，但它们有自己局限，用户体验也完全不同。

在 DApp 和钱包提供者逐渐适应智能账户标准时，正在探索的一种过渡性解决方案是对 EOA 进行临时增强，使其能够克服大部分强加的限制，无论是验证还是执行逻辑。

以下，我们将讨论三个主要 EIP 的规范，它们为 EOA 可编程性提供可行的路径；从不太知名的 EIP 5806，到雄心勃勃的 EIP 3074，再到最终的 EIP 7702。

通过 EIP-5806 实现可编程性

该提案旨在通过允许 EOA 对合约账户的逻辑（其智能合约）执行委托调用，来为 EOA 标准提供更多功能。这实际上使得智能合约在调用 EOA 的上下文中执行，即 EOA 控制其验证逻辑，而其执行逻辑则由相应 CA 的逻辑处理。

在继续之前，让我们回顾一下以太坊演化的记忆长廊，提到 EIP-7。

EIP-7 提出了创建 0xf4/DELEGATECALL 操作码，用于将消息调用发送到带有二级账户逻辑的主账户，同时保持主账户的 [sender] 和 [value] 字段的值不变。

换句话说，主账户“继承”（或者你更喜欢称之为借用）了额外账户的逻辑，用于执行期间指定的消息调用的持续时间，以便后者的逻辑在主动的上下文中得以执行。

这个操作码允许 dApp 开发者将其应用程序的逻辑分割为多个智能合约，同时保持相互依赖性，从而轻易规避代码大小和气体障碍的限制。

EIP-5806 摘要

那么代理调用允许 CAs 彼此相互依赖的原因是什么？实际上，EIP-5806 是借用 EIP-7 的灵感，建议将代理调用功能扩展到 EOA；也就是说，让我们也允许 EOA 通过代理调用与 CA 建立相互依赖的关系，因为这样做没有坏处。

规范

EIP 5806 引入了一种新的 EIP-2718 兼容 交易类型，其打包格式如下：

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

这些交易旨在使 [to] 字段——代表接收者地址——只能接受 20 字节的地址作为输入，从而禁用发送方使用 CREATE 操作码。

RLP 方案中每个组件的动机如下：

• chainID：当前链的 EIP-115 兼容标识符，填充为 32 字节。此值提供重放攻击保护，以防在具有相似历史记录且经济安全性较低的其他 EVM 链上轻易复制原链的交易。
• nonce：每个交易的唯一标识符，同时也提供重放攻击保护。
• max_priority_fee_per_gas 和 max_fee_per_gas：EIP-5806 交易为排序和包含分别需支付的 gás 费用值。
• gas_limit：单个 5806 类型交易可以消耗的最大Gas量。
• destination：交易接收者。
• data：可执行代码内容。
• access_list：条件授权给 EIP-5806 交易执行的代理。
• signature_y_parity、signature_r 和 signature_s：这三个值一起表示对消息的 secp256k1 签名——keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

虽然 EIP-5806 在 EIP-2718 传输调用规则方面实现了较好的向后兼容性，但 EOAs 不是等同于 CAs。因此必须在 EOA 使用代理调用的方式上定义某些限制，以防止不变性破坏。

这些限制针对以下操作码：

• SSTORE/0x55：此操作码允许账户将值保存到存储中。它在 EIP-5806 交易中受到限制，以防止 EOAs 使用代理调用设置/访问存储，以此防止由于账户迁移而可能在未来产生的问题。
• CREATE/0xF0、CREATE2/0xF5和SELFDESTRUCT/0xFF：这些操作码广泛允许调用者创建新账户。对此的访问受到限制，以防止在执行 EIP-5806 交易时，EOA 的 nonce 在不同的执行过程（合约创建/销毁情况下）中被改变，从而防止了“交易务必携带连续 nonce”的期望被无效。

潜在应用/用例

EIP 5806 的主要适用领域为 EOA 的执行抽象。允许 EOA 借用智能合约逻辑，如下功能拓展了它们的能力：

• 条件执行交易
• 交易批处理
• 多重调用交易（例如，批准并调用）

批评

EIP-5806 提出的更改尽管启用了所需的功能，但并不特别新颖；它的存在主要依赖于已经有效的 EIP-7。这让它得以绕过许多潜在的接受障碍。

在早期阶段，有人提出允许 EOA 访问存储和更改存储的潜在风险。这类似于 CAs 当前的行为。这破坏了与 EOA 如何交易相关的许多网络确立的不变性，因此通过引入前面章节中提到的限制来解决了这一问题。

第二个批评（这是一个双刃剑）是 EIP-5806 的简单性；有人认为，接受 EIP-5806 的收益可能不值得付出的成本，因为它只启用了执行抽象，而不如其他一些类型的 EIPs 那样性能更佳（我们将在后面的小节中讨论它们）。

通过 EIP-3074 实现可编程性

EIP-3074 提议允许 EOAs 将它们大部分的验证逻辑委托给特定的合约账户，称为呼叫者，根据其授权逻辑重叠到特定形式的交易。

它通过签署它们的访问政策，将其定义为一个 invoker 合约，然后由后者为 EOA 定义访问政策，从而实现这一点。

该 EIP 提议向 EVM 添加两个新操作码：

• [AUTH]：基于后者的 ECDSA 签名，将上下文变量 [authorized] 设置为代表第二个 [authority] 账户采取行动。
• [AUTHCALL]：以 [authorized] 账户的身份向 [authority] 账户发送/实施调用。

这两个操作码使 EOA 能够将控制权委托给预先定义的 CA，因此可以通过它进行操作，而无需部署合约并承担相关费用和外部性。

规范

EIP-3074 允许交易使用一个 [MAGIC] 签名格式，以防止与其他交易签名格式发生冲突。在传递 [AUTHCALL] 指令的活动账户定义为一个背景变量字段 [authorized]，该字段仅在单个交易中保持有效，必须对于每个新的 [AUTHCALL] 重新定义。

在讨论各操作码的复杂性之前，以下是涉及 EIP-3074 交易的实体：

• [authority]：主签名账户（EOA），将访问/控制授予第二个账户（通常是合约账户）。
• [authorized]：将接收到 [AUTHCALL] 指令进行执行的账户。换句话说，它是 [AUTHCALL] 的逻辑在其上执行的账户，这是以 [authority] 的身份执行的，使用由 [invoker] 定义的约束。
• [invoker]：一个辅助合约，旨在管理 [authorized] 账户与 [AUTHCALL] 逻辑之间的交互，尤其是在后者的合约代码的主要逻辑是Gas赞助的情况下。

呼叫者合约接收带有 [COMMIT] 值的 [AUTH] 消息，该值定义了账户希望对 [authorized] 的执行施加的限制。

因此，呼叫者的责任是确保在 [authorized] 账户中定义的 [contract_code] 不是恶意的，并能满足主签名账户在 [COMMIT] 值中施加的约束。

[AUTH] 操作码有三个栈元素输入；简单来说——它由三个输入计算单个输出。这些输入是：

1. authority：生成签名的 EOA 的地址。
2. offset
3. length

最后两个输入用于描述从 0 到 97 的可修改内存范围，其中：

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

变量 [yParity]、[r] 和 [s] 一起被解释为在 secp256k1 曲线上对以下消息的 ECDSA 签名，[magic]:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

其中：

• [MAGIC] 是通过组合下列变量而产生的 ECDSA 签名：
  • [chainID]：当前链的 EIP 115 兼容标识符，用于提供对具有相似历史和较少经济安全性的替代 EVM 链上的重放攻击保护。
  • [nonce]：交易签名者账户的当前 nonce，填充为 32 字节。
  • [invokerAddress]：包含 [AUTH] 执行逻辑的合约的地址。
• [COMMIT] 是一个 32 字节的值，用于在呼叫者的预处理逻辑中指定附加交易有效性条件。

如果计算出签名是有效的且签名者地址等于 [authority]，则 [authorized] 字段会更新为 [authority] 提供的值。如果其中任何要求不满足，则 [authorized] 字段保持不变，或者依然是不设值状态。

该操作码的费用以如下收益预算进行计算：

1. 一个固定费用用于 [ecrecover] 预编译及额外的 keccak256 哈希和其他一定的逻辑，总值为 3100 单位。
2. 在当前分配的特定范围内（97 单位）扩展内存时计算的内存扩展费用，类似于 [RETURN] 操作码。
3. 一个固定费用，取决于 [authority] 的热度，热 [authority] 的费用为 100 单位，冷 [authority] 为 2600 单位，以防止因对访问状态的操作码定价错误引发的攻击。

[AUTH] 被设计成不修改内存，并将 [authority] 的值作为参数以便从提供的签名轻松验证其值。

[AUTHCALL] 操作码有七个栈元素输入，用于计算一个输出。

其逻辑与 [CALL] 操作码相同，即它用于向账户发送消息调用并触发该账户合约中的特定逻辑。其逻辑唯一的差异是 [AUTHCALL] 设计为在执行之前设置 [CALLER] 的值。

因此，[AUTHCALL] 被 [authority] 用来以逻辑检查的规则在 [authorized] 中触发上下文特定行为，流程如下：

1. 检查 [authorized] 的值。如果未设定，则执行被视为无效，立即退出框架。这有助于避免因意想不到的失败而产生的错误费用。
2. 检查 [authorized] 预期行为的Gas费用。
3. 检查 [gas] 操作数的 EIP-150 兼容值。
4. 检查 [authority] 的余额中是否可用总Gas费用——[value]。
5. 在从 [authority] 的账户中扣除 [value] 后执行。如果 [value] 大于其余额，则执行无效。

该操作码的Gas费用以如下方式计算：

• 请求调用的固定成本。
• 一个存储读取的固定开销。
• 通过内存扩展费用，[memory_expansion_fee]，其计算方式与 [CALL] 操作码的Gas成本类似。
• 动态成本 [dynamic_gas]。
• 作为子调用的执行成本 [subcall_gas]。

从 [AUTHCALL] 返回的数据通过以下方式访问：

• [RETURNDATASIZE] – 将返回数据缓冲区的大小推送到输出栈上。
• [RETURNDATACOPY] – 将数据从返回数据缓冲区复制到内存。

为了将其全面汇总并减少技术术语；以太坊交易通常指定两个值：

1. tx.origin – 提供交易的授权。
2. msg.sender – 事务实际与其发生。

在 EOAs 中，如前所述，授权与执行紧密结合，即（tx.origin == msg.sender）。这一简单的不变性由大多数问题所引发，如“账户与交易有效性”这一小节中解释的内容。

来自 [authority] 的 [AUTH] 消息使其能够将 tx.origin 功能偏移到 [authorized]，同时仍然保持 msg.sender。同时允许其使用 [COMMIT] 值对这一特权施加限制。

[AUTHCALL] 允许 [authorized] 访问合约逻辑，使用 [invoker] 作为中介来确保它希望访问的合约是无害的。即，对于每一个 [AUTHCALL]，[authorized] 应明确为其 [COMMIT] 指定一个特定的 [invoker]。

潜在应用/用例

EIP 3074 主要支持 EOAs 将其授权逻辑委托给不同账户的能力，但其开放的设计使在不同上下文中能够实现更多功能。

EOA 的整个验证逻辑可以通过对 invoker 应用各种限制/创新进行抽象来实现，一些基于其目标逻辑的可能性设计包括：

• Nonce 逻辑：EIP-3074 允许 EOAs 在发送 [AUTH] 消息时保持其 nonce 不变，同时其每个 [AUTHCALL] 的 nonce 取决于其交互的呼叫者式。这种方式实现了 EOA 的 nonce 并行，因此它们可以在希望时发送多个不重叠的 [AUTHCALL]。
• Gas 付款逻辑：如所述 EIP，invoker 可以设计为允许Gas赞助。因此，用户的 [COMMIT] 的Gas费用可以从交易的原始账户中扣除，或者来自任何支持账户，无论是个人账户还是基于服务的中继（Gas赞助服务）。

同时，上述执行逻辑也能够进行自然而直观的抽象；毕竟，现在拥有执行交易请求的责任的是 invoker （也即 CA）。

批评

• 呼叫者中心化

引用 其中一位作者表述：“我并不期望钱包暴露出签名待任意调用者的功能…… ”。或许 3074 计划的最大问题在于其上构建创新将容易通过授权和专有交易流控制，就像以太坊 MEV 和 PBS 市场的当前版本一样。默认情况下，调用者合约需要进行大量审计，以防止比当前可能的更严重的攻击。这将不可避免地导致一个生态系统，其中只有少数由有影响力人物开发的调用者合约会作为钱包开发者的默认选项。因此，这归结为一个权衡：要么走一条硬性的去中心化道路，风险是不断审计和支持调用者合约，可能影响用户的安全；要么简简单单地采用来自已建立和有声望来源的调用者合约，以提供更好的用户安全保障，并且减少合约安全性的监督。

这一点的另一个方面是设计、审计和营销一个功能性和安全的调用者合约所涉及的成本函数。较小的团队几乎总会被更大的组织超越——尤其是在营销方面——后者已建立了一定的声誉，即使它们的产品更好。

• 向前兼容性问题

EIP-3074 固化了 ECDSA 签名方案，因为它仍然被认为比通过调用者引入的授权方案更有效。虽然有人认为当前量子抗性并不是一个决定性的问题，并且在未来 ECDSA 可被攻破的情况下，风险更大；以太坊的某种未明说的目标是始终领先于这些问题。在不久的将来，可能为了用户体验的轻微改善而牺牲量子-和审查抗性，可能不是最佳选择。

在向前兼容性论点的另一点是，在评估 3074 的好处的同时，ERC-4337（不需要任何协议更改）现在拥有良好的市场，以便避免生态系统的隔离，你也必须与它兼容。

即使在原生账户抽象路线图中，[AUTH] 和 [AUTHCALL] 操作码最终也会在 EVM 中变得过时，这给以太坊引入了大量的技术债务，以提供极少量的用户体验改进。

• ECDSA 方案的不可撤销性

在发送 [AUTH] 消息并委派控制之后，EOA 预期会避免使用通常的私钥授权方案，因为发送“正常”交易会导致每个调用者的授权被撤回。

因此，ECDSA 方案在严格意义上优于任何相关合约可能启用的其他授权方案，这意味着私钥的丢失将导致账户资产的完全损失。

通过 EIP-7702 实现可编程性

该提案最初作为 EIP 3074 的一种有些简约的变体而设计，甚至曾打算成为更新。它的产生是为了解决 EIP 3074 的所谓低效性，特别是其与已经繁荣的 4337 生态系统以及原生账户抽象提案（RIP 7560）不兼容的问题。

它的做法是增加一种新的符合 EIP 2718 的交易类型——[SET_CODE_TX_TYPE]——该交易允许 EOA 在指定交易中表现得像智能账户。

该设计使其具备与 EIP 5806 相同的功能，还有更多，同时与原生账户抽象路线图和现有计划保持兼容。

规范

EIP-7702 允许 EOA 通过符合 [SET_CODE_TX_TYPE] 2718 的交易内容“导入”合约的代码内容，其格式为：

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

该有效载荷与 EIP 5806 的有效载荷完全相似，唯一不同的是它引入了一个“授权列表”。该列表是格式为：

`[[chain_id, address, nonce, y_parity, r, s], ...]`

的有序值序列，其中每个元组定义了 [address] 的值。

在继续之前，SET_CODE_TX_TYPE 中涉及的各方是：

• [authority] ：即 EOA/主签名账户
• [address] ：即包含可委托代码的帐户地址。

当 [authority] 签署一个指定 [address] 的 SET_CODE_TX_TYPE 时，创建一个委托标识符。这是一个“指针程序”，它使得由于 [authority] 的行为在任何时刻导致的所有代码检索请求都被引导到 [address] 的可观察代码。

对于每个 [chain_id, address, nonce, y_parity, r, s] 元组，7702 类型交易的逻辑流程如下：

1. 验证 [authority] 的签名，通过提供的哈希使用：authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. 防止跨链重放攻击和其他攻击向量通过验证链的 ID。
3. 检查 [authority] 是否已有代码内容。
4. 对 nonce 进行检查，以确保 [authority] 的 nonce 等于元组中包含的 nonce。
5. 如果该交易是 [authority] 的第一次 SET_CODE_TX_TYPE 交易，需支付 PER_EMPTY_ACCOUNT_COST 费用。如果余额低于此费用的值，则放弃操作。
6. 委派标识的设置，其中[authority] 的代码被设置为指向 [address]。
7. 签名人的 nonce——[authority]——增加 1。
8. [authority] 被添加到访问地址列表，该列表（过于简化）是一组地址，使得从这些地址的某个交易作用域的回滚使它们（地址）回到回滚前的状态。这如 EIP-2929 中定义的，以便缓存可重用值并防止不必要的费用。

哇！为了把这一切再次捆绑在一起；这个 EIP 允许 EOAs 发送交易，从而设置一个指向合约代码的指针，使它们能在随后的交易中将此逻辑实现为自己的。这样，它在严格意义上比 EIP 5806 更加强大，因为它允许 EOAs 在所希望的时间内实际拥有代码内容（与 EIP 5806 不同，后者仅允许 EOAs 发送委托调用）。

潜在适用性/用例

• 执行抽象

尽管可以说因为 EOA 积极吸收其希望执行的逻辑，所以它不再是抽象，但是它仍然不是该逻辑的“主要拥有者”。此外，它并不直接包含逻辑，它只是指定一个指向逻辑的指针（以减少计算复杂性）。所以我们走的是执行抽象！

• Gas赞助

虽然 require(msg.sender == tx.origin) 不变量被打破以允许自我赞助，但该 EIP 仍然允许赞助交易中继的集成。然而，附带的问题是这类中继需要一个基于声誉或股份的系统，以防止不当攻击。

• 条件访问策略

EOAs 只能指向账户代码的特定部分，以便只有该部分的逻辑可以在它们的上下文中执行。

这还使得子 keys 的存在成为可能，进一步实现“特权降级”，使特定应用程序只能在特定条件下访问账户的余额。例如，你可以想象一个权限可以花费 ERC-20 代币但不能花费 ETH，或每天最多花费总余额的 1% 或仅与特定应用程序互动。

• 跨链智能合约部署

由于其非限制性性质，EIP-7702 交易可以允许用户访问 CREATE2 操作码，并使用它将字节码部署到地址，而无需任何其他限制参数，例如费用市场逻辑（例如 EIP-1559 和 EIP-4844）。这允许地址在多种状态机中恢复和使用相同的字节码，其中在每条链上的账户则负责定义其他上下文变量参数。

批评

• 缺乏向后兼容性

尽管 EIP-7702 仍然非常新，但对于它的依赖性和潜在缺点，已经进行了大量原型设计和测试，但其简约模型确保它在不同上下文中具有很大的灵活性，因此也很有用。然而，它打破了太多的不变量，且不具备立即向后兼容性。

其一些逻辑包括：

1. 中交易 EOA nonce 的更改：EIP-7702 不限制任何操作码以确保一致性。这意味着 EOA 可以在执行 EIP-7702 交易的同时实现 CREATE、CREATE2 和 SSTORE 等操作码，从而允许在不同上下文中增加其 nonce。
2. 允许具有非零 codeHash 值的账户成为交易发起者：EIP-3607 的实施是为了减少 EOA 和 CA 之间“地址碰撞”的潜在影响。当 EOA 地址的 160 位值与 CA 地址完全相等时，就会发生地址碰撞。

大多数用户并不精通账户的实际内容（甚至不清楚账户和地址之间的区别！），因此允许地址碰撞意味着 EOA 可能伪装成一个 CA，并以长期的方式吸引用户资金，最终窃取所有资金。EIP-3607 通过规定包含代码的账户不能使用自己的授权逻辑支出其余额来解决这个问题。然而，EIP 7702 为了使 EOAs 即便在获得一定可编程性后仍然保持自治，打破了这一不变量。

• 与 EIP-3074 的相似性

签名一个账户地址而不是其代码内容基本上与 3074 的调用者方案相同。它并未提供跨链代码内容一致性的严格保证，因为地址在不同链上可能有不同的代码内容。这意味着一个链上代码内容包含相同逻辑的地址，在另一个链上可能具有捕食性或明显恶意，这可能导致用户资金的损失。

结论

目前形式的 EOA 限制很大，因为它们不允许用户利用 EVM 提供的可编程性功能。虽然如我们在本报告开始时概述的那样，有多种途径可以升级账户，但所选择的解决方案必须维护安全的自我保管原则。此外，EOA 升级可能会显著影响用户体验和应用开发人员，因此必须考虑所有利益相关者的声音。

允许 EOAs 以任何方式执行代码极大地扩展了账户的功能，但这种新表现能力伴随着重大风险和潜在的盲点。解决这些权衡对提供对以太坊用户具有无可争议的用户体验好处的升级至关重要。

以太坊开放讨论的文化使其成为这些创新的绝佳试验场，因为几乎每个设计的每个影响都由该领域的专家进行了深入解构。这种全面的考虑有助于降低来自对手的不当行为风险。

EIP-7702 目前是寻求将 EVM 可编程性引入 EOAs 的机制的代表，已被标记为 EIP 3074 在 Pectra 升级中的替代品。它继承了 3074 机制的开放设计，同时大大降低了攻击面/风险。同时，避免了 3074 对特定类操作码的限制，使其能实现更多。

尽管提案的设计仍处于一些完善之中，但它已经获得了众多开发人员的好评和支持，尤其是因为它得到维塔利克的直接支持。

在社区中，有人声称这种账户抽象的方法甚至比智能账户更好。这一评论强调，此路径需要较少的更改且不那么复杂，并且 EOAs 已经确立。然而，我们必须记住，以太坊网络各层的未来安全里程碑——量子抗性。在当前账户模型核心中，由于使用基于 ECDSA 的签名方案作为 EOA 授权，这种量子安全是无法实现的。

因此，EOA 的可编程性应被视为通往智能账户道路上的一步，而非终点。它为 EOAs 提供了动力，提高了用户和开发者的体验，同时仍与智能账户的终极账户抽象目标保持兼容。

在我们的下一份报告中，我们将深入研究 EOA迁移方案，看看它们在账户抽象路线图中适配得如何，敬请期待！

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