以太坊治理战争：EIP3074、ERC4337与EIP7702

文章转载来源： GCC Research

作者：shew

概述

在 Pectra 升级中，出现了最为复杂的治理争端问题。当 EIP3074 被纳入 Pectra 升级后，造成了巨大的争论，特别是来自 ERC4337 的团队反对。

EIP3074 陷入了困境，治理流程无法继续进行。直到 Vitalik 提出 EIP7702 结束了 ERC4337 团队对于 EIP3074 的质疑。

GCC Research 发现对于 Pectra 升级中 EIP3074 和 ERC7702 的治理问题在中文世界少有讨论。但该治理问题也反映了以太坊治理的深层问题，即在 code is law 的前提下，谁可以控制 code 的具体内容。EIP3074 和 ERC7702 的治理问题可以带给我们一个很好的视角去观察以太坊内部的真实治理流程。

本文的最终结论是转述自 ZeroDev 发表的评论文章，该文章指出以太坊治理系统是 VVRC 模型，任何一个提案的纳入都需要首先符合以太坊价值观 (Value)，然后该提案应该反映在 Vitalik 设计的愿景 (Vision) 中，最后提案应该反映到路线图 (Roadmap) 中，最后核心开发者讨论后将其纳入客户端 (Client) 实现中。

GCC Research 在上一篇文章中介绍的 EIP2537 只是在 Client 层级出现了实现问题导致最终延迟加入硬分叉，而 EIP3074 则是因为 Vision 和 Roadmap 问题导致最终没有被纳入硬分叉，而以太坊核心开发者直接选择了 Vitalik 编写的 EIP7702 作为最终的账户抽象提案。

提案内容概述

在介绍具体的治理流程前，我们首先需要简单介绍一下本文涉及到 EIP3074、EIP7702 和 ERC4337 的具体内容。

EIP3074 是一个执行层提案，执行该提案需要节点软件升级。EIP3074 的核心目的是实现 gas sponsoring 和批量交易的功能。所谓的 gas sponsoring 是指用户可以使用任意代币缴纳 gas 费用，或者用户可以在线下缴纳 gas 费用。但需要注意的，相比于其他账户抽象提案允许更改签名校验算法，EIP3074 并不允许用户使用 secp256k1 以外的任何签名算法。换言之，EIP3074 并不是一个满足所有账户抽象功能的提案。这也是 EIP3074 备受诟病的一点。

为了实现预期目标，EIP3074 引入了两个操作码，分别是 AUTH 和 AUTHCALL。其中 AUTH 操作码可以通过校验签名，当签名校验通过后，该操作码就会配置当前 EVM 上下文中的 authorized 为签名人的地址。当配置上下文中的 authorized 后，AUTHCALL 可以使用 authorized 的地址作为调用交易的 msg.sender 发起交易。从某种程度上来说，用户可以通过签名将自己的账户在一笔交易中委托给一个智能合约使用。我们一般称这个被用户委托的智能合约为 invoker 合约。

那用户的具体签名内容是什么？用户需要签名如下内容:

上述内容中的 invoker address 是指用户希望委托的 invoker 合约地址，EVM 会校验用户签名内容与真正校验签名的合约是否一致，避免用户的 AUTH 签名内容被其他合约使用。

而 nonce 是一个防止交易重放的标识。但是需要注意的时，AUTH 操作码会校验签名中的 nonce 与当前签名的 EOA 的 nonce 是否一致，理论上只要用户不使用 EOA 账户发起交易增加 nonce 数值，那么用户发出的 AUTH 签名可以一直被 invoker 合约使用。这是一个巨大的安全漏洞，意味着使用 EIP3074 的用户必须信任获得签名的中继服务商。假如获得用户签名的中继服务商是恶意的，该服务商可能在某一个时刻重放用户的 AUTH 签名盗取用户资产。

另一个具有安全问题的是 commit 字段。commit 字段用于保证某些操作，用户可以在 commit 内精细化控制自己的签名权限，比如在 commit 内写入一些内容避免自己的签名内容被用于 ETH 转账。在 EIP3074 文档 内，提案人给出了一系列的利用 commit 字段的例子。但是问题是 commit 的作用完全依靠智能合约定义，本质是一个可选内容。不同的智能合约对 commit 中内容的解析可能完全不一致，甚至可能某些合约完全不读取 commit 中的内容。假如用户希望安全使用 EIP3074 必须自己简单审查智能合约。

