账户抽象旨在改善整个以太坊生态系统中的用户和开发者体验。它不仅使链上用户体验更加易于使用和顺畅，还使开发者能够在以太坊上实现更强大的功能，并以更加有意义的方式为用户提供服务。

我们将账户抽象的方法进行了如下分类：

1. EOA增强/可编程性：这一方法包括协议层面的变化，使 EOA（外部拥有账户）能够重新定义其有效性规则中的执行逻辑部分。EOA 是通常与最终用户相关联的账户。因此，相较于现有的管理方式，属于此方法的解决方案将赋予终端用户更多控制权，使其能够授权更多类型的操作。
2. EOA转换/迁移：这一方法包括一些提案，旨在将 EOA 完全转换为 CA（合约账户）。这一方法的核心思想是，合约账户已经提供了智能账户大多数的优势，因此无需再将事情复杂化；每个人应简单地使用合约账户作为其主要账户（通过智能合约钱包）。

这种方法提供了使 EOA 过渡到 CA 的机制，而无需转移其资产，例如 EIP 7377 和 EIP 5003（当与 EIP 3074 一起考虑时）。

1. 智能账户：这类提案包括允许 EOA 和 CA 表现为“智能账户”的设计，这些设计是通过使它们能够完全重新定义其有效性规则来实现这一点的。

先前已提出了多种创建智能账户和在协议层面实施账户抽象的提案；EIP-86 和 EIP-2938 是其中被引用较多的几个。然而，这一设计曾遭遇了较大的反对，是因为它带来的复杂性，以及人们认为以太坊尚未准备好应对这种复杂性。

在合并后，Vitalik 重新提出了这个话题，ERC-4337 被提议作为智能账户标准的可选版本，类似于 MEV（最大可提取价值）的 PBS（提议者-构建者分离）架构。因此，用户如果希望访问智能账户的优势，可通过 ERC-4337 管道来重新定义账户逻辑和交易的有效性规则，这些结构称为 UserOperation（简称 UserOps）。

ERC-4337 不需要引入复杂性就能将智能账户的优势带入现有的以太坊，作为智能账户的协议外替代方案。然而，这并不意味着该基础设施在现有状态下是最优的，因为其本身的复杂性仍然是一个潜在的故障点。

为了应对这一复杂性，草拟了 RIP 7560 作为以太坊及其 L2 网络上 ERC-4337 基础设施的正式版本，使其继承网络的 Sybil 抗性机制，而不必重新定义一套新的规则（如 ERC-4337 与 RC 7562 所做的那样）。

在本报告中，我们将重点探讨 EOA 的可编程性，评估描述这一方向解决方案的各种 EIP，并讨论它们的优缺点。在本系列的第二部分和第三部分中，我们将涵盖以太坊正在探索的账户抽象的另外两种方法类别。

以太坊账户与交易概述

要探讨什么可以进行抽象化处理，我们首先需要对当前的账户设计有一个（较为）完整的了解。本节将主要回顾以太坊账户实际情况，介绍它们的交易是如何被验证和执行的。

以太坊账户是存有以太币（ETH）余额并能够在以太坊区块链上发送交易的实体。账户通过一个 42 字符的十六进制“地址”表示，该地址是账户资产和交易的唯一标识。

地址充当区块链状态树的入口键。该状态树的叶节点是账户数据结构，可以被分解为以下四个字段：

1. nonce： 一个线性计数器，用于表示账户发起的外部交易的数量。它在防止重放攻击方面也起着至关重要的作用。
2. balance： 账户拥有的以太币（ETH）数量，以 wei 为单位表示。
3. codeHash： 账户中包含的 EVM 可执行代码的哈希。EVM（以太坊虚拟机）是以太坊的专用执行环境，负责处理除了简单的“发送”交易之外的复杂状态转换。账户的代码内容是不可变的，并被编程为执行特定类型的状态转换。
4. storageHash： 账户存储根的哈希，用于表示账户存储内容，作为一个 256 位哈希值，代表 merkle patricia 树的根节点。简单来说，它是与账户代码内容相关的状态变量数据的哈希。

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

1. 外部拥有账户（EOAs） - 通过加密密钥对初始化：
   • 一个私钥，它是一个可加密且可证明随机的 64 字符十六进制数；
   • 其对应的公钥，通过使用 ECDSA（椭圆曲线数字签名算法）从私钥导出。

