原生账户抽象：最新进展和待定提案 (Q1/26)

• Ahmed Al-Balaghi

TL;DR

原生账户抽象旨在将 gas 赞助、批量交易、Passkey 认证和后量子密码学直接引入 EVM 协议——无需 bundlers 或二级 mempool。目前有四项提案正在积极讨论中

Vitalik 的提案 (EIP-7701)

最大程度的通用性。任意验证逻辑、交易阶段，涵盖所有延伸目标。旨在永远不需要替换的“最终解决方案”。

跳转到该部分 ↓

Tempo Transactions

快速发布，解决当前问题。原生 Passkey、批处理、调度和 ETH 赞助。没有自定义验证——有意限制在用户当前所需的功能。

跳转到该部分 ↓

EIP-8130: Account Configurations

快速推出强大功能。受限验证与可编程执行。原生 multisig、代币 gas 支付和可扩展的密钥类型。

跳转到该部分 ↓

EIP-8141: Frame Transactions

将 EIP-7701 提炼成具体规范的正式 EF 规范。用于验证和执行的交易“frames”具有完全可编程性。

跳转到该部分 ↓

总结： Tempo 和 EIP-8130 优化了在有限复杂性下快速发布。Vitalik 的提案和 EIP-8141 优化了长期灵活性和后量子就绪性，但代价是协议复杂性更高。

账户抽象

Ethereum/EVM 开发者社区长期以来一直致力于解决 EVM 架构固有的用户体验和可用性挑战。最常见的需求是实现：

1. 用 ERC-20 代币支付 gas，或允许应用程序为用户赞助 gas
2. 执行批量交易
3. 使用 Passkeys（或其他签名方案）进行交易认证
4. 交易调度和重复交易（订阅、基于触发器的自动化等）
5. 原生 multisig 设置

虽然许多其他用例也属于“账户抽象”这个广义术语，但这些是最普遍的。

ERC-4337

账户抽象的最初步骤是 ERC-4337——一种用于 gas 抽象、交易赞助、批量执行等的标准化方法。值得注意的是，ERC-4337 不需要硬分叉或协议更改。

ERC-4337 通过让用户采用智能合约作为其账户来实现这一点。这些智能合约遵循 ERC 中定义的严格标准，并通过 Bundlers 和 Paymasters 执行交易。ERC-4337 生态系统得到了许多供应商的支持——特别是 Biconomy、ZeroDev、Alchemy、Safe、Rhinestone、Ambire 等。

该标准获得了不错的采用，特别是在面向消费者的金融科技和数字银行应用程序中，但未能完全解决账户抽象问题。

ERC-4337 的一些核心批评包括：

• 钱包不可移植性：尽管进行了标准化，但钱包无法在应用程序之间“导入/导出”。如果一个应用程序部署了一个 ZeroDev 账户，该账户无法轻松地被基于 Biconomy 账户标准的应用程序使用。
• 二级 mempool / Bundler 访问：在 ERC-4337 中，交易依赖于二级 mempool 或应用程序直接访问 ERC-4337 Bundler。二级 mempool 引入了复杂性，而要求应用程序维护与 Bundlers 的直接关系则引入了中心化风险。
• 复杂性：由于 ERC-4337 旨在允许任意复杂的验证逻辑，因此出现了多个 DoS 攻击向量。恶意行为者可以强制 Bundlers 运行数千次模拟，并在执行前通过一笔交易使数千笔交易失效。这要求 ERC-4337 bundlers/mempool 实现复杂的状态访问逻辑。
• Gas 成本：尽管这正在成为一个越来越小的问题，但通过 ERC-4337 执行交易会产生显著的 gas 开销——部分原因是复杂的 Paymaster 验证逻辑，部分原因是交易通过智能合约路由。虽然在 L2 和更便宜的 L1 上问题不大，但这减缓了 ERC-4337 在 Ethereum 主网上的采用。
• 向后不兼容性：由于使用 ERC-4337 账户需要部署智能合约，因此用户在迁移到新的账户标准时不能保留其现有的钱包地址。他们必须将所有资产转移到一个新地址——引入了迁移摩擦，并导致用户丢失其钱包历史记录。

EIP-7702

这些批评并未被忽视——Ethereum 基金会引入了一个新标准：EIP-7702。