最后，我们介绍一个 EIP3074 对目前以太坊交易内存池的影响。引入 EIP3074 后可能会出现一种对于内存池的攻击方法，黑客可以使用大量的账户发起交易，然后在交易即将被打包时，使用 EIP3074 交易一次性抽空这些账户内的 ETH，这会导致之前发起的交易全部失败。这种攻击方式会对执行层节点造成相当大的影响，本质上就是一种 DoS 攻击。但需要注意的，用于替代 EIP3074 的 EIP7702 也出现了这种问题，但 EIP7702 引入了一些限制避免此问题出现，我们会在后文讨论。

除了上文介绍的 EIP3074 本身存在问题，所以 ERC4337 的作者 Yova 在 Implications of EIP-3074 inclusion 一文中介绍了更多的反对意见。简单来说，这些意见主要包括:

1. 中心化风险。由于 AUTH 签名的特殊属性，用户必须完全信任 EIP3074 的中继服务商和底层基础设施。同时目前 ERC4337 等账户抽象协议构建的基础设施完全不兼容 EIP3074
2. 用户的安全性。正如上文所述，EIP3074 没有统一设计的权限控制方法，而且签名 nonce 设计也存在安全隐患，很有可能导致严重安全问题的出现
3. 不完整的账户抽象功能。相比于其他账户抽象提案，EIP3074 并不完整，无法实现比如更换用户签名算法等功能
4. 用户体验存在问题。当用户需要将自己的账户委托给智能合约时，用户需要进行一次 AUTH 签名，然后将包含 AUTH 签名的调用发布到链上。用户需要进行两次签名。

EIP7702 是由 Vitalik 提出的一个用于替换 EIP3074 的提案。该提案没有引入新的 EVM 操作码，而是引入了一个新的交易类型，该交易类型被称为 SET_CODE_TX_TYPE。一旦用户发起 EIP7702 类型的交易，用户可以将自己的 EOA 在保留 EOA 基础功能的前提下增加智能合约的功能。简单来说，用户既可以继续使用 MetaMask 等钱包发起交易，也可以由其他用户以智能合约的形式调用 EOA 地址。

我们以一个简单的批量交易的例子介绍 EIP7702 的功能。用户可以使用 EIP7702 将自己的 EOA 地址委托给某一个可以执行批量调用的智能合约，然后用户可以直接以智能合约的方式调用自己的 EOA 地址发起批量交易。

从技术实现上来讲，EIP7702 引入的交易类型的相比于传统的交易增加了 authorization_list 列表，该列表内具体内容为 [[chain_id, address, nonce, y_parity, r, s], ...]。其中 address 是用户希望委托的智能合约地址，而 nonce 是用户当前的 nonce 数值。剩下的 y_parity、r 和 s 都是用户的签名结果。在具体执行过程中，我们会首先遍历 authorization_list 内的每一项进行处理，处理的方法是通过 y_parity 等签名参数恢复出 EOA 地址，然后将 EOA 地址指向地址为 address 的智能合约。之后 EOA 地址就可以接受调用发挥合约的功能。

EIP7702 的优点非常明显，其中最核心的优点是 EIP7702 本质上就是允许 EOA 拥有智能合约的功能。这与 ERC4337 等账户抽象的基本规则是一致的，这意味着 EIP7702 可以利用目前账户抽象领域内的所有探索和复用已有基础设施，比如 EIP7702 可以直接使用 ERC4337 的基础设施。目前 ERC4337 已经推出了支持 EIP7702 调用的 EntryPoint v0.8。从复用已有的基础设施角度来看，EIP7702 与 ERC4337 具有同等的去中戏化程度。

当然，EIP7702 实际上也没有完全修复 EIP3074 中出现的问题。大部分 EIP3074 中存在的问题依旧存在。EIP7702 要求账户合约拥有安全实现，而协议自身不对任何安全进行保证。在 EIP7702 提出的早期，存在某些开发者提出将签名 nonce 标准化以避免可能的重放攻击，但是 EIP7702 最后也没有接受这些建议。所以假如用户希望安全使用 EIP7702，那么用户就需要自己审查合约安全性。

同时 EIP7702 也会为执行层带来一系列问题。在上文我们介绍过一种可能的利用 EIP3074 对执行层内存池进行 DoS 攻击的一种方法。这种方法在 EIP7702 也是有效的。所以 EIP7702 建议所有使用 EIP7702 的 EOA 地址只可以在内存池内存在一笔待处理交易，避免大规模 DoS 攻击出现。

综上所述，EIP3074 最大的问题是 EIP3074 没有实现完整的账户抽象功能，而 EIP7702 实现了完整的账户抽象的功能。而定义“完整的账户抽象”包含哪些内容的正是 ERC4337 的作者。读到这里，读者应该就可以理解为什么 EIP3074 被 ERC4337 团队反对，最后被 EIP7702 替代。我们会在后文介绍整体治理和讨论的全部流程。