EOAs 的 codeHash和 storageHash字段为空，只能由持有私钥的人控制。其地址可以通过将“0x”前缀加到账户公钥的 keccak-256 哈希后的最后 20 个字符来获得。

1. 合约账户（CAs） - 只能由已存在的 EOA 创建。它们是由于 EOA 在 EVM 上部署可执行代码内容而被初始化的。这个代码内容（存储为 codeHash）被写入 EVM 中，并负责通过定义其逻辑和交互来控制账户。

它们的交易完全基于拉取模式，并且以其已部署代码的逻辑为前提。
由于这些账户只能通过其代码内容进行控制，因此它们不需要私钥，仅有公钥。因此，任何能够更新或更改合约账户代码内容的代理人，都能访问其余额。
CA 的地址是通过其创建者的地址和合约部署时的 nonce 派生出来的。

交易

我们刚刚将账户描述为能够在以太坊上发送交易的实体。因此，可以理解，账户的一个主要功能就是发送和接收交易，而区块链则充当着记录交易历史的账本，并描述交易如何根据区块链协议规范的规则改变账户字段。

那么，“交易”到底是什么呢？

交易是从账户发出的操作，导致网络“状态”的变化。它们是由账户加密签名的指令，执行时会更新整个网络状态。

无许可性伴随着扭曲激励的风险，必须定义严格的准则（或有效性规则）来应对这种环境中的交互。

在此背景下，交易必须遵循一定的有效性规则，才能被视为有效并执行。大多数有效性规则是通过对发送交易的账户施加约束来实现的，并且这些规则会根据账户类型的不同而有所变化。

账户与交易有效性

在以太坊上，外部拥有账户（EOAs）是为终端用户优化的账户类型。它们能够以特定的方式发送交易，并且能够完全自主地运作。EOAs 还可以在本地创建，常见的方式是通过使用如MetaMask、Rainbow、Rabby 等钱包服务提供商。

另一方面，合约账户（CAs）只能发送其逻辑允许的交易，并且只有在被“调用”时才会发送交易。此外，合约账户只能由拥有足够余额支付其状态存储费用的 EOA 创建。

从更高层次来看，EOAs 仅能持有余额，而 CAs 既可以持有余额，又可以持有逻辑，用以决定如何使用这些余额。

这些属性是由以下逻辑参数决定的，这些参数定义了账户交易必须遵循的规则：

1. 身份验证逻辑：用于定义账户如何在改变余额和/或逻辑时向网络证明其身份。
2. 授权逻辑：用于定义账户的访问权限，即谁有权访问和更改账户的余额和/或逻辑。
3. nonce逻辑：定义账户交易的执行顺序。
4. Gas 支付逻辑：用于定义谁负责支付交易的 Gas 费用。
5. 执行逻辑：用于定义账户可以发送哪些形式的交易，或定义交易如何执行。

这些参数对 EOAs 而言是严格的，因此：

• 身份验证和授权是通过基于 ECDSA 的私钥提供的，即用户希望从 EOA 发送交易时，必须使用其私钥来访问账户，从而证明其有权对余额执行任何变动。
• nonce 逻辑实现了一个顺序计数器机制，每个唯一的 nonce 只能按顺序执行一次交易。
• Gas 支付逻辑规定，交易的 Gas 费用必须由发送方/发起账户结算。
• 执行逻辑规定，EOAs只能发送以下几种交易形式：

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

更广泛地说，EOAs 的执行逻辑限制了它们每个有效签名只能发送一次交易。

另一方面，CAs 在这些参数上更加灵活：

• 身份验证不是必需的，因为它们的交易本质上是基于结果/拉取的。
• CAs 的授权可以有两种形式：

1. 能够“调用” CAs 的内容代码（或执行其智能合约），这取决于账户智能合约的逻辑及其不变性。
2. 能够更改 CAs 的内容代码，这主要取决于代码内容是否可升级。

在大多数实际情况中，使用的逻辑是多签名方案，该方案规定，必须由特定账户（通常是EOAs）提供有效的 M 签名（M < N），才能使对 CA 逻辑的更改有效。

• 它们的交易顺序是松散地基于 nonce 的。CA 本身可以向尽可能多的不同调用者发送尽可能多的交易，但每个调用者因其自身能力而受到限制。
• Gas 支付通常由调用 CA 逻辑的调用者处理。
• CAs 的执行逻辑更加多样化，可改进用户体验，如多重调用交易和原子交易。