EIP-7702 允许用户通过将现有 EOA 委托给智能账户实现来将其转换为智能账户。EIP-7702 直接解决了钱包不可移植性（用户可以随时将其 EOA 重新委托给不同的实现）和向后不兼容性（由于用户委托其现有 EOA，因此不会丢失历史记录）的问题。

然而，二级 mempool、复杂验证逻辑和 gas 开销的问题仍然存在。

EIP-7702 由大多数 ERC-4337 供应商（已列出）提供，此外还得到了某些钱包（MetaMask、Trust、BitGet、Ambire）以及非 4337 供应商（特别是 Ithaca 和 Porto）的一流支持。

荣誉提名：非 7702 EOA 钱包的优雅向后兼容性

原生账户抽象

甚至在 EIP-7702 正式化之前，Ethereum 基金会就计划在协议层面引入账户抽象。这将允许标准 Ethereum/EVM 节点接受批量交易，验证自定义签名方案（特别是 Passkeys），并允许用户使用 ERC-20 代币支付 gas 或允许应用程序为用户赞助 gas。

原生账户抽象的另一个目标是为后量子密码学和交易隐私提供协议级支持。

最后，原生账户抽象的“限制”是它必须与 Ethereum 的扩容路线图保持一致，特别是部分无状态性（VOPS）和 Inclusion Lists (FOCIL)。

目前，有四项活跃提案旨在在 EVM 链中引入原生版本的账户抽象：

• Vitalik 的提案
• Tempo Transaction 提案
• EIP-8130（来自 Coinbase/Base 团队）
• EIP-8141: Frame Transactions（正式 EF 规范）

Mempool 问题

在深入研究这些提案之前，值得了解为什么原生账户抽象很难。核心挑战不是实现新的签名类型或批处理，而是 mempool。

在传统的 Ethereum 中，验证交易是廉价的：检查签名（一次椭圆曲线操作）、验证 nonce 是否匹配、确认账户有足够的 ETH 支付 gas。所有这些都可以通过简单的状态查找来完成。如果一笔交易现在是有效的，那么它将保持有效，直到账户的 nonce 或余额发生变化。

账户抽象打破了这种模型。如果验证可以运行任意代码，就会出现几个问题：

通过模拟进行 DoS 攻击：在包含交易之前，节点必须模拟它以检查它是否有效并会支付费用。利用任意验证逻辑，攻击者可以制造通过模拟但在链上失败的交易（因为某些状态在模拟和包含之间发生了变化）。节点浪费了计算，而攻击者却没有支付任何费用。

大规模失效：假设验证逻辑从一个共享合约中读取——例如，检查预言机价格或全局注册表。更新该合约的一笔交易可以立即使 mempool 中数千笔待处理交易失效。节点必须重新模拟所有内容。

攻击 bundlers：在 ERC-4337 中，bundlers 将多个 UserOperation 聚合为一笔交易。恶意用户可以制造一个通过模拟但在实际执行期间 revert 的 UserOperation，从而浪费 bundler 的 gas。Bundlers 需要复杂的声誉系统来保护自己。

验证期间的状态访问：验证可以读取的状态越多，交易失效的方式就越多。如果验证可以读取任何存储槽，则失效范围实际上是无限的。

这就是 ERC-4337 引入严格规则的原因，限制了验证代码可以做什么：不能读取外部合约（除了你自己的），不能使用 TIMESTAMP 或 BLOCKHASH 等环境操作码，gas 受限。这些规则使验证“本地化”——你的交易的有效性仅取决于你自己的状态。

下面的三项提案对此问题采取了不同的方法。Vitalik 的提案接受了复杂性并构建了复杂的 mempool 规则。Tempo 和 EIP-8130 则完全回避了这个问题，通过将验证限制为签名检查——在交易支付完成之前不进行 EVM 执行。

Vitalik 的提案

阅读完整提案

2026 年 1 月，Vitalik 发布了一项提案，概述了实现全面原生账户抽象的路径。它定义了两组目标：

核心目标：

• 替代签名算法（包括抗量子算法）
• 原生 multisig 支持
• 密钥轮换和账户升级
• 无需中介的隐私协议提款

延伸目标：

• 用 ERC-20 代币支付 gas（无需链下参与者）
• 抗量子签名聚合
• Keystore 钱包（L1 上的账户状态，可从 L2 读取）
• 私有账户抽象（用于验证的 ZK-SNARKs）
• 后断言（如果执行后条件不满足则 revert）
• 与 ERC-4337 和 Safe 等钱包的向后兼容性

该提案提出了三种方法，每种都比上一种更强大：

