Vitalik:以太坊的账户抽象之路
原文标题:《Vitalik : 以太坊 的账户抽象之路》
原文作者: Vitalik Buterin 原文编译:隔夜的粥,元宇宙之道
账户抽象允许我们使用智能合约逻辑来指定交易的效果,以及费用支付和验证逻辑。 这带来了许多重要的安全好处,例如多重签名和智能恢复钱包,能够在不更换钱包的情况下更换密钥以及量子安全性。
许多帐户抽象的方法已在不同程度上被提出并得到了实施,参见: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。
尚未检测到的账户:强制转换面临的一个挑战是拥有资产(如 ERC20 s、ERC721 s,但不是 ETH )但尚未发送或接收任何交易的账户,因此协议无法可靠检测到这些账户。协议必须保留将此类账户永久转换为默认钱包的功能,或者需要有一个截止期(例如部署后 4 年),在此之后尚未转换的帐户将被烧毁。
EOA 只检查不可转让性:一些应用程序实施合约内检查以仅允许 EOA 与其交互。这通常是为了强制执行不可转让性。从根本上来说,这是一个坏主意,并且与转向智能合约以提高安全性的目标不相容。因此,不应鼓励这种做法,而应鼓励应用依赖原所有者恢复程序来使转移无法执行。
降低 Gas 成本
ERC-4337 钱包面临更高的 gas 成本(基本 ERC-4337 操作约 42000 gas,而基本常规交易需要 21000 gas),原因如下:
1、需要支付大量的单个存储读/写成本,在 EOA 的情况下,这些成本会捆绑到一笔 21000 gas 的付款中:
(1)编辑包含 pubkey+nonce (~5000) 的存储 slot;
(2)用户操作调用数据成本(约 4500,通过压缩可减少到约 2500);
(3)ECRECOVER (~3000);
(4)首次访问钱包本身 (~2600)
(5)首次访问收款人账户 (~2600)
(6)将 ETH 转入收款人账户 (~9000)
(7)编辑存储以支付费用(~5000)
(8)访问包含代理 (~2100) 的存储 slot,然后访问代理本身 (~2600);
2、除了上述存储读/写成本之外,合约还需要执行「业务逻辑」(解包 UserOperation、对其进行哈希、洗牌变量等)
3、需要消耗 gas 来支付日志费用(EOA 不发布日志);
4、一次性合约创建成本(约 32000 gas,加上代理中每个 code byte 200 gas,再加上设置代理地址的 20000 gas)
其中很多问题将在 Verkle 树 witness gas cost EIP 以及 write gas cost reform EIP 中自动解决,以更精简的系统取代大量存储成本。例如,pubkey 和 nonce 可以存储在 slot 0…63 中,这将访问它们的成本降低到 1000 以下。用户在转移 ETH 和支付费用时支付的费用会更少,因为目标账户和接收账户只需要被首次访问一次。
还有更多的 EIP 可以帮助我们实现简化。例如:
禁止智能合约逻辑使用 slot 0 的自愿 ERC,将允许它用于存储代理,从而使其受益于更便宜的 gas 成本。
「code address」字段可以使代理更轻松,消耗的 gas 更少。
「snappy compression」预编译可以更轻松地使用 ABI 对象,而无需为所有零字节支付 calldata gas 成本。
这是一个需要更多研究的领域。
crLists
这是一个长期的问题,因为只有启用了完全的协议提议者/构建者(proposer/builder)分离方案后,crLists 才真正适用。挑战在于,我们希望提议者能够识别「值得」包含的用户操作(即他们支付足够的费用),以便协议可以迫使它们被包含在下一个有空间的区块中。
这要求在协议中明确「验证」和「执行」的概念。对于用户操作,必须有一种已定义的方法来验证该操作,以及有一种已定义的方法来执行该操作,这样如果某个操作被验证,则执行该操作的尝试将是保证支付费用的,除非被读取的状态在验证期间被修改。这些操作可以通过嵌入 ABI 方法来实现,如果实现了 EOF EIP,也可以通过添加专用的 EOF 部分来实现。
幸运的是,这不需要我们把 ERC-4337 当作一个最终标准,而是纳入 ERC-4337 所支持的一个较弱概念,其他在很大程度上不同的 ERC 也可以轻松支持它。
原因是,ERC-4337 和 EIP-2938 的复杂性很大程度上与解决更强的 DoS 抗性问题有关:不可能使一个操作取消数百个其他操作,因为这将允许廉价地对 mempool 进行垃圾交易攻击。这需要对帐户验证可访问的内容施加限制。在这里,我们可以做一些更简单的事情:只记录在验证过程中触摸了哪些状态对象,如果这些状态对象中的任何一个被编辑,则不需要包含。
这使得个人账户可以在审查抵制和灵活性之间选择自己的权衡。在极端情况下,如果账户愿意,可以通过 Uniswap 在验证期间支付费用,但由于任何人都可以发送影响 Uniswap 状态的交易,因此此类账户实际上没有抗审查保证。
crList 设计的大致轮廓如下:
提议可以包含一个 crList,它指定要包含的操作列表,以及每个操作读取的状态对象 (key, value)对的列表。接受 crList 的构建者(或其他任何人)必须检查所有操作是否通过 validate 检查。
执行 crList 中的每个操作都需要该区块,除非该区块没有足够的剩余 gas,或者执行时的当前状态已经编辑了该操作读取的状态对象之一。
ERC-4337 的剩余复杂性将仅用于 mempool 安全。原则上,可以有多个相互竞争的 ERC 以不同的方式实现该目标,只要它们都遵循相同的验证和执行标准。
这种方法的一个缺点是它与签名聚合不完全兼容(正如 ERC-4337 试图做的那样):因为协议不「理解」聚合方案,它不能强制聚合,恶意构建者可能纳入未聚合的操作,并迫使发送者为其支付全部 gas。但这种不便可以说是适度的。
可能的路线图
短期
将 ERC-4337 全面投入生产。理想情况下,可以使用签名聚合功能对其进行扩展,以实现 rollup 友好性。
应该有接入 ERC-4337 的易于使用的浏览器钱包。
考虑实现签名聚合和压缩,以使 ERC-4337 对 L2 更加友好;
在 L2 协议中引导 ERC-4337 生态,其中 gas 成本问题会较少;
中期
实施 Verkle 树,添加 EIP 以降低 gas 成本;
添加可选的 EOA-to-ERC-4337 转换;
在 PBS 推出的同时或不久之后添加 crList 逻辑;
长期
考虑强制转换;
可能的替代方案
1、考虑编写一个在协议层包含 ERC-4337 等效帐户和交易的 EIP,并推动其在 L2 中的采用;
2、使用一种通过 axuliary 区块工作的抗审查解决方案,消除用户操作对以太坊协议的可读的需要;
Bitcoin Price Consolidates Below Resistance, Are Dips Still Supported?
Bitcoin Price Consolidates Below Resistance, Are Dips Still Supported?
XRP, Solana, Cardano, Shiba Inu Making Up for Lost Time as Big Whale Transaction Spikes Pop Up
XRP, Solana, Cardano, Shiba Inu Making Up for Lost Time as Big Whale Transaction Spikes Pop Up
Justin Sun suspected to have purchased $160m in Ethereum
Justin Sun suspected to have purchased $160m in Ethereum