社区

作者 | 十四君

前言

本文整体分两大模块：

上半段，将从 2015 年起的首个 AA 提案出发，系统整理目前为止的 Eip 提案主要内容，期望由史出发挖掘 AA 历史提案的历程，并综合性评价各方案优缺点。

下半段，着重对比 EIP4337 提出之后面临的市场低迷反馈，再深入分析如今即将被纳入下个版本以太坊升级的 EIP7702，此提案一旦合并，将全方位改变链上应用形态。

EIP-7702 具有划时代的改变，且听十四君细细讲来。

1. 账号抽象的背景

1.1 账号抽象的意义定位

以太坊创始人 vitalik 在 2023 年年底再次更新 ETH 发展路线图，但其中针对账号抽象的设定，并未改过。如今的主流模式也正是从 EIP-4337，步入到下一个阶段 VoluntaryEOA Conversion（自愿转换 EOA 账号）。

在 EIP4337 推出一年多以来（在 2023.3.1 号丹佛的 WalletCon 上，官宣由以太坊基金会开发人员设计实现的 ERC-4337 的核心合约已经通过了 OpenZeppelin 的审计，被认为是正式推出的历史节点）。

始终是只得到用户的广泛认可，但并不被广泛使用，如此矛盾的市场环境下，让 EIP-7702 的进度被大幅提前，乃至已经被确认将在下一次升级被合并其中。

1.2 账号抽象的市场现状

无需多言，直接看数据吧。

经过一年半的发展，EIP4337 在主流链账号的集合下，仅仅有 1200W 的地址数，其中最为让人惊讶的是在以太坊主网上，活跃地址仅仅 6,764 个，或许统计维度有所问题，但至少与 EOA 与 CA 的地址数相差甚广，要知道以太坊主网上独立地址数已经达到 2 亿 7 千万。

可以说在主网上 EIP4337 是毫无实质性发展。

不过，这并不磨灭 AA 的本质价值，因为他从一开始的 EIP4337 的设计就注定了，他面对主网严重的往前兼容性问题上无法做好，所以伴随着各类 L2 层链的普遍嵌入原生 AA，EIP4337 的地址数在 L2 上获得爆发，其中 base 和 polygon 链的 7 月月度活跃用户分别是 100W 和 300W，倒也颇为可观。

所以，并不是 EIP4337 设计错了，他有很多优点，我们一会会系统的总结，如今的现状是源于主网与 L2 之间的差异，他们需要用各自适合的方案。

2. 账号抽象是什么？

账户抽象，听着很费解，但其实本质解决的是产权分离的问题。

EVM 架构（即以太坊虚拟机）中有两种账户，外部账户（EOA）和合约账户（Contract Account），外部账户的所有权和签名权其实上是同一个体单位持有的。持有私钥的人不只拥有这个账户的「所有权」，同时还有权利「签名转移所有资产」。

这是由以太坊账号交易结构决定的。

从下图的结构中可以发现，其实以太坊的标准交易是没有 From 方的，那么我做了一次资金转账，具体消费的是什么地址上的资金？实际是是通过其 VRS 参数（即用户签名）反解析出 From 地址的。

这里涉及到 ECDSA 等非对称加密，单向门限函数等概念，咱们不做展开，总之这里是由密码学来保障安全性，当然这也就造成了如今的产权合并的 EOA 地址窘境。

而 EIP4337 的核心效果，就是在交易字段里增加了 Sender Address 字段，从而能让私钥与被操作的地址分离开。

那为什么产权分离这么重要呢？

因为外部账户（EOA）设计会衍伸出更多的问题：

· 私钥难保护：用户失去私钥（遗失、黑客攻击、密码学上的被破解）意味着地失去所有资产。

· 签名算法少：原生协议在验证交易上只能使用 ECDSA 签名和验签算法。

· 签名权限高：无原生多签（多签只能通过智能合约实现协作），单签即可执行任意操作。

· 交易手续费只能通过 ETH 支付，并不支持批量交易。

· 交易隐私泄露：一对一交易容易分析账户持有者的隐私信息。

上诉的约束让普通用户很难使用以太坊：

首先，使用以太坊上的任何应用，用户都必须持有以太（并承担以太价格波动的风险）。

其次，用户需要处理复杂的费用逻辑，Gas price、Gas limit、事务阻塞（Nonce 顺序）这些概念对用户来说过于复杂。

最后，虽然许多区块链钱包或应用试图通过产品优化提高用户体验，但它们的实际效果甚微。

所以破局之道在于实现账户抽象，将所有权（Owner）和签名权（Signer）解耦（Decoupling），从而才能逐个解决上述问题。