评估这些特性后，我们观察到，每种类型的账户都在自治性和可编程性之间做出了权衡。

• EOAs 具有完全的自治性，但可编程性有限；它们可以随时授权并发送交易，但这些交易必须遵循严格的格式才能被认为是有效的。
• CAs 拥有完全的可编程性（仅受 EVM 设计的限制），但自治性有限；它们的交易不需要遵循任何严格的格式，但只能在其逻辑被首先调用时发送。

在接下来的小节中，我们将研究这些设计选择的影响，从而充分理解本系列中讨论的每个 EIP 的提案。

以太坊账户困境

现在我们对不同类型账户的功能有了相对简明的了解，我们可以更容易地理解它们的优点以及它们对以太坊用户体验和开发者体验所带来的问题。

正如我们之前提到的，EOAs（外部拥有账户）是面向终端用户的一级账户。应用程序设计上便于与 EOAs 进行交互，几乎没有复杂性，创建一个 EOA 也没有成本。然而，它的简易性也带来了显著的局限性，因为它们是严格确定性的设计。

与 EOAs 相关的一些问题有：

1. 易受量子攻击——它们的密钥对所使用的 ECDSA 签名方案并不具备抗量子攻击的能力，并且乐观的预期是量子计算工业系统在 5 到 10 年内可能实现，这对以太坊及其应用构成了重大威胁，因为以太坊及其应用严重依赖 ECDSA 方案来进行加密证明和安全性保障。
2. 缺乏表达性——EOAs 的有效性规则格式严格，无法使用户通过诸如交易原子性、批量处理和交易委托等功能，更简洁地表达他们的交易。
3. 自我维持能力差——每个人都经历过“我在交易过程中没了Gas”的情况。这是因为 EOA 需要自己支付交易的 Gas 费用，如果以太币（ETH）不是唯一可接受的 Gas 货币，这个问题其实不会这么严重。虽然这是基于账户的状态机（甚至是基于 UTXO 的状态机）的普遍问题，但以太坊的初衷是有所不同的。

不是每个人都想（或者能够）一直持有 ETH（看看那价格波动），所以可行的解决方案是要么允许多种 Gas 货币（但这太复杂了，会打破“货币”部分描述的多个不变性），要么允许由不是交易来源账户的其他账户结算 Gas 费用。

另一方面，合约账户（CAs）主要面向开发者和更技术化的用户群体。它们作为智能合约的载体（即我们认为智能合约是其包含的逻辑或代码内容），因此可以实现由 EVM 支持的新型交易格式。

然而，尽管具备这些特性，CAs 仍然是被美化的二级账户，因为它们没有自主性。它们有如下一些缺点：

• 完全缺乏自主性——CAs 无法主动发起交易，它们只能在以特定方式被调用后，响应性地发送交易。
• 逻辑上容易出错——缺乏严格性往往会导致错误定义不变性和其他逻辑，这导致了由于智能合约漏洞和黑客攻击而造成的数十亿美元损失。然而，这是一个几乎完全不同的话题，超出了本讨论的范围。

在回顾了导致本小节所定义问题的设计选择之后，我们现在可以继续评估提出的解决方案。

账户抽象时间表

账户抽象的概念（至少是通过智能账户）一直是以太坊路线图的重要组成部分。传说中，其实现所涉及的复杂性曾威胁到以太坊的发布进度，因此它被放弃，取而代之的是当前的设计，不同类型的账户提供不同的功能。随着以太坊将重点转向“合并”（The Merge），这一概念再次被推迟，而如今它作为网络下一个重大升级——Pectra 的核心部分重新浮出水面。然而，它的复杂性仍被视为一个重大缺点，导致其无法得到正式确立，尤其是以太坊已经转向了以 Rollup 为中心的路线图。

当前的要求可以总结为两方面：

1. 账户标准必须更加具备表达性，但不能失去自主性。需要一种新的标准，能够明确划分 EOA（外部拥有账户）和 CA（合约账户）标准之间的界限。
2. 新标准必须弥合 EOA 和 CA 之间的差距，同时保持与以太坊及其 L2 生态系统的充分兼容性。

直观来看，这一概念在链抽象和互操作性的背景下扮演着更重要的角色，但我们在本报告中仅讨论实现账户抽象的技术举措。