方案 1：最小化 AA

最简单的方法。如今，每个 Ethereum 交易都通过检查 ECDSA 签名进行验证——这是一个固定不变的、内置于协议中的过程。方案 1 用智能合约调用取代了这一点。协议不再直接验证你的签名，而是调用你账户的代码，让该代码决定交易是否有效。

你的账户获得了一小部分存储槽（0-15），用于存储公钥。这意味着你可以轮换密钥、添加备用密钥或设置基本 multisig——所有这些都无需更改地址。协议将这些槽添加到“VOPS”（所有节点必须存储的最小状态）中，从而使验证保持快速和廉价。

局限性：这种方法有意受到限制。验证只能读取这 16 个存储槽，不能读取其他任何东西。这使得事情保持简单和 mempool 安全，但这意味着没有隐私协议、没有 gas 赞助，也无法与现有智能钱包向后兼容（智能钱包需要重写其代码以适应 16 个槽）。

方案 2：隐私扩展

在方案 1 的基础上，添加了一种称为“2D nonces”的新型存储。这种存储仅在验证阶段可访问——执行阶段无法触及。

为什么这很重要？隐私协议（如 Tornado Cash 或 Railgun）需要跟踪哪些 notes 已被花费。它们通过“nullifiers”（阻止双重花费的唯一标记）来做到这一点。通过 2D nonces，隐私协议可以充当“多租户账户”，多个用户共享一个合约，每个用户将他们的 nullifiers 存储在这个特殊的仅用于验证的存储中。

缺点是：如果多个用户同时尝试从同一个隐私协议中提款，mempool 可能一次只允许一个通过。而且与方案 1 类似，它与现有钱包不向后兼容。

方案 3：无协议内限制

此方法消除了验证可以访问内容的限制。你的账户的验证代码可以读取它需要的任何状态——其他合约、代币余额、预言机，任何东西。

为了使其与 FOCIL（抗审查机制）和无状态性（大多数节点不存储完整状态）一起工作，交易必须包含“witnesses”——对它们访问核心 VOPS 之外的任何状态值的加密证明。这会为每个外部存储槽增加约 4KB，但这是可管理的。

权衡在于 mempool。在无限制状态访问的情况下，一笔交易可能会通过更改共享状态而使数千笔其他待处理交易失效。为了解决这个问题，方案 3 依赖两种 mempool 策略：

1. ERC-4337 风格的规则：验证只能访问“你自己的状态”——你账户的存储、你的代币余额等。这保证了你的交易在你的状态改变之前保持有效。
2. 自定义 mempool：对于高级用例（如 gas 赞助），应用程序可以运行自己的具有自定义规则的 mempool。提议者和 FOCIL 节点可以加入他们想要的任何 mempool。

方案 3 涵盖了所有核心目标和大多数延伸目标。主要限制是开发者体验——每个高级用例可能都需要自己的自定义 mempool。

EIP-7701：完全通用性

EIP-7701 是最强大的选项。它引入了交易阶段的概念——按顺序执行的不同阶段，每个阶段都有其自身的成功或失败规则。

一个典型的交易可能有五个阶段：

1. 部署：如果账户合约尚不存在，则部署它
2. 发送者验证：检查用户的签名
3. Paymaster 验证：一个“paymaster”合约同意代表用户支付 gas
4. 执行：执行用户实际想要做的任何事情
5. 后操作：Paymaster 计算最终 gas 成本并收取费用（例如，用 USDC）

每个阶段都可以指定：“如果我失败，只 revert 我自己”或“如果我失败，revert 所有东西”或“如果我失败，交易根本不能被包含。”这种灵活性使得以前没有链下中介就无法实现的复杂流程成为可能。

例如：你有 100 USDC 但没有 ETH。你想向朋友发送 10 USDC。使用 EIP-7701，你可以在一笔交易中完成此操作——一个 paymaster 合约（本质上是链上 AMM）为 gas 预付 ETH，执行你的转账，然后收取 USDC 作为付款。没有 bundlers，没有 relayers，没有受信任的第三方。

EIP-7701 还支持“后断言”——在执行后运行的检查，以验证交易是否符合预期。如果你的代币余额与你预期的不符，执行将 revert（但你仍然支付 gas，因此它是 mempool 安全的）。

作者注：后断言在技术上可以通过编码一个原子批处理来实现，其中断言作为最终调用。如果断言失败，整个批处理将 revert。然而，EIP-7701 在协议层面正式化了这种模式，具有更清晰的语义和更好的工具支持。

