原生账户抽象不需要通用交易层：EIP-8130 与 EIP-8141 路线之争

为什么 EIP-8130 是对 EVM rollup 而言更用户友好、更开发者友好、更可预测且更可审计的路径

以太坊围绕原生账户抽象的争论已持续近十年。EIP-86 在 2017 年提出对签名和 nonce 校验进行抽象。此后，生态陆续构建了 meta-transactions、relay networks、ERC-4337、EIP-7702，以及如今的 Frame Transactions。

工程实现已经大幅改进，但用户体验并未以同样的速度提升。

原因很简单：每一代方案都避免把用户需要的那一小部分功能直接放进协议中。

相反，它创建了一个更通用的系统，钱包和应用必须在其上一层重新构建这些功能。

原生账户抽象不断重复发明同样三个原语：

• 交易批量处理
• Gas 赞助
• 密钥轮换

事实上，到 2026 年，任何现代账户抽象的基本预期还已经包括：并行 nonce、有效期窗口和 passkey 认证。

如今，有两种方案在竞争以太坊原生账户抽象：EIP-8130 直接将产品面标准化，而 EIP-8141 则标准化一台通用机器，开发者可以从中构建出产品面。

十年来责任不断上移

在早期，meta-transactions 实现了 Gas 赞助，但把问题转移到了 relays、trusted forwarders 和应用特定的集成中。例如 ERC-2771 要求接收方识别一个 trusted forwarder，并从附加的 calldata 中恢复出实际发送者。ERC-4337 在不改变共识的情况下实现了可编程账户。这是一项务实的成就，但它也创造了一套平行的交易系统：UserOperation 对象、另一套 mempool、bundlers、一个 EntryPoint、paymasters、factories、模拟规则、声誉规则以及新的 RPC 方法。EIP-7702 通过把控制权委托给钱包代码，为 EOA 提供了通往 smart-account 行为的路径。批量处理、赞助、权限和密钥管理仍然依赖于该实现本身，而不是由交易协议提供的保证。

每一步单独来看都是合理的。合在一起则揭示出一种模式：协议拒绝承担更好 UX 所需的账户功能，于是钱包、应用、relayers、bundlers、paymasters 以及其他第三方必须代为承担。

这不是抽象，而是责任转嫁。

EIP-8130 简单、可移植，并且刻意保持窄范围

在与钱包开发者、实现者和协议审查者的交流中，同样的三个优点被反复提及：简单性、可移植性和窄范围。

简单性

EIP-8130 明确说明了交易是什么。calls 描述其动作。payer 和 payer_auth 描述赞助。nonce_key 和 nonce_sequence 创建独立的通道。valid_after 和 valid_before 定义其有效期窗口。account_changes 描述账户创建、委托和配置变更。

这种结构更易读、更易实现。钱包无需解释一个由应用提供的验证程序，就能知道谁可以授权交易、谁支付，以及哪些调用阶段会提交。节点可以在执行之前识别 authenticator。即使是审计者，需要枚举的路径也更少。

可移植性

账户模型要正常工作，并不要求必须使用 EIP-8130 的原生交易类型。Keystore 和 authenticator 合约可以部署在各条 EVM 链上的确定性地址。一次 chain_id = 0 的账户变更允许同一份签名更新提交到每个部署，无需桥即可保留 signer 和恢复配置。

在没有 EIP-8130 交易类型的链上，同一个账户可以使用替代传输方式，例如 ERC-4337。这种回退并非自动完成：账户必须存在于目标链上，更新必须在目标链上提交，而且钱包需要一个兼容的 ERC-4337 实现。但用户不会仅仅因为交易信封变了，就需要一套完全不同的身份和账户策略模型。

窄范围

EIP-8130 定义的是通用账户模型，而不是一个用于发明新模型的执行环境。批量处理、赞助、并行 nonce、有效期窗口、认证和账户变更都有明确的协议面。钱包清楚地知道自己开箱即得什么。

Keystore 把一切整合在一起。它管理 actors、scopes、授权、轮换、撤销、过期和恢复。账户可以锁定其 actor 集合；解锁会启动一段可配置的延迟，之后权限变更才会恢复。因此，被攻破或受限的密钥可以在不改变账户地址的情况下被控制住。

不过，窄范围并不意味着僵化。Canonical authenticators 为各条链提供了针对 secp256k1、P-256、WebAuthn/passkeys 和委托的恒定成本原生路径。任何合约都可以实现 IAuthenticator 接口。宽松的 profile 可以在 gas 上限内直接接纳自定义 authenticators；仅支持 canonical 的 L2 可以把它们排除在原生热路径之外，同时仍可通过普通 EVM 执行或 ERC-4337 使用它们。

这种约束是架构层面的：定制通过声明的接口和明确的账户策略进入，而不是通过任意的交易机器。

EIP-8141 的通用性不是免费的

EIP-8141 很有创新性。它把一笔交易分解成负责验证、批准支付和执行的 frames。它让可编程验证和支付批准成为交易组合的一等公民组成部分。

EIP-8130 把灵活性放在了别处：声明的 authenticators、Keystore scopes、执行时策略管理器，以及由链选择的采用 profile。

重要的区别不在于定制是否存在，而在于在一笔交易可以安全转发之前，钱包和节点必须解释多少东西。

对于默认的 Transaction Layer 来说，最大表达力是错误的目标。真正重要的问题是：钱包能否向用户解释清楚签的是什么，节点能否预测准入成本，客户端能否实现一致的行为，审计者能否枚举安全路径，sequencers 能否优化常见情形。

EIP-8141 引入了七个 opcodes、frame 模式和标志位、transaction-scoped approvals、外层签名列表、分离的执行与 state-gas 预算、per-frame receipts、回滚规则、default code 以及公共 mempool 限制。虽然协议定义的路径可以被评估，但自定义验证仍然需要 EVM 执行和依赖跟踪。

