Frame Transactions 的论证：灵活的基础与强大的默认功能

原生 AA 正在成为以太坊历史上最具争议的话题之一。核心开发者们已经尝试了至少六个相互竞争的 EIPs，并两次未能就某个特定提案做出决定，第三次尝试计划于本周四进行。

在这篇文章中，我想为 Frame Transactions（EIP-8141）提出论据。我认为 Frames 为支持 AA 用例提供了最灵活的基础，并且对它主要的担忧——它可能给开发者带来的复杂性——可以通过强大的默认设置来解决，从而简化常见的工作流程。我还将拓展视野，解释为什么现在是以太坊开始着手原生 AA 的合适时机。

Frame Transactions 是当下和未来用例的灵活基础

在设计 AA 协议时，大多数 EIPs 都采用“自上而下”的方法：

• 识别一组作者认为价值最高的 AA 用例。
• 设计一个支持这些用例的协议。

虽然这种方法很直观，但它受到两个限制：

• 决定哪些 AA 用例子集最重要，这本身就是主观的。用稳定币支付 Gas 重要吗？私密发送交易重要吗？多重签名重要吗？事实上，当你比较大多数将自己定位为 Frames 替代方案的 AA 提案时，你会发现它们支持不同的用例子集。但谁能说哪个子集是正确的呢？
• 围绕当前用例设计的提案注定会错过未来的用例。例如，随着 ZK 技术飞速发展，我们看到了一波可以实现私密交易的隐私协议浪潮——但当前的 AA 提案很少考虑到这些用例。

另一方面，Frame Transactions 采用的是自下而上的方法。它首先提出问题：最小的一组基本原则（可以想象成乐高积木），当它们组合在一起时，如何能够实现最大数量的 AA 用例？

Frames 令人惊讶的洞察力是，为了支持我们今天所知道的所有 AA 用例——以及我们尚未知道的用例——你只需要三个基本原则：

• 一笔交易由一系列合约调用组成，我们称之为“帧”（frames）。
• 一个帧可以对交易进行认证和/或支付 Gas。
• 一个帧可以自省（introspect）其他帧。

为了理解这些看似简单的基本原则如何实现强大的 AA 功能，让我们看一个在其他 AA 提案中很少支持的具体示例：用 ERC20 Token 支付 Gas。

案例研究：用 ERC20 Token 支付 Gas

假设用户拥有一些 USDC 但没有 ETH。在当今世界，用户必须以某种方式获取 ETH，但他们甚至无法将 USDC 兑换成 ETH，因为他们首先需要 ETH 来进行该交易。

使用 Frame Transactions，用户无需依赖中心化的中继者即可用 ERC20 Token 支付 Gas。这样的交易将包含五个帧：

• 验证发送方：调用用户账户以验证签名，然后批准交易。
• 验证 Gas 支付方：调用 Paymaster 合约，该合约自省下一个帧以确认用户正在将 ERC20 Token 转移到 Paymaster，然后批准交易的 Gas 支付。
• 支付 Gas 支付方：调用 ERC20 合约以将 Token 转移到 Paymaster。
• 执行目标操作：调用目标合约以执行用户意图的操作。
• 退还未使用的 Gas：调用 Paymaster 合约以将未使用的 Gas 退还给用户。

请注意这个流程如何利用所有三个基本原则：

• 交易生命周期被分解为五个步骤（帧），所有步骤都由智能合约执行。协议中无需硬编码任何逻辑。
• 帧 1 认证交易。
• 帧 2 自省帧 3，以确认用户正在将 ERC20 Token 转移到 Paymaster，并且只有在满足该条件时才批准 Gas 支付。

支持这种工作流程需要在交易发送方和 Gas 支付方之间进行精心协调，这就是为什么将这种机制硬编码到 AA 协议中很困难的原因。然而，凭借 Frames 灵活的架构，无需进行硬编码。通过组合这三个简单的基本原则，这种复杂的用例自然而然地出现了。

灵活性是祸害吗？

对 Frames 的一个常见反对意见是：它的灵活性实际上是一种祸害，因为它给下游开发者带来了复杂性。例如：

• 使用 Frame Transactions 的钱包可能需要将它们的安全性委托给智能合约。
• 交易验证从一个简单的 O(1) 操作（检查签名）转变为执行任意 EVM 代码，这为 L1 和 L2 的 mempools 引入了新的 DoS 向量。