代价是复杂性。EIP-7701 是一个更复杂的协议变更，mempool 规则变得更加复杂。但它涵盖了所有目标——核心和延伸——并提供了一个足够灵活的基础，以应对我们尚未想象到的用例。

Vitalik 的建议

任何低于方案 3 的方案都不值得付出努力。方案 3 和 EIP-7701 之间是复杂性与通用性的权衡。

他的方法是：尽快发布协议变更，但逐步推出 mempool 功能。从限制性规则开始（如 ERC-4337 规则），然后随着开发人员信心的增强而扩展。

关键的见解是：大多数复杂性存在于 mempool 中，而不是协议中。尽早进行协议更改可以为生态系统提供成熟的时间。

支持完全通用性的论据（Nicolas Consigny）

ZkEVM 兼容性

Ethereum 的路线图包括向 ZkEVM 架构过渡，其中 provers 生成区块执行的加密证明，而不是 validators 重新执行每笔交易。这是一个“精简”项目——进度在 ethproofs.org 上跟踪。

为了实现这一点，证明系统必须处理 Ethereum 中的每个操作，包括验证。如果验证受限于固定操作（例如 Tempo 的特定签名类型），prover 只处理这些情况——但 Ethereum 将失去在不进行硬分叉的情况下添加新签名方案或验证模式的能力。EIP-7701 的任意验证与 ZkEVM 对通用 provers 的需求相符。替代方案是每当加密标准演变时重复协议更改。

后量子灵活性

当前的 Ethereum 密码学 (secp256k1 上的 ECDSA, P-256) 容易受到运行 Shor 算法的量子计算机的攻击。行业共识表明 P-256 硬件可能在 2027-2028 年被淘汰，取而代之的是 ML-DSA（基于格）或 SPHINCS（基于哈希）等后量子方案。

高效的后量子签名聚合需要递归 STARK 证明——验证其他证明批次的证明。这只有在证明系统能够处理任意验证逻辑时才有效。有了 EIP-7701，新的后量子方案可以作为智能合约验证部署，而无需协议更改。对于固定验证（Tempo，EIP-8130），每种新的签名算法都需要硬分叉。鉴于哪些后量子方案会胜出存在不确定性，灵活性是宝贵的。

Tempo Transactions

阅读完整提案

Tempo 是一种不同的哲学。它不构建一个能够处理未来任何用例的通用框架，而是提出：用户今天面临哪些具体的 UX 问题，以及解决这些问题需要进行哪些最少的协议更改？

该提案引入了一种新的交易类型，它捆绑了一组受限的功能：

• 原子批处理：一笔交易中的多个调用——如果任何一个失败，所有都会 revert
• 有效期窗口：交易可以有“有效时间之后”和“有效时间之前”的时间戳，用于调度和过期
• Gas 赞助：可选的“fee payer”可以支付 gas 费用
• 2D nonces：并行 nonce 流，因此交易不必排队等待
• 多种签名方案：原生支持 secp256k1、P-256 和 WebAuthn (Passkeys)
• Access keys：协议强制的子密钥，具有过期和消费限制

Tempo 明确不做什么

该提案明确了其边界：

• 它不替代 ERC-4337 或其 mempool 模型
• 它不提供任意验证逻辑（没有自定义代码来决定交易是否有效）
• 它不引入原生 ERC-20 费用支付——希望获得代币报销的赞助商必须在交易中包含明确的调用来给自己支付
• 它不定义通用权限系统

目标是狭窄的、可审查的基元集。复杂的用例仍然需要智能合约钱包或 EIP-7702 委托。

原生 Passkey 支持

这是 Tempo 的主要功能。目前，在 Ethereum 上使用 Passkeys (WebAuthn) 需要 ERC-4337：你创建一个 UserOperation，bundler 将其打包成一个真实的交易，然后该交易调用 EntryPoint 合约。你无法直接使用 Passkey 签署交易并提交。

Tempo 改变了这一点。Tempo 交易可以直接使用 P-256 密钥（Passkeys 使用的密码学）或完整的 WebAuthn 认证数据进行签名。没有 bundler，没有 EntryPoint，没有中介。协议本身理解这些签名。

交易在其编码中包含签名类型：

