Vitalik 简述以太坊账户抽象之路：相关 EIP 实施顺序及优缺点
实现最佳效果的一条现实途径，是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。
原文标题：《Vitalik ：以太坊的账户抽象之路》
撰文：Vitalik Buterin
编译：隔夜的粥，DeFi 之道
账户抽象允许我们使用智能合约逻辑来指定交易的效果，以及费用支付和验证逻辑。这带来了许多重要的安全好处，例如多重签名和智能恢复钱包，能够在不更换钱包的情况下更换密钥以及量子安全性。
许多帐户抽象的方法已在不同程度上被提出并得到了实施，参见：EIP-86、EIP-2938?，以及两年前的这篇文章?。今天，由于开发者们希望专注于合并与分片，这些 EIP 的开发陷入了僵局，而 ERC-4337? 这种不需要任何共识更改的替代方案已经取得了很大进展。
ERC-4337 尝试通过额外的协议手段实现和 EIP-2938 相同的事情。用户需要发送称为用户操作（user operations）的链外消息，这些消息由区块提议者（proposer）或为区块提议者生成 bundles 的构建者（builder）批量收集并打包成单笔交易。提议者或构建者负责过滤操作以确保他们只接受支付费用的操作。用户操作有一个单独的 mempool 存储池，连接到这个存储池的节点会进行 ERC-4337 特定的验证，以确保用户操作在转发之前能够支付费用。
ERC-4337 作为一个纯自愿的 ERC 可以做很多事情。然而，在一些关键领域，它比真正的协议内解决方案更弱：
现有用户如果不将其所有资产和活动移动到新帐户，则无法升级；
额外的 gas 开销（基本 UserOperation 用户操作约 42 k，而基本交易约为 21 k）；
较少受益于协议内抗审查技术（例如 crLists），它以交易为目标并会错过用户操作（user operation）
而实现最佳效果的一条现实途径，是在短期内开始大力支持 ERC-4337，然后随着时间的推移添加 EIP 来弥补其弱点。这并不一定需要大家专门承诺遵守 ERC-4337。相反，可以将协议内支持设计为更通用，并支持 ERC-4337 及其替代方案和改进。
在这里，我将列出其中的一些 EIP，并说明它们可以按什么顺序实施。
将 EOA 钱包转换为智能合约钱包
为了让现有的 EOA 钱包升级到 ERC-4337 钱包，我们可以制作一个 EIP，允许 EOA 执行设置其合约代码的操作。一旦 EOA 做到了这一点，这种转变就不可逆转。从那时起，该帐户将仅用作智能合约钱包。幸运的是，由于 ERC-4337 帐户是 DELEGATECALL 代理，因此如果需要，以后可以将钱包转换为与其他 ERC 兼容的智能合约。
关于如何实施此升级过程有一些提案：
1、「replace code」 交易类型
这还没有作为正式的 EIP 引入，但方法很简单：添加一个新的 EIP-2718? 交易类型，只需将帐户码替换为 calldata。
2、AUTH_USURP (EIP-5003)
EIP-5003? 是 EIP-3074?（AUTH 和 AUTHCALL）的扩展提案，它引入了新的 AUTHUSURP 操作码。如果使用 EIP-3074 机制，EOA 地址 A 已授权另一个地址 B 代表它行事，则 AUTHUSURP 允许 B 设置 A 的代码。
这种方法比「replace code」路线更复杂，只有当我们打算采用 EIP-3074 时，这才有意义。
强制转换
在更长远的未来，我们可能希望进行强制转换，以简化协议，并使合约成为唯一的帐户类型，从协议中取消 ECDSA。一种可能的方法是添加一个覆盖规则，从某个区块开始，没有 code 的账户被视为具有特定标准化「ERC-4337 EOA 钱包」 code 的账户。
这可以通过「poking」过程来完成，其中任何源自 EOA 的交易都将其转换，并且任何触及具有非零 nonce 的 EOA 交易都会将其转换。也可以一次性通过整个状态来完成。
问题
合约内 ECRECOVER 验证：一些智能合约依赖于这样的假设，即如果你向特定账户提供 ECRECOVER 的签名，你就拥有该账户。如果 EOA 转换为合约，然后更改其验证密钥，则原始密钥仍然能够在这些特定上下文中「代表」帐户。这可通过开始鼓励所有此类项目更改为使用 EIP-1271 验证，而不是在帐户有 code 的情况下使用 ECRECOVER。
- 热门