🎉 #Gate Alpha 第三届积分狂欢节 & ES Launchpool# 联合推广任务上线!
本次活动总奖池:1,250 枚 ES
任务目标:推广 Eclipse($ES)Launchpool 和 Alpha 第11期 $ES 专场
📄 详情参考:
Launchpool 公告:https://www.gate.com/zh/announcements/article/46134
Alpha 第11期公告:https://www.gate.com/zh/announcements/article/46137
🧩【任务内容】
请围绕 Launchpool 和 Alpha 第11期 活动进行内容创作,并晒出参与截图。
📸【参与方式】
1️⃣ 带上Tag #Gate Alpha 第三届积分狂欢节 & ES Launchpool# 发帖
2️⃣ 晒出以下任一截图:
Launchpool 质押截图(BTC / ETH / ES)
Alpha 交易页面截图(交易 ES)
3️⃣ 发布图文内容,可参考以下方向(≥60字):
简介 ES/Eclipse 项目亮点、代币机制等基本信息
分享你对 ES 项目的观点、前景判断、挖矿体验等
分析 Launchpool 挖矿 或 Alpha 积分玩法的策略和收益对比
🎁【奖励说明】
评选内容质量最优的 10 位 Launchpool/Gate
以太坊EIP-7702:账户抽象新时代 让EOA获智能合约能力
深入解读以太坊账户抽象赛道的过去与未来
前言
本文分为两大模块:
上半部分从2015年首个AA提案出发,系统梳理迄今为止的EIP提案主要内容,探讨AA历史提案的演进历程,并综合评价各方案优劣。
下半部分重点对比EIP4337推出后面临的市场冷淡反应,深入分析即将纳入以太坊下一版本升级的EIP7702,该提案一旦合并将全面改变链上应用形态。
EIP-7702具有划时代意义,让我们详细了解一下。
1. 账户抽象的背景
1.1 账户抽象的意义定位
以太坊创始人Vitalik在2023年底再次更新ETH路线图,但对账户抽象的定位未做改动。目前主流模式正从EIP-4337迈向下一阶段"自愿转换EOA账户"。
在EIP4337推出一年多以来(2023年3月1日在丹佛WalletCon上,以太坊基金会开发人员设计实现的ERC-4337核心合约通过OpenZeppelin审计,被认为正式推出),始终得到用户广泛认可但未被广泛使用。在这种矛盾的市场环境下,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)。外部账户的所有权和签名权由同一实体持有。持有私钥的人不仅拥有账户"所有权",还可以"签名转移所有资产"。
这由以太坊账户交易结构决定。标准交易中实际没有From字段,资金转账通过VRS参数(用户签名)反解析出From地址。这涉及ECDSA等非对称加密,单向门限函数等概念,由密码学保障安全性,也造成了如今EOA地址产权合并的窘境。
EIP4337核心效果是在交易字段中增加Sender Address,从而分离私钥与被操作地址。
产权分离之所以重要,是因为外部账户(EOA)设计衍生出更多问题:
这些限制导致普通用户难以使用以太坊:
首先,使用任何以太坊应用都需持有ETH并承担价格波动风险。
其次,用户需处理复杂的费用逻辑,Gas price、Gas limit、交易阻塞(Nonce顺序)等概念过于复杂。
最后,虽然许多区块链钱包或应用试图通过产品优化提升用户体验,但实际效果甚微。
因此,解决之道在于实现账户抽象,将所有权(Owner)和签名权(Signer)解耦,从而逐个解决上述问题。
历史上有多种方案,最终汇聚为两条路线。
3. AA历史提案脉络梳理
问题解法看似有多个EIP提案,但归根结底只有两种核心思路。每个未通过的EIP考虑的问题都汇聚成了现有方案的突破点。
3.1 第一种路线:将EOA地址变为CA地址
2015年11月15日,Vitalik就在EIP-101中提出以合约作为账户的新结构。将地址改为只有代码和存储空间,改变手续费支持ERC20支付,通过预编译合约将原生代币改为类ERC20存余额(具备代扣授权等功能),将交易字段精简为to、startgas、data和code。
这是大跃进式变革,会大幅改动底层设计,让每个账户地址都拥有自己的"代码"逻辑(正是现在EIP-7702要实现的效果)。
还能衍生出其他功能,如:
未继续推进原因很简单,步伐太大,对当前交易哈希冲突问题、安全性隐患考虑不周而搁置,但每个优点理念都成为后续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中加入两个新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编码序列化结果:
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]元组:
4.3.2 执行操作阶段