EIP3074 和 EIP7702 的治理流程

EIP3074 在以太坊核心开发者会议内提及的非常早。在 2021 年 4 月 2 日的 Meeting #109 内，以太坊核心开发者就对 EIP3074 进行了简单的讨论。讨论结果非常简单:

1. Alexey 提出 EIP3074 签名内容存在安全风险，可能对用户造成严重的安全损失，建议 EIP3074 进一步规范化 AUTH 签名的具体内容，该提议得到了 Martin 的支持
2. James 提出 EIP3074 可能带来潜在的执行层漏洞，比如 DoS 攻击等，建议 EIP3074 给出书面的威胁分析
3. Alexey 和 Martin 抱怨 EIP3074 文档质量一般，花费了大量时间阅读和理解
4. Martin 认为 EIP3074 的核心是与应用，特别是钱包开发者的合作和实现，EIP3074 的作者表示已经和应用开发者进行了一系列交流

比较有趣的是，Vitalik 在这次会议中认为无论如何，以太坊需要一种为 EOA 设计的一笔交易产生多次调用的技术方案。虽然 EIP3074 存在可能的安全问题，但 EIP3074 给出了一种可能的技术方案，开发者需要在 EIP3074 的基础上前进。

显然，由于 EIP3074 存在安全问题，这次会议并没有将 EIP3074 纳入 London 升级。

在 2021 年 6 月 11 日的 Meeting #115 内，EIP3074 开发者提交了安全审计方面的报告，会议主要讨论了 EIP3074 的安全问题。一个简单的结论是 EIP3074 invoker 合约在系统内是十分重要的，所以是否需要对 invoker 合约进行管理是一个问题。EIP3074 开发者希望对 invoker 合约进行形式化证明，以此增加安全性。

当然，还有部分讨论关于有一些合约使用 msg.sender == tx.origin 进行了调用地址是否是 EOA 判断，当 EIP3074 被引入了，这些判断都会失效，但结论是这部分判断失效不会产生严重的安全问题。简而言之，该次会议主要是 EIP3074 提出者向核心开发者介绍 3074 的安全审计结果。会议最终的结论是 3074 还需要考虑 invoker 合约问题，建议不要在 London 硬分叉内加入。

在 2021 年 6 月 25 日的 Meeting #116 内，ERC4337 的核心作者 Yova 提交了 A case for a simpler alternative to EIP 3074 的材料，该材料指出 EIP3074 存在较多安全问题，建议修改其中部分内容，比如限制签名内的 commit 字段内容，要求 commit 字段为 {nonce,to,gas,calldata,value,chainid} 形式。使用此签名模式后，EIP3074 仅可以用于执行某些特定交易以保证交易的安全。

此处会议中 EIP3074 的作者对 Yova 提交的材料进行了回应:

1. 希望将 invoker 合约地址纳入 EIP 规范，然后由以太坊核心开发者编写一个安全的 invoker 合约避免安全问题
2. 关于签名中 commit 的内容，EIP3074 开发者认为这完全是用户和钱包软件方面的问题，并不需要在 EIP 内进行规范

Vitalik 在此次会议中提出以下三点内容:

1. EIP3074 仍使用了传统的 secp256k1 签名方案无法实现抗量子特性。
2. EIP3074 没有未来兼容性，使用 EIP3074 也无法使得一个 EOA 进化为智能合约账户
3. EIP3074 生命周期有限。3074 引入了 AUTH 和 AUTHCALL 两个预汇编代码，但是按照账户抽象的路线图，未来以太坊内所有的钱包都可能是智能合约钱包，EIP3074 的预汇编代码在未来会被废弃

在 2022 年 2 月 4 日的 Meeting #131 内，开发者讨论 ShangHai 升级内应该包含的 EIP 类型。EIP3074 被纳入讨论范围，但开发者只是简单同步了 EIP3074 的开发动态。值得注意的，在会议开始前，nethermind 编写了 Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337 一文，文章内没有包含对 EIP3074 的反对意见。

在 2023 年 8 月 3 日的 Meeting #167 内，核心开发者在讨论另一个 EIP5806 时提及了 EIP3074。EIP5806 是一个允许 EOA 在交易过程中使用 delegate call 的方式调用外界合约。该方案在某种程度上类似 EIP7702。但核心开发者对此方案的安全性也提出了质疑，Ansgar 指出过去 EIP3074 因为可能存在的安全问题一直无法被纳入硬分叉，而 EIP5806 是一个更加激进的方案。