• secp256k1 (65 字节)：标准 Ethereum 签名
• P-256 (130 字节)：带公钥的原始 P-256 签名
• WebAuthn (可变，最多 2KB)：包括认证器数据和客户端数据 JSON 的完整 Passkey 认证

对于 P-256 和 WebAuthn，发送者地址从公钥派生：keccak256(pubkey_x || pubkey_y) 截断为 20 字节。

Gas 赞助

Tempo 包含一个可选的 fee_payer_signature 字段。如果存在，gas 费用将从 fee payer 而不是发送者处扣除。

fee payer 签署的消息与发送者略有不同（使用不同的魔术字节进行域分离），其中包含发送者的地址。这可以防止 fee payer 签名附加到不同交易的重放攻击。

重要提示：fee payer 签名必须是 secp256k1。这使得验证简单且有界。

协议不处理代币报销。如果赞助商希望以 USDC 获得报销，他们应该只共同签署包含明确转账以支付给他们的交易。这在签名之前在链下进行验证——协议只执行调用。

2D Nonces

传统的 Ethereum 账户有一个单一的 nonce，每次交易都会递增。这意味着交易必须按顺序处理——如果交易 #5 阻塞，交易 #6、#7、#8 都会等待。

Tempo 引入了“nonce keys”。每个密钥都有自己独立的 nonce 流：

• nonce_key = 0：使用标准账户 nonce（向后兼容）
• nonce_key > 0：使用该密钥的独立计数器

这允许你并行发送多个交易，而不会相互阻塞。一个应用程序可以使用一个 nonce key 进行交换，另一个用于转账，另一个用于治理投票——每个都独立运行。

有效期窗口

交易可以指定：

• valid_after：在此时间戳之后才包含此交易
• valid_before：在此时间戳之后不包含此交易

这使得调度交易（明天中午执行）和过期交易（此交换仅在 5 分钟内有效）成为可能。mempool 会持有交易直到它们变得有效，并在过期时丢弃它们。

Access Keys

该提案引用了一个“access keys”的配套 EIP——具有受限权限的子密钥。用户可以创建一个 access key，该密钥：

• 每天最多只能花费 0.1 ETH
• 30 天后过期
• 只能与特定合约交互

主账户创建这些密钥，由 access key 签名的交易使用“keychain wrapper”签名格式，该格式标识正在使用哪个 access key。协议在执行前验证密钥的权限。

权衡

Tempo 刻意避免通用性。它不会处理所有可能的用例——隐私协议、完全自定义验证、可编程后置条件都超出了其范围。

但对于它所针对的特定问题——Passkeys、批处理、调度、赞助——它提供了一个干净的解决方案，且协议复杂性最低。交易是静态可分析的。Gas 成本是可预测的。mempool 除了基本的有效性检查外，不需要新的规则。

Vitalik 的看法：Tempo 解决了不同的问题。它非常适合标准化常见的 UX 模式，但它没有解决完整账户抽象的长期目标（抗量子性、隐私、密钥轮换）。Ethereum 可以同时采用这两种方案——Tempo 用于日常交易，EIP-7701 用于高级用例——但它们服务于不同的目的。

EIP-8130: Account Configurations

阅读完整提案

EIP-8130 采取了 Tempo 受限基元和 EIP-7701 完全通用性之间的中间路径。核心洞察：账户抽象中的大部分复杂性来自验证。将验证限制为固定密钥类型，让执行保持完全可编程，这样你就可以在不增加 mempool 复杂性的情况下获得大部分好处。

验证 vs. 执行

这种区别是理解 EIP-8130 的关键。

验证 回答：“此交易是否已授权？”它发生在 gas 支付之前。在 EIP-8130 中，这意味着根据账户的注册密钥检查签名——一个简单的状态查找，没有 EVM 执行。如果验证失败，交易会立即被拒绝，永远不会进入 mempool。

执行 是其他一切：你的智能钱包逻辑。它发生在 gas 支付之后。calldata 作为对你地址的自调用（to = msg.sender = tx.origin = 你的地址）到达。

对于没有代码的 EOA，这什么也不做——调用成功，仅此而已。对于智能账户，你的合约会按你想要的方式解释 calldata：

• 将其解码为一批调用并按顺序执行
• 在允许转账之前检查消费限额
• 实现时间锁、会话密钥或任何其他逻辑

协议处理“谁可以提交”。你的代码处理“可以做什么”。

账户配置预编译

每个账户在 Account Configuration Precompile 中注册授权密钥。只有账户本身可以修改其配置。协议在验证期间直接读取这些密钥——无需 EVM。

