Vitalik：以太坊账户抽象之路

账户抽象允许我们使用智能合约逻辑来指定交易的效果，以及费用支付和验证逻辑。 这带来了许多重要的安全优势，例如多重签名和智能恢复钱包、无需更改钱包即可更改密钥的能力以及量子安全性。

许多帐户抽象的方法已经被提出并在不同程度上实施，参见：EIP-86、EIP-2938 和两年前的这篇论文。 如今，由于开发人员希望专注于合并和分片，这些 EIP 的开发已经停滞，而 ERC-4337‌，一种不需要任何共识更改的替代方案，已经取得了很大进展。

ERC-4337 试图通过附加的协议手段来达到与 EIP-2938 相同的目的。 用户需要发送称为用户操作的链下消息，这些消息由块提议者或为块提议者生成捆绑包的构建者批量收集并打包成单个事务。 提议者或建设者负责过滤操作，以确保他们只接受付费的操作。 用户操作有一个单独的内存池，连接到该池的节点会执行特定于 ERC-4337 的验证，以确保用户操作在转发之前得到支付。

ERC-4337 作为一个纯自愿的 ERC 可以做很多事情。 然而，它在几个关键领域弱于真正的协议内解决方案：

- 如果不将所有资产和活动转移到新帐户，现有用户将无法升级；

- 额外的gas开销（基本UserOperation用户操作约42k，而基本交易约21k）；

- 较少受益于协议内抗审查技术（例如 crLists），该技术针对交易并错过用户操作

实现最佳结果的现实途径是从短期内大力支持 ERC-4337 开始，然后随着时间的推移添加 EIP 以弥补其弱点。 这并不一定要求每个人都特别承诺遵守 ERC-4337。 相反，协议内支持可以设计得更通用，并支持 ERC-4337 及其替代方案和改进。

在这里，我将列出其中一些 EIP，并说明它们可以按什么顺序实施。

将 EOA 钱包转换为智能合约钱包

为了将现有的 EOA 钱包升级为 ERC-4337 钱包，我们可以制作一个允许 EOA 执行设置其合约代码的操作的 EIP。 一旦 EOA 实现了这一点，转变就不可逆转。 此后，该账户将仅作为智能合约钱包使用。 幸运的是，由于 ERC-4337 账户是 DELEGATECALL 代理，如果需要，钱包可以稍后转换为其他 ERC 兼容的智能合约。

关于如何实施此升级过程，有一些建议：

1.“替换码”交易类型

这还没有作为官方 EIP 引入，但方法很简单：添加一个新的 EIP-2718‌ 交易类型，只需将 account_code 替换为 calldata 即可。

2. AUTH_USURP (EIP-5003)

EIP-5003‌ 是 EIP-3074‌（AUTH 和 AUTHCALL）的扩展提案，它引入了新的 AUTHUSURP 操作码。 如果使用 EIP-3074 机制，EOA 地址 A 已授权另一个地址 B 代表其行事以太坊合约地址和帐户地址，则 AUTHUSURP 允许 B 设置 A 的代码。

这种方法比“替换代码”路线更复杂，只有在我们打算采用 EIP-3074 时才有意义。

强制转换

从长远来看，我们可能希望进行强制转换以简化协议并使合约成为唯一的账户类型，从协议中删除 ECDSA。 一种可能的方法是添加覆盖规则，从某个区块开始，没有代码的账户被视为具有特定标准化“ERC-4337 EOA 钱包”代码的账户。

这可以通过“戳”的过程来完成，在这个过程中，任何源自 EOA 的交易都会对其进行转换，并且任何接触具有非零随机数的 EOA 的交易都会对其进行转换。 也可以通过一次遍历整个状态来完成。

问题

合约内 ECRECOVER 验证：一些智能合约依赖于这样的假设，即如果您向特定账户提供 ECRECOVER 的签名，您就拥有该账户。 如果将 EOA 转换为合约，然后更改其验证密钥，则原始密钥仍将能够“代表”这些特定上下文中的帐户。 这可以通过开始鼓励所有此类项目更改为使用 EIP-1271 验证而不是 ECRECOVER（如果帐户有代码）来完成。

尚未检测到的账户：转换的一个挑战是拥有资产（如 ERC20、ERC721，但不包括 ETH）但尚未发送或接收任何交易的账户，因此协议无法可靠地检测到这些。 该协议必须保留将此类帐户永久转换为默认钱包的能力，或者需要有一个截止日期（例如部署后 4 年），在此之后未转换的帐户将被销毁。

EOA 仅检查不可转让性：一些应用程序实施合同内检查以仅允许 EOA 与其交互。 这通常是为了强制执行非分配。 这从根本上说是一个坏主意，并且与转向智能合约以提高安全性的目标不相容。 因此，不应鼓励这种做法，应鼓励应用程序依赖原所有者恢复程序，使转让无法进行。

降低燃气成本

ERC-4337 钱包面临更高的 gas 成本（基本 ERC-4337 操作大约需要 42,000 gas，而基本常规交易需要 21,000 gas），原因如下：

1. 你需要付出大量的个人存储读/写成本。 在 EOA 的情况下，这些成本将被捆绑到一次支付 21000 gas 中：