账户抽象旨在将 EOA 和 CA 的最佳特性结合成一种新的账户标准——智能账户。这种智能账户允许完全或部分地将账户的有效性规则分离为验证逻辑和执行逻辑；使账户能够像合约账户一样定义自己的有效性规则——在 EVM 允许的范围内，同时又能像外部拥有账户一样保持完全的自主性。

常常有人将智能账户和智能合约钱包混淆，不明白它们之间的区别，因此我们将在下文明确描述这两者的差异：

智能账户是以太坊账户的一种设计理念，旨在实现编程灵活性和自主性的平衡。其理念是， EOA 和 CA 都可以通过某些机制（例如 ERC 4337）变成智能账户，这些机制允许它们根据需要用定制的有效性规则替换由网络强加的有效性规则。

另一方面，智能合约钱包只是作为合约账户接口的钱包提供者（是的，钱包并不是账户）。

智能合约钱包的商业化推动了 CA 在更广泛市场的普及，使得技术门槛较低的用户能够利用其功能。然而，它们仍然面临与 CA 相关的固有问题。

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

• 身份验证
• 授权
• 随机数逻辑
• Gas 支付逻辑
• 执行逻辑

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

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

在介绍部分，我们通过对各种提议设计进行某种分类，概述了当前账户抽象（AA）领域的整体情况。接下来，我们将重点关注以太坊账户困境的第一类解决方案——EOA 可编程性。

可编程 EOA（外部拥有账户）

以太坊最大的吸引力在于其新兴且充满活力的 DeFi 生态系统，该生态系统包含多种去中心化应用（DApp），它们是主要的流动性汇聚点。多数去中心化应用（DApps）都优化为服务外部拥有账户（EOAs），因此难以与合约账户（CAs），也就是智能账户，进行交互。虽然智能合约钱包在这种情况下可以帮助 CAs，但它们也有自身的局限性，而且提供的用户体验完全不同。

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

下面，我们将介绍三项主要的 EIP（以太坊改进提案）规范，这些提案为 EOA 的可编程性提供了可操作的路径；从较少被关注的 EIP 5806，到雄心勃勃的 EIP 3074，再到最终取得胜利的 EIP 7702。

通过EIP-5806实现可编程性

该提案旨在通过允许外部拥有账户（EOA）执行委托调用（delegate call）来扩展其功能，使其能够调用合约账户（CA）的逻辑（即智能合约）。这实际上使得智能合约在调用方 EOA 的上下文中执行，也就是说，EOA 依然掌控验证逻辑，而执行逻辑则由相应的 CA 的逻辑处理。

在进一步讨论之前，让我们回到 EIP-7，回顾一下以太坊演进的历史。

EIP-7 提议创建 0xf4/DELEGATECALL 操作码，用于在调用主账户时使用辅助账户的逻辑，同时保持主账户的 [sender] 和 [value] 字段的值不变。

换句话说，主账户“继承”（或者如果你愿意，可以称为借用）次账户的逻辑，并在指定的消息调用期间内执行，这样次账户的逻辑就在主账户的上下文中被执行。

这个操作码使得 DApp 开发者可以将应用逻辑拆分到多个智能合约中，同时保持相互依赖性，从而轻松绕过代码大小和 gas 费用的限制。

EIP-5806 概述

那么，委托调用如何让合约账户（CAs）相互依赖呢？EIP-5806 以 EIP-7 为灵感，提出了将委托调用功能扩展到外部拥有账户（EOAs）的建议；也就是说，让我们允许 EOAs 也与 CAs 互相依赖，因为为什么不呢。

规范

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 交易为排序和包含支付的 gas 费用。
• 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 信封中，使其在很大程度上兼容旧版，但 EOA 与 CA 并不等同。因此，必须在 EOA 使用委托调用时定义某些限制，以防止破坏不变性。

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

• SSTORE/0x55：该操作码允许账户将一个值保存到存储中。在 EIP-5806 交易中对此操作码进行了限制，以防止 EOA 通过委托调用设置或访问存储，从而避免未来因账户迁移而可能出现的问题。
• CREATE/0xF0, CREATE2/0xF5 和 SELFDESTRUCT/0xFF：这些操作码允许调用者创建新账户。对这些操作码的访问进行了限制，以防止 EOA 在执行 EIP-5806 交易时，因合约创建/销毁等操作改变其 nonce 值，进而使得交易的连续性受到破坏。