当一笔 frame transaction 失败时，开发者可能需要检查它的模式、caller 上下文、approval scope、标志位、validation-prefix 位置、签名条目、两个 gas 预算、回滚边界、payer 状态和 receipt 状态。每个机制都有其理由，问题在于它们的组合。

能力	EIP-8130	EIP-8141
批量处理	一等公民的 call phases	Frame 组合与原子标志位
赞助	显式的 payer 与 payer 认证	VERIFY/APPROVE 与 paymaster 模式
密钥管理	Keystore actors、scopes、过期、锁定和延迟解锁	委托给 Account 代码，基础 EIP 未做标准化
并行 nonce	内置于交易中	由姊妹提案 EIP-8250 提供
有效性	valid_after 和 valid_before	内置过期验证器；没有 valid_after 字段
账户模型	协议可见的 Keystore 配置	外部的 ERC-8286 和 ERC-7579 模型
验证	声明的 authenticator，配合按 profile 选择的准入	可编程 VERIFY frames
可移植性	原生多链变更与替代传输方式	基础 EIP 中没有等价的账户可移植性路径
EVM 变更	无新 opcodes	七个新 opcodes 和 frame 语义

交易机器不是账户模型

围绕 EIP-8141 生长出来的各项标准表明，还有多少内容留在了基础提案之外。EIP-8250 增加了 keyed nonces。EIP-8272 为验证增加了 recent application roots。EIP-7906 增加了 post-transaction assertions。ERC-7730 提供 clear-signing 元数据。交易过期如今已成为 EIP-8141 本身的一部分，但更完整的产品仍然是分散的。

最明显的例子是草案 ERC-8286——面向 Frame Transactions 的模块化账户。EIP-8141 定义了 frames 如何验证、批准和执行，但没有定义它们背后的模块化钱包账户。ERC-8286 通过 frame validators、approval modes、execution-mode 声明和一个账户接口扩展了 ERC-7579。

因此，钱包开发者需要 frame transaction、ERC-8286 验证扩展和 ERC-7579 模块模型三者齐备，才能拥有一个连贯的模块化账户。协议激活只是钱包采用的开始。

以太坊和 rollup 的推进速度不同

2026 年初，以太坊公开路线图把 Glamsterdam 定在 2026 年上半年。5 月目标移到了下半年，8 月又移到了第四季度。于是现在，下一个分叉 Hegotá 反而被呈现为 2027 年升级。

此外，EIP-8141 在 Hegotá meta EIP 中只是 Considered for Inclusion，而非 Scheduled for Inclusion。如果以太坊保持大约六个月一次的分叉节奏，最早可信的时间窗口大约在 2027 年第二季度末。不过，考虑到当前延期仍在持续，再加上姊妹 EIP 带来的额外复杂性，第三季度是更稳妥的规划假设。

将执行与交易分离

L2 rollup 无法围绕这种不确定性规划产品开发。以太坊 L1 以年为单位演进，rollup 以季度为单位演进。解决方案是把两个兼容面分开：

• Execution Layer（EL）：EVM 语义、合约行为和状态转换。
• Transaction Layer（TL）：交易信封、认证、nonce、有效性、支付、mempool 准入、排序和区块构建。

EVM 兼容应该适用于 Execution Layer。它不应该要求每一条 rollup 都继承以太坊 L1 的交易格式和区块构建约束。

这样一来，以太坊 L1 可以按照其去中心化和共识流程所要求的节奏来开发和发布 EIP-8141。与此同时，L2 可以采用 EIP-8130 作为务实的 Transaction Layer，而不放弃 EVM 兼容。合约行为保持一致，同时钱包可以协商每条链的交易能力。

采用已经开始。Base 计划在其 Cobalt 升级中引入 EIP-8130，并报告称相比之前的 smart-account 设计，单笔交易成本降低超过 2 倍。Optimism 也宣布正在与 Base 合作，把原生账户抽象带入 OP Stack。

一旦 OP Stack 链在生产环境中证明了该模式，其他 rollup 生态就可以验证其可行性，并跟进把 EIP-8130 投入生产。

届时 Arbitrum、Polygon 和 ZKsync 也必然能够验证对原生批量处理、赞助、账户策略、并行 nonce、有效性和现代认证的同样需求。

AA 的链下成本是真实存在的

AA 的链下成本同样重要。钱包提供商、企业和金融机构必须围绕这些账户运营签名基础设施、监控、恢复、策略和合规系统。

EIP-8130 是面向工具的：它为这些系统提供了一个可复用的账户和服务策略面。

EIP-8141 是面向网络的：它为运营者提供了一个更可编程的交易处理环境。

答案不是强迫所有链使用同一个 Transaction Layer，而是保留共同的 Execution Layer，同时在不同的交易系统之间标准化能力发现、签名描述、RPC 约定、receipts 和回退传输方式。

掌控账户路径

EIP-8141 作为以太坊 L1 的通用交易框架可能很有价值，但这并不意味着最大表达力就是每条 EVM 链的正确默认选择。

对 rollup 而言，EIP-8130 是更好的务实 Transaction Layer，因为它足够简单易于实现，足够可移植以保留账户体验，也足够窄以使常见能力显式化。

它给开发者更小的面，给节点更可预测的验证路径，给审计者更可枚举的系统，给 sequencer 一个可以直接优化的模型。

近十年过去，原生账户抽象不应再要求钱包从更低层的机制重新构建批量处理、赞助和密钥管理。

协议应当承担用户已经期待的功能，而最好的设计就是让常见路径显式化的设计。

• 原文链接： x.com/pedrouid/status/20...
• 鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～