以太坊账户抽象之争：EIP-8130 与 Frames 的简洁性与可扩展性权衡

几个月前，我发表了一篇对比 Tempo Transactions 与 Frame Transactions（EIP-8141）的文章。自那以后，核心开发者社区在很大程度上因僵化而拒绝了 Tempo 风格的 AA 提案，转而拥抱更灵活的 Frames。

最近，Base 发布了其 AA 提案——EIP-8130，并已正式提交给 L1 审议。这重新点燃了 AA 之争，这一次是在 8130 和 Frames 之间展开，双方都有知名人士支持。

在 Ethlabs，我们一直在与两项提案的共同作者深入交流，以理解他们的观点并寻找共同点。在这篇文章中，我想概述当前这场辩论的现状，呈现双方的观点，并分享我自己关于 ACD 应如何在这两项提案之间做出抉择的想法。

为什么 L2 担心 Frames

L2 希望扩展规模——提供高 TPS。然而，frame transactions 很难扩展，因为它们需要用 EVM 代码进行验证，而执行这些代码所需的 gas 数量未知（甚至可能是无上限的）。这与普通交易形成鲜明对比，后者只需验证签名即可完成验证，成本已知且有界。

此外，由于验证代码可以访问任意状态，如果所访问的状态发生了变化，节点必须小心地重新验证交易。因此，节点必须追踪 frame transaction 的验证阶段，以识别它触及了哪些状态，这给高性能 L2 带来了额外的性能损耗。

为什么 L1 担心 8130

为了规避上述问题，8130 维护了一个 "authenticators" 白名单（又称 "canonical set"），这些 authenticator 是实现常见签名方案（如 k1 和 r1（passkeys））的合约。账户在一个 "keystore" 合约中注册它们的 authenticator，这样节点只需查找账户的 authenticator 就能知道验证交易的成本是多少，甚至可以用原生代码优化验证过程。由于 authenticator 只负责验证签名，它们是不访问状态的“纯函数”，因此交易一旦通过验证就无需重新验证。

然而，这种方案并不适合 L1，因为 L1 希望实现无许可创新——任何人都应该可以自由开发自己的账户。这包括 multisig、PQ、私密交易以及其他新颖的认证方案等用例。要求不断进行硬分叉来支持新的认证方案，对 L1 来说是不可接受的。

两项规范如何演进

近几周以来，两项规范都在不断演进以解决各自的不足。

在 Frames 一侧，得益于来自 L2（主要是 Base 和 Arbitrum）的反馈，共同作者们一直在研究一种“纯函数验证”方案，允许签名由纯函数——即不访问任何状态的合约——来验证。这些纯函数类似于 8130 的 authenticator——它们可以通过地址识别、成本有界，并且可以用原生代码优化。这将使 L2 能够以可预测且有界的成本验证 frame transactions。

在 8130 一侧，共同作者们在规范中增加了一个 "L1 profile"，允许采用 L1 profile 的链（例如 Ethereum）支持 "non-canonical authenticators"，即具有任意逻辑的 authenticator。使用这样的 authenticator 当然会削弱 8130 的许多优势，但它为 L1 提供了一条支持无许可账户实现的路径。

仍然存在的根本差异

随着 Frames 实现 8130 风格的 authenticator，以及 8130 支持 L1 profile，这两项规范正在趋同。但仍存在一些根本性的差异：

跨链可移植性

8130 在跨链可移植性方面有一套完整的方案——即使在不原生支持 8130 的链上，8130 账户也能工作，在这种情况下，8130 交易将通过 ERC-4337 bundlers 和 paymasters 进行中继。

虽然 8141 也可以做到同样的事情，但其设计尚未规划。这是一个工程上的差距，而非根本性的差距。

内嵌账户 vs 纯粹的 AA

8130 实际上是两个规范合二为一——底层思想是通过 authenticator 验证交易，在此之上还有一个完整的账户标准，包含 policies（session keys）、actors、locks 等概念。简而言之，采用 8130 后，所有账户都将具有相似的结构，因此围绕它构建钱包和工具会更容易，但账户的演进会更困难，因为它将需要更多的硬分叉。