潜在适用性/用例

EIP 5806 的主要适用场景是外部拥有账户（EOAs）的执行抽象。允许 EOAs 无需信任即可与智能合约进行交互，超越简单的调用合约逻辑，从而为它们提供以下功能：

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

批评意见

EIP-5806 提出的变化，虽然启用了所需的功能，但并不特别创新；它的存在大多基于已经有效的 EIP-7。这使得它可以绕过许多可能的接受障碍。

其中一个早期提出的主要担忧是，允许外部拥有账户（EOAs）像当前的合约账户（CAs）一样访问并修改存储数据的潜在风险。这打破了网络上关于 EOAs 如何进行交易的许多固定规则，因此通过引入前面小节中提到的限制来处理这一问题。

第二个批评（有点像双刃剑）是 EIP-5806 的简单性；有一种观点认为，接受 EIP-5806 所带来的回报可能不足以弥补其成本，因为它只启用了执行抽象，而没有更多的功能。与其他类似的 EIP 相比，接受 EIP-5806 后，所有其他有效性限制仍然由网络定义，而不是像其他类似提案那样提供更多的功能。

通过EIP-3074实现可编程性

EIP-3074 提议允许外部拥有账户（EOAs）将大部分验证逻辑委托给专门的合约账户，称为‘调用者（invokers）’，通过将调用者的授权逻辑覆盖在自己的验证逻辑上，来处理特定形式的交易。

它通过将其访问策略的签名授权给一个 invoker 合约来实现这一点，之后该合约就负责定义 EOA 的访问策略。

此 EIP 提议向以太坊虚拟机（EVM）中添加两个新的操作码：

• [AUTH]：该操作码通过基于第二个账户的 ECDSA 签名，设置一个上下文变量 [authorized] 账户，授权该账户代表另一个 [authority] 账户执行操作。
• [AUTHCALL]：该操作码允许通过 [authorized] 账户从 [authority] 账户发起/执行调用。

这两个操作码使得 EOA 可以将控制权委托给一个预先建立的合约账户（CA），从而通过该合约账户行事，而无需部署一个合约，避免了部署合约所带来的成本和外部影响。

规范

EIP-3074 允许交易使用 [MAGIC] 签名格式，以防止与其他交易签名格式发生冲突。传递 [AUTHCALL] 指令的活动账户被定义为一个上下文变量字段 [authorized]，该字段只在一个交易内存在，并且必须在每次新的 [AUTHCALL] 中重新定义。

在理解每个操作码的复杂性之前，先来了解 EIP-3074 交易中涉及的实体：

• [authority]：主签名账户，通常是外部拥有账户（EOA）。该账户将控制权委托给第二个账户，通常是合约账户（CA）。
• [authorized]：该账户是执行 [AUTHCALL] 指令的目标账户，代表 [authority] 执行逻辑，并遵循 [invoker] 定义的约束条件。
• [invoker]：子合约，负责管理 [authorized] 账户与 [AUTHCALL] 逻辑之间的交互，尤其是当 [authorized] 合约的主要逻辑涉及 gas 资助时。

调用者合约接收来自 [authority] 的 [AUTH] 消息及其 [COMMIT] 值；该值定义了账户希望对 [authorized] 执行 [AUTHCALL] 指令时施加的限制。

因此，调用者合约负责确保在 [authorized] 账户中定义的 [contract_code] 不存在恶意行为，并且能够满足由主签名账户在 [COMMIT] 值中定义的不变性。

[AUTH] 操作码有三个栈元素输入；简而言之，它由三个输入计算一个输出。这些输入为：

• authority：EOA的地址，用于生成签名
• offset
• length

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

• [memory(offset : offset+1)] – [yParity]
• [memory(offset+1 : offset+33)] – [r]
• [memory(offset+33 : offset+65)] – [s]
• [memory(offset+65 : offset+97)] – [COMMIT]

变量 [yParity]、[r] 和 [s] 共同解释为 ECDSA 签名 [magic]，它基于 secp256k1 曲线和以下消息生成：

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

其中：