在 2024 年 2 月 29 日的 Meeting #182 内开发者详细讨论了 EIP3074 的是否应该被纳入 Pectra 升级。Vitalik 提出任何账户抽象标准都需要具有以下三种功能:

1. 密钥轮换
2. 密钥弃用
3. 可兼容抗量子签名

Vitalik 对 指出 EIP5806 可能是一个优于 EIP3074 的选择。Andrew 认为 EIP3074 相比于 EIP5806 更加通用，建议使用 EIP3074。Vitalik 对 Andrew 进行了反驳，Vitalik 认为未来所有的钱包可能都是智能合约钱包，一旦此情况发生，EIP3074 引入的预汇编操作码就会失效。Yoav 作为 ERC4337 的作者在此次会议中进行了篇幅较长的发言，其发言内容主要包括:

1. EIP3074 可能导致对以太坊内存池的 DoS 攻击，而 ERC4337 对这部分进行大量研究给出了一些规则避免攻击
2. EIP3074 在用户发起批量交易时需要签名两次，这是不合理的
3. EIP3074 要求使用中心化中继器

Yova 更加倾向于使用 EIP5806 作为账户抽象方案。

在 2024 年 3 月 14 日的 Meeting #183 会议内部，核心开发者邀请 MetaMask 的 Dan Finlay 讨论关于钱包对 EIP3074 的看法。Dan 对 EIP3074 持赞成态度，同时指出 MetaMask 也会为 EIP3074 的测试提供支持。MetaMask 认为 EIP3074 在功能上可以使得 EOA 享受账户抽象的全部功能。在安全上，EIP3074 为钱包服务商提供了一种方案，即冷热密钥分离。钱包服务商可以持有 EOA 的 EIP3074 签名发起交易，用户在正常交易中都可以使用热私钥，但冷私钥可以保存在用户的硬件钱包内，当发现紧急情况时，用户可以使用冷钱包内的冷私钥发起交易撤销 EIP3074 的签名。这种冷热私钥分离的方案为钱包提供商带来了灵活性。

Vitalik 指出在 EIP3074 内，钱包设计者必须设计严格的授权逻辑，避免用户的 EIP3074 签名被滥用。有趣的是，在讨论 MetaMask 增加 EIP3074 功能支持时，Vitalik 指出可以使用 L2 作为过渡方案，即任何新的执行层修改应该在 L2 内进行率先实践，因为 L2 资金体量有限，即使发生严重问题也会造成严重损失。

Dror Tiros 在讨论中指出确保 EIP3074 安全的最好方式是以太坊官方直接给定 invoker 合约。但 Dan Finlay 反对官方给出合约的意见，Dan 认为 invoker 合约应该完全由用户决定，市场最终会选择出最安全的 invoker 合约。

Ansgar 仍坚持 EIP3074 一次签名应该只对应一笔交易，钱包服务商不应该复用用户签名发起交易，但 Dan Finlay 也表达了反对意见。Dan Finlay 认为 EIP3074 应该由冷钱包签名，然后钱包服务商可以复用该签名直接为用户发起交易，假如每次都要求用户重新签名，可能导致冷私钥被多次使用。这与冷热私钥分离的思想不符。

在此次会议中，核心开发者讨论了另一个重要的话题是包含列表。包含列表是增加以太坊抗审查属性的一种手段。简单来说，包含列表允许一些交易被承诺直接包含在下一个区块内。但核心开发者指出 EIP3074 与包含列表是抵触的。

在 2024 年 4 月 11 日的 Meeting #185 会议内部大部分的客户端实现都同意 EIP3074 加入 Pectra 硬分叉中，但 Geth 表示反对，原因是 EIP3074 可能导致 Verkle 树方面的问题。Danno 仍表示反对，因为 EIP3074 可能出现签名复用的情况。Yoav 也表示反对，Yoav 给出了一种使用 EIP3074 和 Blob 交易对内存池进行攻击的方案。简单来说，攻击者可以发起大量的 Blob 交易，这些 Blob 交易都包含大量的数据，然后使用 EIP3074 使这些 Blob 交易全部失效。

简而言之，在此次会议中，所有客户端开发者都同意 EIP3074 被纳入最终的升级。

在 2024 年 5 月 9 日的 Meeting #187 内，核心开发者第一次讨论 EIP7702 替代 EIP3074 的问题。而 EIP7702 是在 Vitalik 在核心开发者会议 开始前前 90 分钟 内完成的。在会议中，核心开发者认可 EIP7702 是一种更加优于 EIP3074 的标准。此次会议没有出现对 EIP7702 的反对声音，只是存在部分研究员认为 EIP7702 也存在类似 EIP3074 的不可撤销属性，可能导致资金安全问题。