另一方面，8141 专注于 AA 本身——它只提供构建账户的原语。协议本身对账户的逻辑不做任何限定。这为账户的创新和多样性开辟了更多空间，但也带来了更多碎片化的可能性，而这实际上是同一枚Coin的两面。

结构化 vs 非结构化验证

8141 与 8130 最根本的区别在于交易的结构方式，或者更准确地说，是验证相对于执行必须发生在什么时机。

在 8130 中，验证是结构化的——先进行验证，然后执行。这非常自然，并将简化围绕它构建的工具。

在 8141 中，验证是非结构化的——验证可以在交易期间的任何时刻通过任何 frame 发生。这意味着从技术上讲，你可以先执行交易，然后再验证它。这开启了一些强大的用例：账户一开始没有 ETH，但在执行过程中获得 ETH，最后用这笔 ETH 支付 gas。例如：

假设你有一个持有一些 memecoin 但没有 ETH 的账户。你可以发送一笔交易，在执行过程中把 memecoin 兑换成 ETH，然后支付这笔交易的费用（验证）。

类似地，假设你有一个没有 ETH 但在某些 DeFi 协议中存有 ETH 的账户。你的交易可以先执行，从 DeFi 协议中取出 ETH，然后最终支付这笔交易的费用（验证）。

简而言之，非结构化验证为没有 ETH 的账户开启了用任意逻辑支付交易费用的用例。

然而，非结构化验证也有一个注意事项——它们无法在公共 mempool 中得到安全支持，因为依赖执行的验证很容易因链上状态的变化而失效。这就是为什么 8141 引入了额外的 mempool 规则来约束验证结构。因此，在实践中，上述这类非结构化验证的用例必须通过私有 mempool 和 builder API 来支持。

决策的关键所在

简而言之，我认为在 8130 和 8141 之间的选择归结为：

如果我们更看重简洁性和更少的碎片化，我们应该采用一种看起来像 8130 的方案。

如果我们更看重可扩展性和更多的多样性，我们应该采用一种看起来像 8141 的方案。

请注意，我说的是“一种看起来像 8130/8141 的方案”——我想把方案与 EIP 编号区分开来，因为任何 EIP 最终都可能采用任何方案，我们甚至可能最终得到一个综合这些方案的全新 EIP。因此，我的论点是针对具体方案的，而不是针对具体的 EIP 编号。

从历史上看，Ethereum 更倾向于 Frames 的理念——协议提供最大的灵活性，而应用层进行创新和竞争。然而，值得思考的是，作为 Ethereum UX 基础的账户层，是否应该从协议本身获得更多的引导和结构。

前进之路

在 Ethlabs，我们认为，在演进诸如账户这样的基础 EVM 构件时，我们不能只为 L1 的需求做优化，而应听取其他利益相关方（如钱包和 L2）的反馈。这是因为我们相信 Ethereum 极大地受益于 EVM 的网络效应，所以我们应该致力于维护一个紧密且兼容的生态系统，只有在满足 L1 和 L2 独特需求确有必要时才偏离这一目标。

关于当前的辩论，我建议 ACD 采取以下两种路径之一：

如果我们作为一个社区认为简洁性比可扩展性更重要，我建议我们采用 8130 基于 keystore 的验证方案，但将其内嵌的账户标准剥离出来，放入一个单独的 ERC。这样一来，Ethereum 和 L2 都能受益于结构化验证的简洁性，同时为新类型账户的发展留出空间。

如果我们作为一个社区认为可扩展性比简洁性更重要，我建议我们继续基于 frames 构建，但我们必须完成“纯函数”工作流（或类似的想法），使 L2 能够支持 frames 而不牺牲验证性能，并且最好还能制定出类似 8130 的跨链可移植性方案。

AA 之争正在考验 Ethereum 去中心化治理模式的极限，但我相信，我们正走在再次证明社区能够团结一致、交付雄心勃勃的更新、让 Ethereum 变得比以往更好的道路上。我和 Ethlabs 的同事们本周将参加 AA breakouts 和 ACDE，参与这场讨论；希望在那里见到大家！

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