其实历史的方案有很多，最终都会汇聚到两种路线。

3. AA 历史提案脉络梳理

问题的解法看似有很多的 EIP 提案，但归根究底，就是两种核心思路，所以过往每一个没有被通过的 EIP，其考虑的问题也就汇聚成了现在方案的破局之道。

3.1 第一种路线是让 EOA 地址变为 CA 地址

早在 2015 年 11 月 15 日，围绕 EIP-101，Vitalik 就提出以合约作为账户的新结构。将地址改为只有代码和存储空间，改变手续费支持由 ERC20 支付，通过预编译合约将原生代币改为类 ERC20 来存余额（可具备代扣授权等功能），将交易字段精简到只有 to、startgas、data 和 code。

现在看来，简直是大跃进式变革，会大幅改动底层设计，让每个账户地址都拥有自己的 “代码” 逻辑（其实也正是现在 EIP-7702 要做到的效果）。

还能衍生出其他的功能，比如：

a. 让交易使用更多加密算法，可以由各地址内部 Code 来指定验签鉴权方法；

b. 具备抗量子攻击特性，因为代码具备升级特性；

c. 让以太币具备与 ERC20 合约一致的功能特性，核心效果有了代扣授权，从而无需原生币的损耗；

d. 提升账户的自定义空间，兼容社交恢复、sbt 支持、密钥找回等。

没有继续推进的原因也很简单，显然是步伐太大，对于当前交易哈希冲突问题，安全性隐患考虑不周所以一直搁置，但每个优点的理念都成为后续 EIP4337 以及 EIP7702 的核心功能之一。后来还有一系列 EIP 试图完善这种逻辑。

EIP-859：主链账户抽象 — 2018–01–30

试图解决 Code 的部署问题，核心作用是，如果出现了若交易方合约未部署，则使用交易附带 code 参数执行合约钱包部署，其次还提出新的 PAYGAS 操作码，除了支付 gas 外，也成为一笔交易的参数中验证部分与执行部分的分隔符。

虽然当时无疾而终，但是这也成了现在 EIP7702 的核心逻辑之一，EIP7702 的每一笔交易结合特殊的交易结构，可以附带一定的代码，从而在本次交易中让 EOA 地址拥有合约能力。

EIP-7702：设置 EOA 账户代码 2024–05–07

这也是本文后续讨论机制的核心 EIP，由 Vitalik 发表了 EIP-7702 作为 EIP-3074 的替代方案（2024–05–07）。因此 EIP-3074 被弃用，EIP-7702 被确定在即将到来的 ETH Prague/Electra（Pectra）硬分叉中纳入，具体内容咱们在下文展开。

3.2 第二种路线是让 EOA 地址驱动 CA 地址

EIP-3074：增加 AUTH 和 AUTHCALL 操作码 — 2020–10–15

在 EVM 中加入两个新的 OpCodes AUTH 和 AUTHCALL ，让 EOA 能透过这两个 opcode 授权合约代替 EOA 的身份去呼叫其他合约。

结合下图，概括来说一个 EOA 能将一则已签的消息（交易）送至自己信任的合约（称作 Invoker）上，此 Invoker 合约可以利用 AUTH 和 AUTHCALL 操作码来代替这个 EOA 送出这笔交易。

EIP-4337：用交易内存池实现账户抽象 — 2021–09–29

他受到 MEV 的启发进行设计，其核心价值是可以完全避免共识层协议更改。

eip4337 提出新的事务对象 UserOperation，用户将此对象发送到内存池中，由 bundlers 从矿工维度批量打包交付合约执行交易事务，本质上是把底层的交易与帐户运作拉到合约层面执行。

EIP-5189：通过背书人来操作抽象账户 — 2022–06–29

这算是优化了 EIP4337 的逻辑，是面对恶意的 Bundler 通过建立资金罚款背书 endorser 的机制来防止 Dos 阻塞攻击。

3.3 其他用于支持 AA 的提案

EIP-2718：新交易类型的包装信封 — 2020–06–13

这倒是一个已经 Final 的提案，他定义一个新的交易类型，作为未来新增的交易类型的信封。

最终效果是，当引入新的交易类型时， 通过特定编码来区分这是哪一种交易，让其只需有向后兼容性，而无需往前兼容。最常见的例子就是 EIP1559 了，他区分了交易的手续费，使用了新的交易类型编码，又不影响最初的 legacy 的交易类型。

EIP-3607：让 EOA 地址不可部署合约 — 2021–06–10

