分享|ERC 4337：无需改变以太坊共识层协议，即可实现验证逻辑

tanoye  |  2021-10-09 12:50:06215

本文由Medium首发，Eigen Labs译制。Eigen Network是Arbitrum上目前唯一一个提供隐私保护功能的项目。欢迎关注我们，持续为您提供更优质的内容。

原文链接： ERC 4337: account abstraction without Ethereum protocol changes | by Vitalik Buterin | Infinitism | Sep, 2021 | Medium

以下为正文，enjoy~

账户抽象（Account Abstruct, 目标是将两类以太坊账户抽象为一类，合约账户）一直以来都是以太坊社区开发者力图实现的目标。EVM代码不仅仅用于app的逻辑实现，它还将用于个体用户钱包的验证逻辑（nonce、签名等）。这就为钱包的创新设计打开了新的思路。例如如下的一系列重要功能：

• 多签和社交恢复
• 更高效和更简洁的签名算法（如：Schnorr, BLS）
• 后量子安全签名算法（如：Lamport, Winternitz）
• 钱包可升级能力

如今，使用智能合约钱包可以实现所有上述功能。但事实上，以太坊协议本身要求交易内容都基于ECDSA算法加固的外部账户（EOA, Externally-Owned Account）进行打包签名。因此，这个要求使得上述功能的实现非常困难。要知道，每个UserOperation都需要通过外部账户封装（ wrap），这就会增加21000 gas的开销。这种情况下，用户有两个选择：要么，用户要在单独的EOA中，用以太坊支付gas 费，并管理两个账户的余额；或者，用户就要依赖典型中心化的中继系统。