(1)编辑包含pubkey+nonce(~5000)的storage slot；

(2) 用户操作调用数据成本（约4500，可通过压缩降低至约2500）；

(3) 恢复 (~3000);

(4) 首先访问钱包本身 (~2600)

（5）首次访问收款人账户（~2600）

(6) 将ETH转入受益人账户（~9000）

(7) 编辑存储支付费用（~5000）

(8) 访问包含代理的存储槽(~2100)，然后访问代理本身(~2600)；

2. 除了上面的存储读/写成本，合约还需要执行“业务逻辑”（解包UserOperation，散列它，shuffle变量等）

3.需要消耗gas支付日志费用（EOA不发布日志）；

4. 一次性合约创建成本（约32,000 gas，代理中每个代码字节加200 gas，代理地址设置加20,000 gas）

其中许多问题将在 Verkle 树见证 gas 成本 EIP 和编写 gas 成本改革 EIP 中自动解决，用更精简的系统取代大量存储成本。 例如，pubkeys 和 nonces 可以存储在 slot 0…63 中，这将它们的访问成本降低到 1000 以下。用户在转移 ETH 和支付费用时将支付更少的费用，因为目标账户和接收账户只需访问一次第一次。

还有更多的 EIP 可以帮助我们简化。 例如：

禁用智能合约逻辑使用 slot 0 的自愿 ERC 将允许它用于存储代理，从而使其从更便宜的 gas 成本中受益。

“代码地址”字段可以使代理更容易并且消耗更少的气体。

“snappy compression”预编译使得使用 ABI 对象变得更容易，而无需为所有零字节支付 calldata gas 成本。

这是一个需要更多研究的领域。

cr列表

这是一个长期的问题，因为 crLists 只有在启用完整的协议提议者/构建者分离方案时才真正适用。 挑战在于我们希望提议者能够识别“值得”包含的用户操作（即他们支付足够的费用），以便协议可以强制将它们包含在有空间的下一个块中。

这就要求在协议中明确“验证”和“执行”的概念。 对于用户操作，必须有一个定义的方法来验证该操作，以及一个定义的方法来执行该操作，这样如果一个操作被验证，则尝试执行该操作将保证支付，除非在验证期间修改了读取状态. 这些操作可以通过嵌入 ABI 方法来实现，或者如果实现了 EOF EIP，则可以通过添加专用的 EOF 部分来实现。

幸运的是，这并不要求我们将 ERC-4337 视为最终标准，而是合并了一个由 ERC-4337 支持的较弱的概念，该概念可以很容易地得到其他截然不同的 ERC 的支持。

原因是 ERC-4337 和 EIP-2938 的复杂性在很大程度上与解决更强的 DoS 抵抗问题有关：不可能让一个操作取消数百个其他操作，因为这将允许 mempool 的廉价垃圾 Transactional攻击。 这需要对帐户验证可以访问的内容施加限制。 在这里，我们可以做一些更简单的事情：只记录在验证期间触摸了哪些状态对象，如果这些状态对象中的任何一个被编辑则不需要包括在内。

这允许个人账户在审查抵抗和灵活性之间选择自己的权衡。 在极端情况下，如果账户愿意，可以在验证期间通过 Uniswap 支付费用，但由于任何人都可以发送影响 Uniswap 状态的交易，因此此类账户实际上没有抗审查保证。

crList设计的大致轮廓如下：

提案可以包含一个 crList，它指定要包含的操作列表，以及每个操作读取的状态对象（键、值）对列表。 接受 crList 的构建器（或其他任何人）必须检查所有操作是否通过验证检查。

该块需要执行 crList 中的每个操作，除非该块没有足够的 gas 剩余，或者执行时的当前状态已经编辑了该操作读取的状态对象之一。

ERC-4337 的剩余复杂性将仅用于内存池安全。 原则上，可以有多个相互竞争的 ERC，以不同的方式实现这一目标，只要它们都遵守相同的验证和执行标准。

这种方法的一个缺点是它与签名聚合不完全兼容（正如 ERC-4337 试图做的那样）：由于协议不“理解”聚合方案，它不能强制聚合，并且恶意构建者可以合并未聚合的操作，并强制发件人为此支付全部gas。 但这种不便可以说是适度的。

可能的路线图

短期

将 ERC-4337 投入全面生产。 理想情况下，这可以通过签名聚合功能进行扩展以太坊合约地址和帐户地址，以实现汇总友好性。

应该有一个与 ERC-4337 接口的易于使用的浏览器钱包。

考虑实施签名聚合和压缩以使 ERC-4337 对 L2 更加友好；

在L2协议中引导ERC-4337生态，gas成本问题会更少；

中期

实现 Verkle 树，添加 EIP 以降低 gas 成本；

添加可选的 EOA-to-ERC-4337 转换；

在 PBS 启动的同时或之后不久添加 crList 逻辑；

长

考虑铸造；

可能的选择

1. 考虑在协议层编写包含ERC-4337等价账户和交易的EIP，并推动其在L2中的采用；

2. 使用通过辅助块工作的抗审查解决方案，消除了以太坊协议可读用户操作的需要；