这些是 Frame Transactions 早期版本中存在的合理担忧，也正是我与 EIP 共同作者们共同的担忧。然而，在过去的一个月里，我们一直在努力解决这些问题。解决方案可以用一个想法来概括：强大的默认设置。

强大的默认设置

钱包的默认账户

根据我们使用 ERC-4337 的经验，AA 普及的最大障碍来自两个方面：

• 现有的 EOA 用户不想迁移到新账户，无论用户体验（UX）有多大好处。
• 钱包不想通过依赖智能合约引入新的攻击面。

通过最新迭代的 Frame Transactions，我们用一个强大的想法解决了这两个问题：EOA 的默认账户。当 EOA 发送 Frame Transaction 时，它被视为通过一个“默认智能账户”进行操作，其安全性由协议保证。这个默认智能账户支持典型智能账户的核心流程，而无需钱包信任新的智能合约。

默认账户还可以支持除 k1 之外的 EOA——它还可以支持其他签名方案，例如 Passkeys (r1)。这意味着钱包甚至可以在不信任新智能合约的情况下支持非 k1 密钥，从而显著降低采用新签名方案的门槛。

Mempools 的规范帧结构

Tempo/Monad 等高性能 L1 和 Base 等 L2 的开发者们提出了担忧，他们担心将交易验证（通常只是签名检查）转变为任意 EVM 执行。这使得同时保持高吞吐量和 mempool 安全性变得更加困难。

答案再次是默认设置——特别是 Mempools 可以依赖的规范帧结构。例如，虽然验证帧理论上可以出现在交易的任何位置（甚至在末尾），要求 Mempool 节点执行完整的交易来验证它，但默认结构要求交易以验证帧开头才能被安全接受。

为了进一步限制验证成本，链可以实现一个最大验证 Gas 限制，限制 Mempool 节点每笔交易必须执行的 EVM 代码量。对于优先考虑最大吞吐量或安全性的 Mempools，它们可以更进一步，仅支持默认账户，该账户具有已知且受限的验证成本。

默认设置可以被覆盖，但基础不能被重建

对默认设置的一个自然的反驳是：如果默认设置如此之好，为什么不直接将其“神圣化”（enshrine）呢？事实上，许多 AA 提案实际上等同于“神圣化”Frames 的默认账户和验证结构，因此享受了仅支持狭窄用例集所带来的简单性。

但这正是 Frames 更好的设计所在。对于常见用例，默认设置效果很好，Frame Transactions 使用起来超级简单。但对于更高级的用例，开发者可以自由地构建定制的工作流程以满足他们的需求。

当以太坊提供一个灵活的基础时，开发者可以根据需要创建新的解决方案。但当基础本身是僵硬的，这种灵活性就丧失了，开发者别无选择，只能等待下一次硬分叉，如果他们的用例没有被支持的话。如果我们选择一个僵硬的 AA 提案，那将是不幸的现实。

为什么现在是原生 AA 的时候

很容易看待当前 AA 提案的现状并说：“为什么不再等一次硬分叉呢？”当然，到下一个周期，我们将会学到更多并达成一个完美的设计。

一个反对这一观点的理由很简单：我们已经争论 AA 多年了，没有理由相信下次会更容易做出决定。

更重要的是，在更广泛的以太坊路线图内，目前有三项主要工作正在积极进行，它们与原生 AA 具有很强的协同作用。再次推迟 AA 将意味着错失共同开发这些系统的机会。这些工作包括：

• 通过 FOCIL 实现抗审查
• 通过 VOPS 实现无状态化
• 量子抵抗

虽然深入探讨超出了本文的范围，但值得注意的是，Frames 在 AA 提案中是独一无二的，它经过了所有这三个领域的研究人员的审查，并被发现与它们在架构上兼容。这里有一个 FOCIL + Frames 的例子。

当然，这些交互的细节仍需解决，但这正是重点所在。我们现在就应该开始，并与这些机制并行开发原生 AA，这样 AA 才能被这些重要机制视为一等公民，而不是事后才附加的东西。

结论

Frame Transactions (EIP-8141) 是以太坊 AA 标准的最佳候选者，因为它是唯一一个提供灵活基础的提案，可以支持所有 AA 用例，同时为最常见的 AA 工作流程提供强大的默认设置。此外，它与以太坊路线图的其他领域（包括隐私、抗审查、无状态化和量子抵抗）具有极好的协同作用。将原生 AA 引入以太坊的最佳时机就是现在，而 Frame Transactions 是我们最好的选择。

• 原文链接： x.com/decentrek/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～