EIP 2938 是解决上述两难问题的一个方案。这个方案要求对以太坊协议进行修改，并允许从合约(contract），而不是外部账户来发起以太坊交易。合约本身会具有验证和矿工需验证的gas费用支付逻辑。但是，当时协议开发人员非常关注合并和可扩展性，并没有实现这种重大的协议改变。于是，我们提出了ERC 4337，希望在不改变共识层协议的情况下，实现与EIP 2938相同的效果。

我们的提案如何运作?

与其修改共识层本身的逻辑，不如在更高级别的系统中复用交易池的机制。用户发送 UserOperation 对象到交易池，UserOperation将用户数据，签名和其他数据打包在一起进行验证。使用像Flashbots 这样的矿工或捆绑器（bundler）可以将一组UserOperation对象打包成一个“捆绑交易”，然后将其包含在以太坊区块中。

捆绑器使用以太币来支付捆绑交易的费用。同时，捆绑器也能得到一定的激励。这种激励来源于用户执行操作所支付的费用。捆绑器要选择包含哪些UserOperation对象。与矿工在现有交易mempool类似，捆绑器选择交易依据是基于“费用优先”。一个UserOperation对象类似是一个交易; 它是由以下字段组成的abi编码的结构：

• 发送方（Sender）：发起操作的钱包账户
• Nonce和签名：传递到钱包验证功能的参数，以便钱包验证操作
• InitCode：如果钱包尚不存在，则用于创建钱包
• CallData：钱包在实际执行中需要的输入数据

剩余字段与gas及其费用管理有关；在ERC-4337规范中可以找到完整的字段列表。

钱包是一种智能合约，需要具备两项功能：

• ValidateUserOp功能（以UserOperation为输入）：用于验证UserOperation上的签名和nonce，如果验证成功则支付费用并增加nonce，如果验证失败则报错。
• OP执行功能：将 calldata解释为钱包采取行动的指令。OP执行功能解释calldata的结果是完全开放式的；但是我们预计最常见的结果是将calldata解析为钱包指令，供钱包进行调用。

为了简化钱包的逻辑，我们不在钱包中设置太多的智能合约。而是在一个被称为入口点（EntryPoint）的全局合约中设置复杂的智能合约。预计validateUserOp和执行功能需要执行入口 （msg.sender==ENTRY_POINT），因此只有可信任的EntryPoint才能引发钱包执行操作或支付费用。EntryPoint仅在validateUserOp后对钱包进行任意调用，而validateUserOp后携带该calldata的UserOperation已经成功执行，因此这足以保护钱包免受攻击。如果钱包不存在，EntryPoint还可以负责使用提供的初始代码创建钱包。

运行HandleOps时的入口点控制流

交易池节点和捆绑器（bundler）需要对“验证UserOperation”（validateUserOp）的功能实施一些限制：验证UserOperation不能读或写入其他合约的存储以及，不能使用诸如时间戳之类的环境操作码，不能调用其他合约（除非可以证明这些合约无法自毁）。这些限制是为了确保捆绑器（bundler）和UserOperation 交易池节点使用“验证UserOperation”的模拟执行功能，在应用到正常区块中以后，可以正常地进行验证。

如果上述UserOperation的模拟验证成功，则在发送方（sender）帐户发生更改前，UserOperation必然是包容的。那么，无论是同一发送方的其他UserOperation抑或是另一个合约调用发送方，触发一个帐户都需要在链上花费7500以上的gas。此外，UserOperation为验证UserOperation限定了gas上限。除非该gas上限非常小（例如低于200000），否则交易池节点和捆绑器将拒绝该步骤。这个限制沿袭了现有以太坊交易的关键属性，旨在保护交易池免受DoS攻击。捆绑器和交易池节点可以使用类似于以太坊交易处理的逻辑来确定是否包含或转发UserOperation。

与常规以太坊交易交易池相比，我们的设计有哪些特点？

保持了常规以太坊交易的：

• 去中心化；一切交易都是通过P2P完成
• 免受DoS攻击（直到发送方发生另一个状态更改，通过模拟检查的UserOperation必然是可包含的，这将要求攻击者为每个发送方支付7500以上的gas）
• 用户端钱包设置简单：这就是说，用户不必关心他们的钱包合约是否已经“发布”；钱包存在于确定的CREATE2 地址。如果钱包还不存在，第一个用户会自动创建一个钱包出来。
• 完整的EIP 1559支持，包括简单的费用设置（用户可以设置固定的费用溢价和最高总费用，并希望能迅速纳入并公平收费）
• 付费替换的能力。发送一个比旧UserOperation具有更高的溢价UserOperation，去替换掉旧的UserOperation，或者让自己的新操作先被执行

新优点：

• 验证逻辑灵活性：函数（validateUserOp）可以添加任意签名和nonce验证逻辑（新签名方案、多签…）
• 执行层量子安全：如果这一提案得到普遍采用，则无需为量子安全在执行层做进一步的工作。用户可将钱包自行升级到量子安全的版本。甚至连封装交易（wrapper transaction）也是安全的。矿工可以为每个捆绑交易使用新创建的EOA，由于是新创建的，所以每个交易都受到哈希保护，更保证了安全性。并且，在矿工将交易添加到区块中之前不会发布该交易。
• 钱包可升级性：钱包验证逻辑可以是有状态的，因此钱包可以更改其公钥或（如果使用DELEGATECALL发布）完全升级其代码。
• 执行逻辑灵活性：钱包可以为执行步骤添加自定义逻辑，例如进行原子多操作（这是EIP 3074的一个关键目标）

不足：

• 尽管协议力求完美，但DoS漏洞无法彻底规避。主要是由于准许(校验，后面都改下）验证逻辑（verification logic）比单个ECDSA签名验证要更复杂。
• Gas开销：尽管在某些用例中由多操作支持来弥补，Gas开销还是要比常规交易稍微多一些
• 一次只能发送单个捆绑交易：帐户无法排队将多个交易发送到交易池。不过，我们的优点（执行原子多操作的能力）已经使得此功能不那么必要了。

Paymasters支持

代付交易（Sponsored Transactions）有许多关键案例。一些经常提到的需求场景如下：

1. 允许app开发者代表其用户支付费用
2. 允许用户使用ERC20代币支付费用，合约作为中介，负责收取ERC20代币并使用以太坊支付

此提案可通过内置paymaster机制支持此功能。UserOperation可以将另一个地址设置为其paymaster。如果设置了paymaster（即nonzero），则在验证步骤期间，入口函数还会调用paymaster(原支付人）以验证其是否支持为UserOperation付费。如果验证结果是支持付费，那么费用将从paymaster质押在入口点的以太坊扣除，而不是将费用从钱包中扣除。并且，出于安全考虑，在这个过程中存在提取延迟。在执行步骤中，钱包会像照常调用UserOperation中的calldata，但之后会使用postOp调用paymaster。

上述两个关键用例的示例工作流程包括：

• Paymaster验证paymasterData是否包含发起人（Sponsor）的签名，从而验证发起人是否愿意为UserOperation付费。如果签名有效，UserOperation的费用将从发起人的质押金额中支付。
• Paymaster验证发送方钱包是否有足够的ERC20 代币余额。如果ERC20 余额足够，paymaster将支付费用，然后在postOp中申请ERC20 代币作为补偿。但是，如果UserOperation中的ERC20余额不足，之前的操作将被还原。PostOp将再次被调用。总之，paymaster始终都能获得支付。不过以上的这些表述有一个前提，就是只有当ERC20是由paymaster本身的封装代币（wrapper token）时，才能执行此操作。

我们特别要注意的是，在第二个用例下，除了偶尔的重新平衡和参数重新设置的情况，paymaster可能完全是被动的。与现有的支持尝试相比，这是一个巨大的改进，即要求paymaster始终在线，积极地封装个人交易。

提案进展如何？

ERC 4337指日可待。我们预计，面向早期的开发者的alpha版本很快就会面世。我们的下一步工作将是敲定最终细节，并进行最终检查，以确认该方案的安全性。

我们相信，开发者应该能够很快开始尝试帐户抽象钱包！

About Us：

EigenSecret是一款专注于秘钥托管和社交恢复的EVM兼容的钱包，支持Web2账户One-click登陆，并且支持Arbitrum跨链桥协议。 社交恢复功能将于近期上线。