深入解读以太坊账户抽象赛道的过去与未来

前言

本文分为两大部分:

第一部分从2015年的首个AA提案出发,系统梳理了目前为止的主要EIP提案内容,探讨AA历史提案的发展历程,并对各方案进行综合评价。

第二部分重点对比EIP4337推出后面临的市场反应,以及深入分析即将纳入以太坊下一版本升级的EIP7702。这一提案一旦合并,将彻底改变链上应用形态。

EIP-7702具有划时代意义,让我们一起来深入了解。

1. 账户抽象的背景

1.1 账户抽象的意义定位

以太坊创始人Vitalik在2023年底再次更新ETH发展路线图,但对账户抽象的定位并未改变。当前主流模式正从EIP-4337过渡到下一阶段的"自愿转换EOA账户"。

1.2 账户抽象的市场现状

经过一年半的发展,EIP4337在主流链上的总地址数仅1200万,其中以太坊主网上的活跃地址仅6,764个,与EOA和CA地址数相差甚远。以太坊主网独立地址数已达2.7亿,可以说EIP4337在主网上发展缓慢。

不过这并不影响AA的本质价值。EIP4337的设计注定了其在主网上难以很好地向前兼容。随着各类L2链普遍嵌入原生AA,EIP4337的地址数在L2上获得爆发,如Base和Polygon链的7月月活分别达到100万和300万,表现不俗。

因此,EIP4337的设计并非错误,它有诸多优点。当前现状源于主网与L2之间的差异,它们需要各自适合的方案。

2. 什么是账户抽象?

账户抽象本质上是解决产权分离的问题。

EVM架构中有两种账户类型:外部账户(EOA)和合约账户(CA)。在外部账户中,所有权和签名权由同一实体持有。拥有私钥的人不仅拥有账户"所有权",还有权"签名转移所有资产"。

这是由以太坊账户交易结构决定的。从交易结构可以看出,标准交易实际上没有From字段。资金转账时,具体消费的地址是通过VRS参数(即用户签名)反向解析得出的。

而EIP4337的核心效果,就是在交易字段中增加了Sender Address,从而实现私钥与被操作地址的分离。

产权分离如此重要的原因在于,外部账户(EOA)设计会衍生出诸多问题:

1. 私钥难以保护:丢失私钥意味着失去所有资产。

2. 签名算法单一:原生协议验证交易只能使用ECDSA算法。

3. 签名权限过高:无原生多签功能,单签即可执行任意操作。

4. 交易手续费只能用ETH支付,不支持批量交易。

5. 交易隐私容易泄露:一对一交易易分析账户持有者信息。

这些限制让普通用户难以使用以太坊:

首先,用户必须持有以太币并承担价格波动风险。

其次,用户需要处理复杂的费用逻辑,如Gas price、Gas limit、交易阻塞等概念。

最后,区块链钱包或应用试图通过产品优化提升用户体验,但效果有限。

因此,解决方案在于实现账户抽象,将所有权(Owner)和签名权(Signer)解耦,从而逐步解决上述问题。

历史上有多种方案,最终归结为两条路线。

3. AA历史提案脉络梳理

问题的解决方案看似有很多EIP提案,但归根结底就是两种核心思路。每个未通过的EIP考虑的问题,都汇聚成了现有方案的突破点。

3.1 第一种路线:将EOA地址变为CA地址

早在2015年11月,Vitalik就在EIP-101中提出以合约作为账户的新结构。将地址改为只有代码和存储空间,支持ERC20支付手续费,通过预编译合约将原生代币改为类ERC20存储余额,将交易字段精简为to、startgas、data和code。

这一方案可谓大跃进式变革,会大幅改动底层设计,让每个账户地址都拥有自己的"代码"逻辑(正是EIP-7702要实现的效果)。

它还能衍生出其他功能,如:

1. 让交易使用更多加密算法,由各地址内部Code指定验签鉴权方法。

2. 具备抗量子攻击特性,因为代码可升级。

3. 让以太币具备与ERC20合约一致的功能,如代扣授权。

4. 提升账户的自定义空间,兼容社交恢复、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-3074的替代方案。EIP-3074被弃用,EIP-7702将在即将到来的ETH Prague/Electra(Pectra)硬分叉中纳入。

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

EIP-3074:增加AUTH和AUTHCALL操作码(2020-10-15)

在EVM中加入两个新的OpCode: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逻辑的优化,通过建立资金罚款背书endorser机制来防止恶意Bundler的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的实际效果:

1. 支持批量交易
2. 支持社交恢复
3. 支持自定义签名验证
4. 无需原生代币支付手续费
5. 更细粒度的权限管理
6. 可升级性

但是,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编码序列化结果:

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])

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

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

4.3 交易生命周期

4.3.1 验证阶段

交易执行开始时,对每个authorization_list的[chain_id, address, nonce, y_parity, r, s]元组:

1. 从签名r、s中用ecrecover恢复签名者地址。
2. 验证链ID(防分叉链重放)。
3. 验证authority签名者的代码是否为空或已委托。
4. 验证authority签名者的nonce(防authority签名重放)。
5. 设置authority签名者的代码为0xef0100 || address(绕过EIP3607防碰撞策略)。
6. 增加authority签名者的nonce(防局部签名重放)。
7. 将authority签名者账户添加到已访问地址列表(转热地址,降低查询存储gas费)。

4.3.2 执行操作阶段

"新"版本仅更改了代码部署行为。

不再将account_code设为contract_code,而是从authorization_list中检索address指定的代码并设为account_code。

执行授权代码时,从authorization_list的address字段指定地址加载代码,在签名者账户上下文中执行。

这意味着用户合约代码实际存储在链上特定地址,而非直接包含在交