支持的密钥类型：

• K1 (secp256k1)：标准 Ethereum ECDSA
• R1 (secp256r1/P-256)：Passkeys 使用的曲线
• WebAuthn：完整的 Passkey 认证
• BLS：BLS12-381 签名（支持 rollup 的聚合）
• DELEGATE：指向另一个账户的配置（仅一跳）

空配置表示只有 EOA 密钥有效。EOA 密钥始终保留授权，无论其他密钥如何——这确保你始终可以恢复账户。

原生 Multisig

EIP-8130 包含协议层面的 multisig。设置一个 required_signatures 阈值，协议会在任何代码运行之前验证是否有足够多的不同密钥进行了签名。

一个 2-of-3 的 multisig 签名只是两个签名的拼接。协议解析它们，根据账户的配置验证每个签名，检查重复项，并确认满足阈值。没有智能合约开销，没有 EntryPoint 调用。

2D Nonces

与 Tempo 类似，EIP-8130 通过 nonce_key 字段支持并行 nonce 流。每个密钥都有自己独立的计数器。首次使用新 nonce key 需要 20,000 gas 进行初始化；之后，不同 nonce key 上的交易不会相互阻塞。

代币支付 Gas

这是 EIP-8130 比 Tempo 更具野心的地方。它不仅仅是 ETH 赞助，还包含一个完整的代币支付系统，有三种模式：

• 受权限控制的支付者：赞助商签署每笔交易，同意特定的汇率
• 无权限限制的支付者：注册的支付者配置每种代币的预言机；用户设置 max_amount 进行价格保护
• 原生支付者：由链操作的 AMM，具有链定义的定价

代币必须在 Token Payment Registry 中注册（余额槽位置、小数位数、黑名单方法）。代币转账发生在执行之前，在 EVM 之外——协议直接从存储中读取余额，验证黑名单状态，并原子性地更新余额。你的钱包代码在收到 calldata 时就知道 gas 已经支付。

为什么是每个支付者一个预言机而不是全局预言机？没有关于哪个预言机是规范的治理辩论，不良预言机只会影响该支付者的用户，支付者可以提供促销费率，发现发生在钱包层。max_amount 字段提供硬保护——如果成本超过你的限制，交易将失败。

迁移与上下文

现有 ERC-4337 账户无需重新部署即可迁移：

1. 在 precompile 中注册现有签名密钥
2. 更新合约以从 precompile 中读取密钥
3. 在执行期间使用 getCurrentSigner() 来了解哪个密钥授权了交易

在执行期间，合约可以查询 precompile 以获取上下文：哪个密钥签名了，谁支付了 gas，转移了多少代币。这使得可以根据使用的密钥做出授权决策，而无需重复签名验证。

权衡

你将获得：

• 简单、可优化的 mempool（仅限状态查找）
• 无需智能合约开销的原生 multisig
• 具有竞争性支付者市场的完整代币支付系统
• 可扩展的密钥类型（可稍后添加抗量子算法）

你将失去：

• 任意验证逻辑（没有自定义代码来决定交易是否有效）
• 需要验证阶段状态访问的隐私协议
• 后断言或条件执行

EIP-8130 介于 Tempo 和 EIP-7701 之间——比 Tempo 更灵活（原生 multisig、代币支付、可扩展密钥），比 EIP-7701 更简单（有界、可预测的验证）。

缩减范围的变体

EIP-8130 的一个缩减范围版本也被提议，将提案简化为其核心要素以加快发布速度。核心理念保持不变——受限验证、可编程执行——但两项主要功能被移出协议范围：

无原生 Multisig：代替协议级别的阈值验证，multisig 完全存在于钱包代码中。智能账户合约可以在合约代码本身中验证其他签名者，但其实现不属于规范的一部分。在执行期间，multisig 合约可以调用 getCurrentSigner() 来获取协议级别的密钥，然后拥有自己的逻辑来检索和验证其余密钥。

无 ERC-20 代币支付：Gas 赞助仅限 ETH。赞助商签署他们愿意支付的每笔交易——每笔交易的明确授权，而不是基于预言机的代币转换。该规范为未来的 EIP 保留了一个 extensions 字段以添加代币支付，但初始版本不包含此功能。

缩减范围的变体可以更快地发布和更简单地实现，但希望使用 multisig 或代币 gas 支付的钱包必须在自己的代码中处理它们，而不是依赖协议支持。对于优先快速部署核心 AA 功能的链来说，这是一个实用的起点，可以在以后进行扩展。