• [MAGIC] 是 ECDSA 签名，由以下变量组合而成：
  • [chainID]：当前链的 EIP-115 兼容标识符，用于在历史相似且经济安全性较低的替代 EVM 链上提供重放攻击保护。
  • [nonce]：交易签名者地址的当前 nonce 值，左填充为 32 字节。
  • [invokerAddress]：包含 [AUTH] 执行逻辑的合约地址。
  • [COMMIT]：一个 32 字节的值，用于指定在调用者预处理逻辑中额外的交易有效性条件。

如果计算出的签名有效且签名者地址与 [authority] 相同，[authorized] 字段将更新为 [authority] 提供的值。如果这些要求未得到满足，[authorized] 字段将保持其先前的状态，或作为未设置值。

该操作码的 gas 费用计算为以下各项的总和：

• 固定费用，包括 [ecrecover] 预编译和额外的 keccak256 哈希及一些附加逻辑，总计 3100 单位。
• 内存扩展费用，计算方式类似于 [RETURN] 操作码，当内存超出当前分配的指定范围时（97 单位）。
• 为了防止因误定价的状态访问操作码而发生攻击，[AUTH] 操作码有一个固定费用：对于热的 [authority] 账户为 100 单位，对于冷的 [authority] 账户为 2600 单位。

[AUTH] 被设计为不修改内存，并将 [authority] 的值作为参数，因此可以轻松验证其签名。

[AUTHCALL] 操作码

[AUTHCALL] 操作码有七个栈元素输入，用于计算一个栈元素输出。其逻辑与 [CALL] 操作码相同；即，它用于向账户发送消息调用并触发其合约中的特定逻辑。唯一的不同之处在于， [AUTHCALL] 被设计为在执行前先设置 [CALLER] 的值。

因此， [AUTHCALL] 由 [authority] 用来在 [authorized] 中触发特定上下文的行为，执行过程中的逻辑检查如下：

1. 检查 [authorized] 的值。如果未设置，则认为执行无效，立即退出当前框架。这有助于防止由于前所未有的失败而产生不公平的费用。
2. 检查 [authorized] 预期行为的 gas 费用。
3. 检查 [gas] 操作数是否符合 EIP-150 的规范值。
4. 检查 [authority] 账户余额中是否有足够的总 gas 费用 [value]。
5. 执行时，从 [authority] 的余额中扣除 [value]。如果 [value] 超过其余额，则执行无效。

[AUTHCALL] 的 gas 费用由以下部分组成：

• 固定费用：调用 [warm_storage_read]。
• 内存扩展费用：计算方式类似于 [CALL] 操作码的 gas 费用。
• 动态费用 [dynamic_gas]。
• 子调用执行费用 [subcall_gas]。

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

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

为了简化技术细节，通常以两种方式指定以太坊交易的值：

• tx.origin：提供交易的授权。
• msg.sender：交易实际发生的账户。

在 EOA 中，如前所述，授权与执行紧密结合，即（tx.origin == msg.sender）。这一简单的不变性导致了报告中“账户与交易有效性”小节所讨论的大多数问题。

[AUTH] 消息来自 [authority]，允许将 tx.origin 功能偏移到 [authorized]，而保持 msg.sender 不变。它还允许使用 [COMMIT] 值定义对这一权限的限制。

[AUTHCALL] 允许 [authorized] 访问合约逻辑，通过 [invoker] 作为中介，确保其访问的合约无害。也就是说，每个 [AUTHCALL]，[authorized] 必须为其 [COMMIT] 指定一个特定的 [invoker]。

潜在适用性/用例

EIP-3074 主要用于允许 EOA 将其授权逻辑委托给不同的账户，但其开放设计在不同的上下文中能够实现更多功能。

EOA 的整个验证逻辑可以通过应用必要的约束/创新来抽象化，基于目标逻辑的一些可能设计包括：

• Nonce 逻辑：EIP-3074 允许在发送 [AUTH] 消息后，EOA 的 nonce 保持不变，而每个 [AUTHCALL] 的 nonce 则取决于它与哪个 invoker 交互。这样，它支持 EOA 的 nonce 并行性，使得它们可以根据需要发送多个互不重叠的 [AUTHCALL]。
• Gas 费用支付逻辑：如 EIP 中所述，invoker 可以被设计为支持 gas 赞助。因此，用户的 [COMMIT] 的 gas 费用可以从交易的 origin 账户或任何支持账户（无论是个人账户还是服务型中继，如 gas 赞助服务）中扣除。
• 执行逻辑直观地被抽象化；毕竟，invoker（作为一个合约账户）现在负责代表 EOA 执行交易请求。