这是是 AA 路径上的补充方案，用于防止合约部署地址与 EOA 地址冲突的问题。他会控制合约生成方法，让系统不允许将代码部署到已经是 EOA 地址的地址上。这个风险其实很小，毕竟以太坊地址有 160 位长，虽然存在用私钥碰撞出指定合约地址私钥的方法，但以比特币全算力投入估计，也还需要一年的时间。

3.4 如何理解账号抽象发展历程？

首先需要理解转为 CA 后的价值，基本上也就是 EIP-4337 的实际效果，他可以实现。

但是，EIP-4337 的核心缺点是违背人性动机原则。

他看起来是更好了，但是陷入了一种市场发展的死循环，Dapp 很多还不兼容，那用户就不乐意使用 CA 地址，甚至使用 CA 有更高的交易成本（普通转账场景，也会交易费用翻倍），也太依赖于 Dapp 本身的兼容性。

所以在以太坊主网上迄今为止始终没有得到普及。

成本就是用户最重要衡量的标准，必须降低成本。

但是要真正降低 GAS，就必须以太坊本身做软分叉升级，修改 GAS 计算或者修改操作码的 GAS 消耗等模块，然而既然要软分叉，那何不直接考虑 EIP-7702 呢？

4. 全面解析 EIP-7702

4.1 EIP-7702 是什么

它通过新的交易类型来区分，可以允许 EOA 在单笔交易中临时具备智能合约的功能，进而支持业务上进行批量交易、无 Gas 交易和自定义权限管理等，且无需引入新的 EVM opCode（影响往前兼容性）。

他可以让用户在不部署智能合约的情况下，就可以获得大部分 AA 的能力，甚至可以提供第三方代用户发起交易的能力，且不需要用户提供私钥，只需签名授权的信息。

4.2 数据结构

他定义了新的交易类型 0x04，该交易类型的 TransactionPayload 是下列内容的 RLP 编码序列化结果。

重要的是其中新增了 authorization_list 对象，存储签名者希望在其 EOA 中执行的代码，用户签署交易的同时也签署要执行的合约代码，他作为二维列表存在，说明可以批量存放多个操作信息，执行批量操作。

4.3 交易生命周期

4.3.1 验证阶段

在执行交易的开始阶段，对于每个 authorization_list 的 [chain_id, address, nonce, y_parity, r, s] 元组：

a. 从签名 r、s 中采用 ecrecover 恢复出签名者地址（注意这是以太坊本身的机制，所以该 EIP 没有改变签名算法）。authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]（与之前解签名得出 from 地址类似，这里得出的是针对这个 list 的局部签名地址）

b. 验证链 ID（防分叉链重放）。

c. 验证 authority 签名者的代码是否为空或已经委托（验证交易是否属于有效 7702 交易，后续会通过 delegation 机制去代理执行交易）。

d. 验证 authority 签名者的 nonce（防 authority 的签名重放）。

e. 设置 authority 签名者的代码为 0xef0100 || address（用于绕过 EIP3607 防碰撞策略的）

f. 增加 authority 签名者的 nonce（防局部签名重放）。

g. 将 authority 签名者账户添加到已访问地址列表中（转热地址，降低查询存储的 gas 费）

4.3.2 执行操作阶段

要执行的合约代码以及操作指令在哪里？

“新” 版本仅更改了代码部署方面的行为。

它不再将帐户代码设置为 contract_code，而是从 authorization_list 中检索代码 address 并将该代码设置为帐户代码。

所以，当需要执行授权代码时，从 authorization_list 的 address 字段指定的地址加载代码，并在签名者账户的上下文中执行。

这意味着用户的合约代码实际上是存储在链上的某个特定地址，而不是直接包含在交易中。

而操作指令和相关参数则存储在交易负载的 data 字段中。

4.4 EIP-7702 有什么价值？

他对于 Web3 钱包的全链路都会有变化，用户体验也因此巨变，因为 EOA 发起的普通交易也可以类似合约执行多种逻辑，比如批量 transfer。对于 CeFi 场景会影响交易鉴别，也影响冲提归集手续费

由于其出现，打破了很多曾经的定势，比如：

a. 打破了账户余额只能因源自该账户的交易而减少的不变量。

b. 打破了交易执行开始后 EOA nonce 增加 1 的不变量（可能同时增加多个）。

c. 打破了 tx.origin 和 msg.sender 两个比对的防护逻辑，很多过往的合约有风险了。

d. 打破了 EOA 本身无法发出事件的现状，对部分链上事件识别监听可能需要注意。

e. 打破了 EOA 地址接受 ERC20、721、含 eth 等资产必然成功的现状（因为回调机制，可能失败）

