原生账户抽象 + 抗量子威胁：EIP-8141 为何还没成为以太坊 Hegotá 的头牌？

撰文：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á，这场讨论本身至少已经说明了一件事：

以太坊并没有在原地等待问题发酵，而是在用一种日拱一卒地为下一代账户体系提前铺路。