批评意见

• 调用者合约的中心化问题

正如其一位作者所言：“我不希望钱包暴露出可以授权任意调用者的功能…”。EIP-3074 所带来的最大问题之一是，在其基础上创新可能很容易导致许可化和专有的交易流程，就像当前以太坊的 MEV 和 PBS 市场的演变一样。

默认情况下，调用者合约需要经过广泛的审计，以防止比目前更严重的攻击。这不可避免地会导致一个生态系统，其中只有少数由有影响力人物开发的调用者合约会被钱包开发者作为默认选项采用。因此，这就变成了一个权衡问题：是在不断审计和支持调用者合约的过程中，承担用户安全风险，还是选择采用来自已建立和信誉良好的来源的调用者合约，这些合约对用户安全有更好的保障，同时对合约安全的监督较少。

这一点的另一个方面是，与设计、审计和推广一个功能性和安全的 invoker 相关的成本问题。较小的团队几乎总是会被更大的组织超越——尤其是在营销方面——即便他们的产品更好，较大的组织由于已有一定的声誉，通常更容易获得成功。

• 向前兼容性问题

EIP-3074 使 ECDSA 签名机制更加根深蒂固，因为它仍然被认为比通过 invoker 引入的授权机制更有效。尽管有一些观点认为量子抗性目前不是一个确定的问题，而且在未来 ECDSA 可能被攻破的情况下，实际上面临的风险更大；以太坊的目标通常是始终走在这些问题前面。为了获得在用户体验上的微小改进，可能牺牲量子抗性和审查抗性，并不是近未来的最佳选择。

关于向前兼容性的问题，在 EIP-3074 的好处尚在评估时，ERC-4337（无需任何协议更改）已经取得了一个良好的市场，因此你也必须兼容它，以避免生态系统的隔离。而且即使在本地账户抽象的路线图中，[AUTH] 和 [AUTHCALL] 操作码最终会在 EVM 中变得过时，给以太坊带来大量的技术债务，来换取用户体验的微小改善。

• ECDSA 方案的不可逆性

在发送 [AUTH] 消息并委托控制后，EOA 必须避免使用常规的私钥授权方案，因为发送“普通”交易会导致其委托给每个调用者的授权被撤销。

因此，ECDSA 方案仍然优于任何其他授权方案，意味着私钥丢失会导致账户资产的完全丧失。

通过 EIP-7702 进行编程

通过 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 = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s) 验证 [authority] 的签名。
2. 通过验证链的 ID 来防止跨链重放攻击和其他攻击向量。
3. 检查 [authority] 是否已经有代码内容。
4. 检查 nonce，确保 [authority] 的 nonce 等于元组中包含的 nonce。
5. 如果这是 [authority] 的第一次 SET_CODE_TX_TYPE 交易，则收取 PER_EMPTY_ACCOUNT_COST 费用。如果其余额低于此费用，操作将被放弃。
6. 发生委托指定，其中 [authority] 的代码被设置为 [address] 的指针。
7. 签名者 [authority] 的 nonce 增加 1。
8. [authority] 被加入到一个列表——已访问地址。该列表（简化版）是一个地址集合，进入其范围的交易会使这些地址恢复到先前的状态，如同未进入该范围一样。这是根据 EIP-2929 定义的，用于缓存可重复使用的值并防止不必要的费用。

简而言之，这个 EIP 允许 EOAs 发送交易，设置指向合约代码的指针，使它们在后续交易中能够实现此逻辑。因此，它比 EIP 5806 更强大，因为它允许 EOAs 持有代码内容，直到它们希望为止（而 EIP 5806 仅允许 EOAs 发送委托调用）。

潜在适用性/用例

• 执行抽象化

虽然可以争论说它不再是一个抽象，因为 EOA 积极地选择它希望执行的逻辑，但它仍然不是该逻辑的‘主要拥有者’。此外，它并不直接包含逻辑，而只是指定了指向逻辑的指针（以减少计算复杂度）。所以我们仍然称之为执行抽象！

• Gas 赞助

尽管 require(msg.sender == tx.origin) 不变式被打破以允许自我赞助，但该 EIP 仍然允许集成赞助交易中继。需要注意的是，这些中继需要一个基于声誉或股份的系统来防止恶意攻击。

