账户抽象之路——过去、现在和未来方向

协助EOA的进展：账户抽象之路

过去：我们开始的地方

三年前（2021 年）Vitalik提出了一种新的账户抽象模型，我们团队开始集思广益，目标是在不牺牲去中心化和审查制度的情况下实现完整的 AA（抽象账户的所有方面：身份验­­­­证、授权、重放保护、gas 支付、执行）， 后来成为ERC-4337。

棘手的情况比我们预想的还要深。抗审查需要一个无需许可的内存池，但完整的 AA 会带来大量 DoS 向量，这使得这成为一个挑战。

我们很快意识到我们需要将验证与执行分开，然后在验证期间应用某些限制。 EOA 自然地做到了这一点，并且具有非常严格的验证规则（对不可撤销密钥进行一次 ECDSA 签名检查、一项随机数检查、一项余额检查，没有外部依赖性）。我们希望 AA 能够启用尽可能多的用例，同时保持 DoS 抵抗力，并且不诉诸白名单等许可方法。

以防止廉价的 DoS该过程首先要找出验证规则。但到达了那里的限制非常严格。接下来是更难的部分——找出可以安全做出哪些例外，从而在不引入DoS向量的情况下启用更多用例。这最终产生了ERC-7562。这些规则是从 ERC-4337 中提取的，以便启用不使用内存池（例如意图）的 AA 用例，并支持不使用 ERC-4337 的 AA 的本机形式。

现在：我们现在在哪里

ERC-4337 于 2023 年 3 月在所有主要 EVM 网络上推出，并受到用户和开发人员的关注。截至撰写本文时，已部署 410 万个帐户并发送了 1820 万个 UserOps，并且基于 ERC-4337 构建了一个蓬勃发展的项目生态系统。

积累的数据揭示了有关用户如何使用 AA 的一些见解。特别是，绝大多数 UserOps 使用 Paymasters，这表明我们将 Gas 抽象作为核心功能的设计选择是正确的。

我们最近发布了 v0.7，我们希望这是最后一个重大更改。

mempool 本身（p2p 网络）已在测试网上启动，并有多个捆绑器实现参与，但尚未在主网上上线。作为一个多客户端架构（就像以太坊本身一样），它需要大量的互操作和压力测试。主网上的捆绑器目前作为私有内存池运行，但随着内存池上线，这种情况很快就会改变。

在过去几年中，我们发现存在对 ERC-4337 协议级版本的需求。一些 L2 网络（例如zksync 的本机 AA）实现了自己的版本。这不可避免地导致钱包碎片化，一些钱包只能在某些网络上运行。我们意识到 L2 链中的某些事情需要标准化 - 不仅仅是 AA，并启动了 RIP（Rollup Improvement Proposals，又名 RollCall）流程来促进这一点。从那时起，我们一直致力于RIP-7560，这是 L2 链的 ERC-4337 的本机版本。

未来：我们前进的方向

Native AA - 模块化路线图

我们当前的重点是一组 RIP，以帮助 L2 链迁移到本机 AA。 RIP-7560 最初是一个整体式 RIP，但它不会一直保持那样。我们已经将其剥离至最低可用形式，将其部分移动到单独的可选 RIP。 这些PR目前仍处于早期草案，但将在不久的将来作为 RIP 发布。

一些已被移出的东西：

·      任何执行之前的所有验证- 单序列器汇总不需要，但强烈建议在去中心化链上进行，以确保 DoS 抵抗力，如果使用聚合，则必须进行验证。

·      2D nonces - 不是强制性的，但支持多租户帐户、并行化和其他用例。

·      聚合- 支持签名聚合以及高级用例，例如意图求解器的事务原子性。

·      所有 EOA 相关扩展- 逐步向 EOA 添加某些 AA 功能，并最终将 EOA 迁移到 AA。

·      当包含 EOF 时，摆脱 ABI成为可能。

邀请 L1 核心开发人员、L2 开发人员和整个社区进行协作并提供反馈。

L1

路线图主要关注 L2，但在以太坊 L1 上实现AA 也很有价值。

我们预计这将需要更长的时间，但不应延迟 L2 的采用。 RIP-7560 和提取的 RIP 与 ERC-4337 账户模型兼容，因此可以在不同的链上部署相同的账户，其中一些在本机工作，一些使用 ERC-4337。以太坊 L1 可能会继续使用 ERC-4337 更长的时间，而 L2 链则逐渐转向 RIP-7560，但用户和项目在两者上的工作方式是相同的。 ERC-4337 和 RIP-7560 可能会并存多年，直到迁移完成。

RIP-7560 必须做出的一项权衡（可能不适合 L1）是对 Solidity ABI 的依赖。理想情况下，EIP 应避免依赖于可靠性，而 L1 上的情况大多如此（存款合约除外，它引入了可靠性依赖来质押共识层）。 L2 链不会尝试避免这种依赖性，并且大多数都使用带有 ABI 的预编译/预部署。

实现 RIP-7560 的一种更简洁的方法是使用 EOF，并将 ABI 留给更高的抽象层（例如，solidity）。然而，正如我们在上面看到的，一些 L2 链不会等待 L1 包含 EOF，并希望更快地实现 AA。因此，RIP-7560 目前使用 ABI。

L1 不太可能做出同样的权衡，并且有更长的时间范围来引入原生 AA 等功能。对于 L1，有RIP-7560 的 EOF 版本，它将协议侧和面向用户的侧之间进行清晰的分离。该工作仍在进行中，但我们将不胜感激 EOF 开发人员的反馈。

我们如何在此期间协助执行EOA

一直以来都有在 EOA 中添加某些 AA 功能的需求。尽管目标应该是完整的 AA，而不是进一步体现 EOA，但对批处理和气体提取等功能的需求是显而易见的，并且最近围绕 EIP-3074 的争论充分证明了这一点。

路线图并没有忽视这一需求，但这些功能应该作为引导我们实现 AA 的战略的一部分添加，而不是对 EOA 进行临时改进并引入未来的技术债务。

通过从 RIP-7560 中提取的EOA 扩展 RIP，使用与上述其他 RIP 使用的相同 TransactionType4 的 EOA 可以使用许多 AA 功能。与立即采用 EIP-3074 相比，它具有一些优势：

·      与原生 AA 路线图一致。钱包不需要支持两种标准。

·      使 EOA 能够使用现有的出纳员。付款人并不关心发件人是 EOA。

·      对于大多数常见用例，需要的信任度低于 EIP-3074。 Gas 提取和批量处理不需要委托具有完全帐户访问权限的合约。因此不需要白名单。

·      使用付款主管启用 EOA 迁移到 AA（而不是EIP-7377）。

·      启用 EOA 签名聚合（与聚合 RIP结合），这可以节省大量的汇总网络费用。

·      无需继电器或特制的 4337 调用器。 EOA 将使用 AA 内存池。

·      当我们转向抗量子签名时，不会引入进一步的技术债务，这会减慢我们的速度。

作为中间步骤，该 RIP 也可以在没有 RIP-7560 的情况下采用，因此它不会引入本机 AA，但使用相同的事务类型，因此与其向前兼容。这会将 EOA 纳入 AA 路线图，而不是启动并行改进路径。