4.5 对比 EIP-7702 和 EIP-4337

4.5.1 EIP-7702 的优势

· gas 更低，因为无需经过 entrypoint 模块，减少链上操作。

· 用户迁移成本更低，无需提前部署链上合约做为主体

· 与 Eip4337 相比，同样会有代码委托执行，也同样会有两种方式：

完全委托（Full Delegation）

完全委托是指将某个操作的全部权限委托给一个特定地址。例如，用户可以将所有 ERC-20 代币的管理权限委托给一个智能合约地址，从而使得这个智能合约可以代表用户执行所有相关操作。

受保护的委托（Protected Delegation）

受保护的委托是指在委托的过程中增加一些限制和保护措施，确保委托操作的安全性和可控性。

例如，用户可以仅将部分 ERC-20 代币的管理权限委托给一个智能合约，或者设置一些限制条件（如每天最多花费总余额的 1%）。

4.5.2 EIP-7702 的缺点

他的核心缺点是属于软分叉升级，需要大家共识推动，并且改动巨大，对链上生态影响太广，十四君初步评估下来，就有以下挑战，但是挑战也就是市场的机会：

自由度极高，难以被审计，用户会更需求靠谱的钱包承担安全防护的保护。

对原架构变化过大，虽然用不同交易类型区分，但是很多基建尤其链上不可改合约都无法直接适配。

对 EOA 地址提供了合约能力，且对应的存储空间可以留存。

单独交易的成本稍微提高，因为会大量增加 Calldata 的部分，估算调用的总成本将是 16（gas） * 15（字节） = 240（gas）calldata 成本，加上 EIP-3860 的成本 2 * 15 = 30，再加上大约 的运行时成本 150。因此，仅仅准备账户哪怕什么都不做，就要增加 500 的 Gas 了。

“如果接收者签署了没有接收功能的代码，发送者在尝试发送资产时可能会面临 DoS。” 见案例。这个问题其实是 EOA A 签署了它不应该签署的东西 — — 一个设置了错误实现（没有 receive()）的可重放文件。

链上 冲提逻辑可能不一致，比如当转移 ERC-20 代币时，如果接收方账户有代码，则代币合约将调用 onERC20Received 接收方账户。如果 onERC20Received 还原或返回错误的值，则令牌传输将还原。

另外如果 EOA 可以发出事件，会不会有什么问题？一些基础设施可能需要注意。

这些还只是十四君基于目前 EIP7702 提案内容，以及对应的官方论坛讨论总结出的一些缺点，最终还需要基于最终的实现代码才能分析完全。

参考如下：

5. 全文总结

本文看似篇幅宏大，实际上文字内容只有 6k 余字，中间涉及的很多往期 EIP 解读，都在文中链接可以拓展，我就不进而追溯了。

目前看，账户抽象，确实只能放在第六模块，即修复一切，也即最后在推行，如今大幅加快 EIP7702 的进度，更多带来的还是对系统安全性的挑战，可以预料到，最终他会实现，毕竟以太坊合并，修改共识算法这样的颠覆性事件都可以发生，又谈何区区新的交易类型呢。

但是这一次颠覆的内容太多了，打破多个链上不可能的潜规则，也打破了大多数 Dapp 的应用逻辑，但是他死死的占住了最核心的一点，就是用户的成本更低了！对比 EIP4337 近乎翻倍的交易成本而言。

用户本身还是 EOA 地址，只是在需要的时候才去驱动和使用 CA 逻辑，所以持有成本低了。无需先转换出链上 CA 身份再做操作，等于用户无需注册了。

用户可以轻松用 EOA 做到多交易并行，比如授权代扣和执行代扣两种合一，这样对用户交易成本本身就低了，而对于 Dapp 而言，尤其是需要做链上企业级管理的项目方，比如交易所等更是颠覆性的优化，批量归集一旦原生态实现，基本交易所成本可以瞬间减少一半以上，最终也可以惠及用户。

所以，虽然他改变了很多，但占据成本这个维度，就值得全部 Dapp 去研究和适配，因为这一次，用户必然站在了 EIP7702 的一边。

根据央行等部门发布“关于进一步防范和处置虚拟货币交易炒作风险的通知”，本文内容仅用于信息分享，不对任何经营与投资行为进行推广与背书，请读者严格遵守所在地区法律法规，不参与任何非法金融行为。不为任何虚拟货币、数字藏品相关的发行、交易与融资等提供交易入口、指引、发行渠道引导等。吴说内容未经许可，禁止进行转载、复制等，违者将追究法律责任。