EIP-8141: Frame Transactions (1 月 29 日更新)

阅读完整提案

就在最初的提案被讨论几天后，Ethereum 基金会正式发布了 EIP-8141——将 Vitalik 的 EIP-7701 愿景具体化为一项具体规范。Frame Transactions 代表了“完全通用性”的路径，提供了一个从 ECDSA 密码学到任意签名方案（包括后量子系统）的原生退出通道。

哲学

EIP-8141 提出了与 Tempo 或 EIP-8130 不同的问题。它不是问“用户今天需要哪些特定功能？”，而是问“哪些基元可以让开发者构建用户可能需要的任何功能？”

答案是一种交易模型，其中验证和执行是完全可编程的。一笔交易变成了一系列“frames”——一些用于验证（谁授权了此操作？），一些用于执行（应该发生什么？）。协议强制执行顺序（验证在执行之前），但不对验证或执行逻辑可以做什么施加限制。

这是一种“一劳永逸”的设计：一旦发布，Ethereum 就不再需要通过硬分叉来添加新的签名方案、新的 gas 支付方法或新的交易模式。EVM 本身成为扩展机制。

它实现了什么

任何签名方案：账户可以使用任何密码系统验证交易——今天的 ECDSA，明天的 ML-DSA（后量子），用于隐私的 ZK 证明，或者尚未存在的方案。无需协议升级。

原生 Gas 赞助：赞助商可以通过添加自己的验证 frame 来同意支付一笔交易。协议确保赞助商只有在满足其条件（例如，用户向他们转账代币）时才支付。没有 bundlers，没有 relayers，没有受信任的中介。

无信任 ERC-20 Gas 支付：在赞助的基础上，用户可以在没有任何链下协调的情况下用 USDC 支付 gas。交易结构保证赞助商在用户调用执行之前获得支付——由协议强制执行，而不是通过信任。

一笔交易中部署账户：用户可以原子地部署其智能账户并执行其第一笔交易。部署 frame 首先运行，然后是验证 frame（现在账户已存在），然后是执行。

隐私协议支持：像 Tornado Cash 或 Railgun 这样的隐私系统需要在验证期间验证 ZK 证明。Frame Transactions 允许任意验证逻辑，因此这些证明可以无需 bundler 基础设施即可原生验证。

面向未来的可扩展性：签名聚合、keystore 钱包、后断言——尚未完全设计的功能可以在此基础上构建，而无需协议更改。

DoS 攻击向量及缓解措施

Frame Transactions 重新引入了核心 mempool 挑战：如果验证运行任意代码，攻击者可以制造最初通过验证但后来变得无效的交易，从而浪费节点资源。

攻击：攻击者提交数千笔交易，其验证依赖于某些共享状态（例如，检查 block.timestamp < deadline）。当截止日期过去时——或者当攻击者修改共享状态时——所有交易同时失效。节点浪费了计算来验证和存储它们。

缓解措施 1：验证限制。规范建议像 ERC-7562 处理 ERC-4337 验证一样处理验证 frames：限制哪些 opcode 可以运行，限制哪些存储槽可以读取，限制 gas 消耗。这使得验证“本地化”——你的交易的有效性仅取决于你自己的状态，而不是其他人可以修改的共享状态。

缓解措施 2：有界验证。验证 frames 必须在交易进入 mempool 之前明确成功（通过 APPROVE opcode）。节点可以拒绝验证失败或超出限制的交易，然后再将它们传播到对等节点。

缓解措施 3：每个账户一个待处理交易。与 EIP-7702 类似，节点可以将每个账户限制为一笔待处理的 frame 交易。这限制了失效造成的损害——每个攻击者账户最多一笔交易被逐出。

缓解措施 4：已知部署者工厂。对于在执行中部署账户的交易，mempool 只接受来自白名单工厂合约的部署。这确保了部署是确定性的，并且不依赖于可操作的链状态。

关键洞察：协议提供完全通用性，但 mempool 可以施加更严格的规则。高级用例（自定义验证、异构签名）可能需要直接提交给区块构建者，而不是公共 mempool 传播。

权衡

你将获得：

• 完全通用性——任何签名方案、任何验证逻辑、任何 gas 支付方法
• 无需未来硬分叉的原生后量子支持
• 基本用例无需外部基础设施（bundlers、relayers）
• 足够灵活的基础，可用于尚未存在的用例