在 2024 年 5 月 23 日的 Meeting #188 会议内核心开发讨论了 EIP7702 替换 EIP3074 的可能性。此次会议的最终结论是使用 EIP7702 替换掉 EIP3074 作为 Pectra 硬分叉中的账户抽象标准。Vitalik 指出 EIP7702 也具有一些与 EIP3074 一致的不可撤销性，这些属性在讨论 EIP3074 时已经得到了大量讨论。比较有趣的是，会议中存在大量 ERC4337 的代表参与发言。

事实上，EIP3074 被 EIP7702 替换的讨论在 188 次核心开发者会议之前就已经被广泛讨论，当时的讨论结果就是 3074 会被替换，所以在核心开发者会议中并没有大量的争执。

路线图与裁决

账户抽象的核心基础设施 Zerodev 在得知 EIP3074 会被替换后，发表了一篇有趣的文章，该文章标题为 Reflections on Ethereum Governance Following the 3074 Saga，这篇文章的结论是 EIP7702 是一个好的提案，该提案可以使得所有用户收益。但 EIP7702 替换 EIP3074 的治理流程不是最佳的，原因包括:

1. EIP3074 经过了漫长的讨论流程，在上文中我们已经介绍了 EIP3074 在核心开发者会议中的多次讨论
2. EIP3074 被确定纳入 Pectra 升级后收到了 ERC4337 社区的大量反对。当然，在上文中，我们已经指出 ERC4337 的核心开发者 yova 曾多次在核心开发者会议中表达自己对 EIP3074 的反对

Zerodev 认为最好的治理路径应该是在 EIP3074 过去漫长的核心开发者讨论过程中，ERC4337 社区应该广泛参与并表达自己的意见。

EIP3074 开发者认为 ERC4337 应该对治理失败负责。因为 EIP3074 在过去几年内积极参与治理，并多次和 ERC4337 核心开发者 yova 进行了交流。

而 ERC4337 社区则认为 EIP3074 应该对治理失败负主要责任。ERC4337 社区成员认为 Yova 作为 ERC4337 的核心开发者在多次核心开发者会议中对 EIP3074 表达对反对意见，但核心开发者似乎并没有听取意见。ERC4337 中大部分社区成员没有关注 EIP3074 的治理动态，大部成员都认为 EIP3074 是一个死掉的标准。ERC4337 社区也认为核心开发者没有积极与 ERC4337 社区积极沟通。

EIP3074 和 ERC4337 都认为自己进行了正确的治理工作，而对方应该对治理失败负主要责任。显然，在此次治理过程中存在一个更加深层的原因在发挥作用。

简单来说，这个更加深层的原因其实是以太坊的路线图。以太坊路线图具有高于核心开发者会议的权力。账户抽象的路线图则是以 ERC4337 为核心的。EIP7702 完全兼容 ERC4337 标准，但是 EIP3074 没有充分兼容 ERC4337 标准。所以从以太坊路线图角度来看，EIP3074 被替换是一定会发生的。

当然，以太坊路线图都是 Vitalik 个人对以太坊未来愿景的展示。以太坊在治理过程中一旦发生严重的争论，那么作为路线图定义者 Vitalik 拥有最终的裁决权。而正是 Vitalik 的裁决使得 EIP3074 被替换。

以太坊的治理模式是 values ⇒ vision ⇒ roadmaps ⇒ clients 模型，或者简称为 VVRC 模型。其治理流程如下:

1. values 价值观，特别是社区的价值观，以太坊社区的价值观包括去中心化、抗审查等
2. vision 愿景，实际上就是 Vitalik 个人对以太坊未来的思考
3. roadmaps 路线图，研究员在愿景的基础上给出一些技术细节上的考虑给出较为完整的实现路线图
4. clients 客户端实现，客户端的核心开发者利用核心开发者会议等工具讨论路线图，并将路线图内的需求实现

上述流程才是以太坊真正的治理流程。我们可以看到 Vitalik 个人愿景位于以太坊治理模型中的底层部分，所以一旦客户端实现内出现严重的争论，Vitalik 的个人意见将进行最终裁决。

参考资料

ZeroDev Introduction

null

https://docs.zerodev.app/blog/3074-governance

ZeroDev Introduction

null

https://docs.zerodev.app/blog/4337-and-3074-disagreements

Notes on the Account Abstraction roadmap - HackMD

# Notes on the Account Abstraction roadmap *Special thanks to Vitalik and the AA team for feedback

https://notes.ethereum.org/@yoav/AA-roadmap-May-2024