• 条件访问策略

EOAs 只能指向账户代码的特定部分，从而使得只有该部分的逻辑可以在其上下文中执行。

这还使得子密钥的存在成为可能，从而实现“权限降级”，确保特定的 dApp 仅在特定条件下能够访问账户余额。例如，你可以设想一个权限，允许支出 ERC-20 代币但不允许支出 ETH，或者每日至多支出总余额的 1%，或仅与特定应用交互。

• 跨链智能合约部署

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

批评意见

• 缺乏向后兼容性

尽管 EIP-7702 仍然非常新，但其依赖项和潜在缺点已经进行了大量原型设计和测试。由于其极简主义的模型，它在不同的上下文中具有很大的灵活性和实用性。然而，它打破了许多不变式，并且不立即向后兼容。

其中的一些逻辑包括：

* **交易中途 EOA nonce 修改**：EIP-7702 不限制任何操作码，以确保一致性。这意味着 EOA 可以在执行 EIP-7702 交易时实现 CREATE、CREATE2 和 SSTORE 等操作码，从而允许其 nonce 在不同的上下文中增加。
* **允许非零 codeHash 值的账户作为交易发起者**：EIP-3607 的实施是为了减少 EOA 和 CA 之间的“地址碰撞”潜在影响。地址碰撞发生在 EOA 的地址与 CA 的地址完全相同时。大多数用户对账户的实际内容（甚至对账户和地址之间的区别）并不熟悉，因此允许地址碰撞意味着 EOA 可以伪装成 CA，吸引用户资金并最终窃取这些资金。EIP-3607 通过规定包含代码的账户不能使用自己的授权逻辑来花费其余额来解决这个问题。然而，EIP-7702 打破了这一不变式，使得即使获得了一些可编程性，EOA 仍能保持自主性。

• 与 EIP-3074 的相似性

签署账户地址而不是其代码内容实际上类似于 3074 中使用的调用者方案。它没有提供严格的跨链代码内容一致性保证，因为一个地址在不同链上的代码内容可能不同。这意味着一个在某条链上包含相同逻辑的地址，在另一条链上可能是掠夺性或完全恶意的，这可能导致用户资金的损失。

结语

目前的 EOA（外部拥有账户）形式受限，无法让用户充分利用 EVM 提供的可编程功能。虽然我们在本报告开始时概述了多种升级账户的路径，但选择的解决方案必须保持安全、可靠的自主管理原则。此外，EOA 升级可能会显著影响用户体验和应用开发者，因此必须考虑所有利益相关者的声音。

允许 EOA 以任何方式执行代码极大地扩展了账户的功能，但这种新型的可表达性也带来了实际的风险和可能的盲点。解决这些权衡对于为以太坊用户提供一个无可争议的更好用户体验（UX）至关重要。

以太坊的开放讨论文化使其成为这种创新的绝佳试验场，因为几乎每个设计的每个影响都被领域专家彻底解构。这样的全面考虑有助于减轻来自对手的不当行为风险。

EIP-7702 目前是将 EVM 可编程性引入 EOA 的典型机制，被视为替代 EIP 3074 在 Pectra 升级中的位置。它继承了 3074 机制的开放设计，同时大幅降低了攻击面和风险。它还通过避免 3074 对某些操作码类别的限制，实现了更多功能。

尽管该提案的设计仍在进行一些完善，但它已经获得了开发者的大量支持，尤其是因为它得到了 Vitalik 的支持。

在社区中，有观点认为这种账户抽象方式可能比智能账户更优。这一评论强调，这种方式需要更少的变动，且不如智能账户复杂，同时 EOA 已经得到认可。然而，我们必须牢记以太坊网络各层级未来的量子抗性安全目标。由于 EOA 授权使用基于 ECDSA 的签名方案，当前账户模型核心无法实现这一量子安全性。

因此，EOA 的可编程性应被视为迈向智能账户的一个步骤，而非终点。它为 EOA 提供了更强大的功能，提升了用户和开发者体验，同时与最终的智能账户目标保持兼容。

在我们的下一个报告中，我们将深入探讨 EOA 迁移方案，看看它们在账户抽象路线图中的适配程度，敬请关注！

免责声明：

1. 本文转载自【2077.xyz】，所有版权归原作者【zhev】所有。若对本次转载有异议，请联系Gate Learn 团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。