你将放弃：

• 协议复杂性——新 opcode、新交易类型、frame 语义
• Mempool 复杂性——节点需要复杂的验证规则来防止 DoS 攻击
• 比简单替代方案更高的基本成本（固有 15,000 gas，而传统约 21,000 gas，但每个 frame 有更多开销）
• 与固定功能方法相比，钱包开发人员的学习曲线更陡峭

EIP-8141 是“最终解决方案”方法。它不直接解决特定的 UX 问题——它提供了足够强大的基元来解决任何 UX 问题。代价是必须通过工具、标准和仔细的 mempool 实现来管理的复杂性。对于 Ethereum 的长期发展，特别是后量子就绪性和 ZkEVM 兼容性，这种通用性可能是必要的，无论短期成本如何。

哲学

Vitalik 的提案 (EIP-7701) 优化了最大的通用性和健壮性。目标是通过“一劳永逸测试”——构建一个如此完整的框架，以至于 Ethereum 不需要持续的硬分叉来添加新的交易功能，因为新的用例不断涌现。它旨在成为账户抽象的“最终解决方案”，足够灵活以处理我们尚未想象到的用例。代价是复杂性：复杂的 mempool 规则、多个交易阶段以及更广泛的协议范围。

Tempo 优化了发布速度。行业现在就需要更好的用户体验——用户今天正在为 gas、签名和交易复杂性而苦恼。Tempo 选择了特定的问题（Passkeys、批处理、调度、赞助），并通过最少的协议更改来解决它们，这些更改可以快速发布。没有自定义验证，协议层面没有代币支付，没有 multisig——只有解除最常见痛点所需的基元。

EIP-8130 优化了快速发布强大功能。与 Tempo 类似，它认识到用户现在就需要更好的用户体验，行业不能等待多年才能获得完美的解决方案。但它更有野心：原生代币支付、multisig 和可扩展密钥类型——这些功能对实际钱包采用至关重要。通过将验证限制为固定密钥类型，它使 mempool 足够简单以快速发布，同时仍能提供有意义的功能。缩减范围的变体牺牲了一些功能（协议级 multisig 和代币支付）以实现更快的发布。

EIP-8141 (Frame Transactions) 是 EIP-7701 愿景的具体化和可实现规范。它代表了 Ethereum 基金会对完全通用性路径的承诺——任意验证逻辑、后量子就绪性，以及对账户可以做什么不施加人为限制。frame 模型提供了结构（验证在执行之前，明确的批准语义），同时不牺牲权力。Tempo 和 EIP-8130 问“用户今天需要什么？”，而 EIP-8141 问“未来十年用户需要什么？” 权衡是显而易见的：更复杂的协议和更严格的 mempool 要求，但它提供了一个基础，随着密码学的演变和新用例的出现，它将不需要替换。

补充：EIP-7851 (停用 EOA 密钥)

阅读完整提案

虽然上述提案侧重于启用新的交易功能，但 EIP-7851 解决了另一个问题：在通过 EIP-7702 迁移到智能账户后，永久禁用 EOA 的 ECDSA 私钥。

这样做的动机是后量子安全性。一旦量子计算机变得可行，ECDSA 密钥将容易受到 Shor 算法的攻击。已迁移到具有抗量子验证（通过 EIP-7701/8141 启用，或 Tempo/EIP-8130 中的受限方案）的智能账户的用户，其旧的 ECDSA 密钥仍将是后门。EIP-7851 允许他们永久关闭这个后门。

该机制是一个预编译，它在委托代码后附加一个标记字节，向协议表明 EOA 密钥已停用。7 天的延迟期允许通过 ECDSA 签名交易取消——为防止未经授权的停用提供了安全窗口。

当前限制：EIP-7851 仅阻止链上 ecrecover 对已停用的密钥生效。它不会使链下签名失效。使用 ERC-2612 permit、ERC-712 类型签名或其他链下签名模式的合约仍将接受来自已停用密钥的签名，除非它们明确检查账户的停用状态。这是一个已知的差距——该提案需要一个配套 EIP 来修改 ecrecover 行为以实现全面保护。

EIP-7851 是原生 AA 提案的补充，而非竞争。它解决了用户迁移到智能账户后仍然存在的“遗留密钥”问题，无论采用哪种 AA 方法。

• 原文链接： blog.biconomy.io/native-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～