撰文:imToken
上周,以太坊核心开发者会议上正式讨论 EIP-8141 是否纳入 Hegota 升级,结果出人意料,这项由 Vitalik 亲自站台的提案,并未被列为 Hegota 的「头条功能」,而是获得了「考虑纳入」(CFI)的状态。
而本周,Google 量子 AI 团队发布最新白皮书,表示在其给定的硬件假设下,破解 ECDLP-256 所需的物理量子比特估算,相比此前大幅下降 20 倍。虽然不代表量子攻击近在眼前,却实实在在提醒我们,如果账户体系未来无法灵活更换验证逻辑,那么今天很多关于钱包体验的讨论,最终都可能演变成安全问题。
虽然站在协议推进的现实角度,EIP-8141 目前仍然太重,尤其是在客户端实现、交易池安全和验证复杂度上,尚未形成足够扎实的共识。
但站在当下这个时间节点,EIP-8141 值得讨论和认真审视的地方,似乎真的越来越多。
一、EIP-8141 到底要解决什么?
EIP-8141 由 Vitalik Buterin 与 timbeiko 等核心贡献者推动,正式名称为 Frame Transactions(帧交易)。
如果用一句更容易理解的话概括,它想做的其实不是单独增加某个钱包功能,而是试图从协议层让任何账户都不必再被单一的 ECDSA 签名路径所束缚,而是可以拥有更灵活的验证与执行逻辑。
这也意味着,多签、Gas 赞助、密钥轮换、社交恢复,甚至未来接入抗量子签名方案,都不再只是外挂在钱包外部的一层能力,而有机会成为以太坊账户体系里的「原生成员」。
如果只看表面,EIP-8141 讨论的,是一组看起来非常具体的能力:用稳定币支付 Gas、把多步操作合成一笔交易、支持更灵活的签名方式、甚至为未来的抗量子签名预留空间。可以说,多年来从 ERC-4337 到 EIP-7702,围绕钱包体验的很多改进,本质上都在让账户不再只是一把私钥,而是一个可以自定义规则的入口。
问题在于,这些改进确实让钱包越来越像智能账户,但始终没有真正触及以太坊最底层的默认账户模型。
众所周知,在现有体系下,以太坊账户大体分成两类。一类是外部拥有账户,也就是大家最熟悉的 EOA,它由私钥控制,可以主动发起交易,但缺乏可编程能力;另一类是合约账户,也就是智能合约本身,它可以执行复杂逻辑,却不能自己主动发起交易。
这就导致发起交易的能力,与单一私钥签名长期被绑定在一起,只要这个前提不变,很多用户今天觉得理所当然应该拥有的能力,比如灵活更换签名规则、让别人代付 Gas、在私钥丢失后恢复账户控制权,或者未来平滑迁移到新的密码体系,都很难真正成为账户的默认能力。
如果你用过 imToken 或其他 Web3 钱包,你大概率也遇到过这些痛点,譬如钱包里有一堆 USDC,但没有 ETH 就发不出交易(因为 Gas 只能用 ETH 支付);丢了助记词就彻底丢了钱,无法恢复;一笔「授权 + 交换」的操作要签名两次、确认两次等等。
这些问题,并不是钱包产品「不够好」,而是以太坊账户模型本身的设计结果。
从这个角度看,过去两年的演进其实已经非常清晰,ERC-4337 在不修改协议的前提下,把账户抽象先在应用层跑了起来;EIP-7702 又进一步证明,EOA 并非完全不能扩展,至少可以临时获得部分接近智能账户的能力。
也就是说,以太坊并不是不想做账户抽象,而是一直在用更温和、更保守的方式,逐步逼近这件事。而 EIP-8141 的出现,意味着这条路径走到了一个新的节点。它不再满足于在现有体系外围再叠一层智能账户能力,而是试图把账户抽象直接嵌入交易模型本身,让账户从协议层开始就具备可编程的验证与执行逻辑。
这也是为什么 EIP-8141 会在今天重新升温。一方面,上层钱包体验已经越来越接近原生账户抽象,协议层迟早需要跟上;另一方面,量子计算带来的长期压力,也正在把「账户能否灵活更换签名方式」从一个遥远的技术议题,提前变成必须认真考虑的现实问题。
二、EIP-8141 如何运作?
归根结底,EIP-8141 引入了一种全新的交易类型——帧交易(Frame Transaction),交易类型编号为 0x06。
如果说传统以太坊交易的基本逻辑是一笔交易对应一次调用,那么 EIP-8141 想做的,就是把一笔交易拆解成一组可以按规则顺序执行的「帧」,从而把原本捆绑在一起的验证、付款、执行三件事拆开处理。
每个「帧」有三种执行模式:
- VERIFY(验证帧):负责验证交易是否合法,它会运行账户自定义的验证逻辑,如果通过,就调用新引入的 APPROVE 操作码来授权执行并指定 Gas 上限。
- SENDER(发送帧):执行实际操作,如转账、调用合约等。调用者地址就是交易发送者本人。
- DEFAULT(入口帧):以系统入口地址作为调用者,用于部署合约、验证 Paymaster 等场景;
这套机制的意义,并不是交易能做得更复杂,而是第一次把「验证、支付、执行」三件事,从账户动作中拆解出来,并交由协议原生调度。
毕竟过去,谁来验证交易、谁来支付 Gas、谁来执行真实操作,基本都被绑在同一个账户动作里,而在 EIP-8141 的设计下,这几件事可以被拆成不同的帧,由协议按明确顺序依次执行,也正因为如此,账户不再只能依赖单一私钥去「整体签字」,而开始具备更接近可编程执行主体的形态。
举个具体例子,假设你想用 USDC 支付 Gas 来完成一笔 Swap,在 EIP-8141 的框架下,这件事理论上可以被组织成一条完整的帧流程:先由账户验证签名和执行权限,再由支付方或 Paymaster 验证自身愿意承担费用的条件,随后完成对应资产的费用支付,最后再执行真正的 swap 操作。
这样一来,Gas 支付与主交易就能被纳入同一条原子流程里,要么全部成功,要么全部回滚。
对于用户来说,最直观的变化就是很多以前必须拆成两三步、并且中间存在失败风险的操作,未来可以更像一次完整动作,因此这种原子性也是 EIP-8141 想解决用户体验碎片化问题的关键之一。
那这对钱包用户意味着什么?从结果上看,最直观的变化至少有四层:
- Gas 支付被抽象:钱包里有稳定币,不再意味着你还必须额外准备一点 ETH 才能操作,未来由 DApp、Paymaster 或其他赞助方代付 Gas,会变得更原生;
- 多步操作被合并:像「授权 + Swap」「授权 + 质押」这类现在经常需要多次签名的流程,有机会被打包成一笔更完整的操作;
- 账户安全规则被打开:多签、社交恢复、每日限额、时间锁、密钥轮换,这些都不再只是某个钱包产品额外提供的高级功能,而开始有机会建立在更原生的账户逻辑之上;
- 签名方案不再必须被 ECDSA 单一路径锁死:这让账户未来迁移到不同密码体系,包括后量子签名方案,第一次拥有了协议层意义上的可能性;
三、为什么没成为 Hegotá 的头牌?
一个很容易被忽略、但对钱包用户来说非常关键的点是:即便 EIP-8141 最终落地,现有账户体系也不会因此被整体推翻。
即便你现在使用的是 imToken 等既有的 Web3 钱包,也不需要迁移,因为它向后兼容,现有的 EOA 地址可以继续使用,只需要在合适的时候选择「升级」账户的验证逻辑。
但反过来看,也恰恰是因为它改得足够深,它才没有在最新一轮讨论里直接成为 Hegotá 的头牌功能。不过,按照 2026 年的 EIP champion 流程,CFI(Considered for Inclusion) 的含义并不是被否定,而是进入认真考虑阶段,但还没有到最终拍板上线的时候。
换句话说,核心开发者并不是不认可 EIP-8141 的方向,而是在承认其价值的同时,也认为它目前仍然太「重」。
毕竟原生账户抽象不像 ERC-4337 那样可以先由少数钱包、基础设施和应用逐步推动,它一旦进入协议层,就意味着所有执行层客户端都要认真实现、测试和协同,这会天然提高推进门槛,也会让核心开发者在 fork 规划时更偏向稳妥。
那接下来会发生什么?可以拆成两条线来看:
- EIP-8141 既然处于 CFI 状态,就说明它仍在被持续评估之中,提案作者会继续补足围绕交易池安全、验证规则和客户端实现的关键细节,后续 ACD 会议也会重新审视它是否具备进一步前推的条件;
- 如果这些不确定性能够被持续压缩,它就有机会在后续升级中进入更实质的纳入阶段;如果不能,它也完全可能被顺延到更晚的升级周期;
实事求是地说,EIP-8141 也并非唯一的原生账户抽象提案,本身更不是某种现成的后量子签名方案,无法直接解决量子计算问题,但它的重要性在于,它第一次为账户摆脱 ECDSA 单一路径提供了协议层意义上的出口。
从这个角度看,EIP-8141 的真正价值,并不在于它是不是唯一正确答案,而在于它把「原生账户抽象的终局究竟应该长什么样」这个问题,第一次非常完整地摆到了以太坊协议讨论的桌面上。
它不是唯一方案,但它确实是目前最雄心勃勃、也最接近「完整原生 AA」想象力上限的方案之一。
无论 EIP-8141 最终是否能赶上 Hegotá,这场讨论本身至少已经说明了一件事:
以太坊并没有在原地等待问题发酵,而是在用一种日拱一卒地为下一代账户体系提前铺路。
