深度剖析以太坊账户抽象的历史演进与未来展望

引言

本文将从两个主要方面探讨以太坊账户抽象(AA)的发展历程:

首先,我们将追溯自2015年首个AA提案以来的历史脉络,系统梳理迄今为止的各项EIP提案的主要内容,深入挖掘AA提案的演进过程,并对各方案的优劣进行全面评估。

其次,我们将重点分析EIP4337推出后市场反应低迷的原因,并深入探讨即将纳入以太坊未来版本升级的EIP7702。这一提案一旦合并,将从根本上改变链上应用的形态。

EIP-7702堪称一项划时代的变革,让我们一起深入探讨其中的奥秘。

1. 账户抽象的背景

1.1 账户抽象的意义定位

以太坊创始人近期再次更新了ETH发展路线图,但其中关于账户抽象的设定并未改变。当前主流模式正从EIP-4337,过渡到下一阶段的"自愿转换EOA账户"。

尽管EIP4337推出已逾一年,但市场反应却相当矛盾 - 用户普遍认可其价值,但实际使用率却不高。在这种情况下,EIP-7702的进度大幅提前,并已确定将在下次升级中合并。

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)和合约账户(Contract Account)。在EOA中,账户的所有权和签名权由同一实体持有。拥有私钥的人不仅拥有账户的"所有权",还有权"签名转移所有资产"。

这一特性由以太坊账户交易结构决定。以太坊的标准交易结构中实际上并没有From字段。交易发起方的地址是通过VRS参数(即用户签名)反向解析得出的。

这种设计虽然通过密码学保证了安全性,但也导致了当前EOA地址产权合并的困境。

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

产权分离如此重要的原因在于,EOA设计衍生出诸多问题:

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

2. 签名算法单一:原生协议仅支持ECDSA签名和验签算法。

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

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

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

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

首先,用户必须持有以太币(并承担价格波动风险)才能使用以太坊上的应用。

其次,用户需要处理复杂的费用逻辑,如Gas price、Gas limit、交易阻塞(Nonce顺序)等概念对用户而言过于复杂。

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

因此,突破困境的关键在于实现账户抽象,将所有权(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中添加两个新的操作码AUTH和AUTHCALL,使EOA能够通过这两个操作码授权合约代替EOA身份调用其他合约。

简而言之,EOA可以将一个已签名的消息(交易)发送到自己信任的合约(称为Invoker)上,该Invoker合约可以利用AUTH和AUTHCALL操作码代替这个EOA发送交易。

EIP-4337:用交易内存池实现账户抽象(2021-09-29)

这一提案受到MEV的启发而设计,其核心价值在于完全避免了共识层协议的更改。

EIP-4337提出了新的交易对象UserOperation,用户将此对象发送到内存池中,由bundlers从矿工角度批量打包并交付合约执行交易事务,本质上是将底层的交易与账户运作提升到合约层面执行。

EIP-5189:通过背书人操作抽象账户(2022-06-29)

这可以视为对EIP4337逻辑的优化,通过建立资金罚款背书(endorser)机制来防止恶意Bundler的DoS阻塞攻击。

3.3 其他支持AA的提案

EIP-2718:新交易类型的包装信封(2020-06-13)

这是一个已经最终确定的提案,它定义了一种新的交易类型,作为未来新增交易类型的信封。

其最终效果是,在引入新交易类型时,通过特定编码来区分不同类型的交易,从而只需考虑向后兼容性,而无需向前兼容。最常见的例子是EIP1559,它区分了交易的手续费,使用了新的交易类型编码,同时不影响最初的legacy交易类型。

EIP-3607:禁止EOA地址部署合约(2021-06-10)

这是AA路径上的补充方案,用于防止合约部署地址与EOA地址冲突的问题。它会控制合约生成方法,禁止系统将代码部署到已经是EOA地址的地址上。这个风险实际上很小,考虑到以太坊地址长达160位,虽然存在使用私钥碰撞出指定合约地址私钥的方法,但即使投入比特币全网算力,估计也需要一年时间。

3.4 如何理解账户抽象的发展历程?

首先需要理解转为CA后的价值

这基本上就是EIP-4337的实际效果,它可以实现:

1. 支持多签和社交恢复
2. 支持批量交易
3. 支持使用ERC20代币支付gas费
4. 支持交易限额
5. 支持无gas交易(代付gas)
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 数据结构

EIP-7702定义了新的交易类型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中执行的代码。用户签署交易的同时也签署要执行