ERC 4337：无需更改以太坊协议的账户抽象

DAOrayaki DAO研究奖金池：

资助地址:DAOrayaki.eth

投票进展： DAO Committee 3/7 通过

赏金总量： 80 USDC

研究种类： DAO, ERC4337, account abstraction, smart wallet

原文作者: Vitalik Buterin

贡献者： Dewei, DAOctor @DAOrayaki

原文: ERC 4337: account abstraction without Ethereum protocol changes

长期以来，账户抽象一直是以太坊 开发者 社区的梦想。EVM 代码不仅用于实现应用程序的逻辑，还用于实现个人用户 钱包 的逻辑验证（随机数、签名……）。这将为钱包设计的创新提供很多思路，且钱包可以提供一些重要的功能如：

1、多重签名和社会恢复

2、更高效、更简单的签名算法（例如 Schnorr、BLS）

3、后量子 安全 签名算法（例如，Lamport、Winternitz）

4、可升级性

今天可以使用 智能合约 钱包完成所有这些事情，但以太坊协议本身要求将所有内容打包在源自 ECDSA 安全外部账户 (EOA) 的交易中，但智能合约钱包很难实现这些事情。每个用户操作都需要由来自 EOA 的事务包装，从而增加了 21000 gas 的开销。用户需要在单独的 EOA 中拥有 ETH 来支付 gas，并管理两个账户中的余额，或者依赖中继系统，这些系统通常是中心化的。

EIP 2938 是解决此问题的一种途径，通过 更改一些以太坊协议，允许顶级以太坊交易从合约而不是 EOA 开始。合约本身将有核实和费用支付逻辑，矿工们将进行检查。然而，当协议开发人员密切关注合并和可伸缩性时，他们需要对协议进行重大更改。在我们的新提案（ERC 4337）中，我们提供了一种在不改变共识层协议的情况下实现相同收益的方法。

这个建议是如何运作的？

我们修改的不是共识层本身的逻辑，而是在更高级别的系统中复制交易mempool的功能 。 用户发送UserOperation对象，将用户的意图与签名和其他数据打包以进行验证。矿工和者使用Flashbots等服务的捆绑机都可以将一组UserOperation对象打包成一个“捆绑事务”，然后将其包含在以太坊块中。

捆绑者以ETH形式支付捆绑交易的费用，并通过作为所有单个用户操作执行的一部分支付的费用获得补偿。捆绑商将根据与矿工在现有交易mempool中的操作方式类似的费用优先级逻辑来选择要包含哪些 UserOperation 对象。UserOperation 看起来像一个事务；它是一个 ABI 编码的结构，其中包括以下字段：

1、发件人：进行操作的钱包

2、nonce 和 signature：传递给钱包验证函数的参数，以便钱包可以验证操作

3、initCode：如果钱包尚不存在，则用于创建钱包的初始化代码

4、callData：用于实际执行步骤调用钱包的数据

其余领域与 gas 和 fee 管理有关，完整的字段列表可以在 ERC 4337 规范中找到。

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

1、validateUserOp，它接受一个 UserOperation 作为输入。这个函数应该验证UserOperation上的签名和nonce，如果验证成功则支付费用并增加nonce，如果验证失败则抛出异常。

2、op执行功能，将calldata解释为钱包采取行动的指令。这个函数如何解释calldata以及它的结果是完全开放的；但我们预计最常见的行为是将calldata解析为钱包拨打一个或多个电话的指令。

为了简化钱包的逻辑，确保安全所需的大部分复杂智能合约技巧不是在钱包本身中完成的，而是在称为入口点的全局合约中完成的。validateUserOp 和执行函数预计将使用 require(msg.sender == ENTRY_POINT) 进行门控，因此只有受信任的入口点才能使钱包执行任何操作或支付费用。入口点仅在 validateUserOp 之后对钱包进行任意调用，并且携带该调用数据的 UserOperation 已经成功，因此这足以保护钱包免受攻击。如果钱包不存在，入口点还负责使用提供的 initCode 创建钱包。

运行时的入口点控制流程

mempool节点和绑定器需要对validateUserOp的功能实施一些限制：特别是validateUserOp执行不能读取或写入其他合约的存储，不能使用环境操作码，如时间戳，它不能调用其他合约，除非这些合约可以证明不能自我毁灭。这是为了确保绑定器和UserOperation mempool节点用于验证给定的 UserOperation是否可以包含或转发的ValidateUserOperation的模拟执行在实际包含到未来块中时具有相同的效果。

如果成功模拟了 UserOperation 的验证，则保证 UserOperation 是可包含的，直到发件人帐户发生其他一些内部状态更改（因为另一个 UserOperation 具有相同的发件人或调用发件人的另一个合约；在任何一种情况下，为一个帐户触发此条件都需要在链条上花费7500+ gas ）。

此外，用户操作为 validateUser 步骤指定了 gas 限制，mempool节点和捆绑器将拒绝它，除非此 gas 限制非常小（例如，低于 200000）。这些限制复制了现有以太坊交易的关键属性，使mempool免受 DoS 攻击。捆绑器和mempool节点可以使用类似于当今以太坊事务处理的逻辑来确定是否包含或转发 UserOperation。

与常规的以太坊交易mempool相比，这种设计增加、维护和牺牲了哪些属性？

维护属性：

1、 没有中心化的参与者；一切都通过点对点mempool完成

2、DoS 安全（通过模拟检查的用户操作保证是可包含的，直到发送方有另一个状态更改，这将要求攻击者为每个发送方支付 7500+ gas）

3、 没有用户端钱包设置的复杂性：用户不必关心他们的钱包合约是否已经“已经发布”；钱包存在于确定性的 CREATE2 地址，如果钱包尚不存在，第一个 UserOperation 会自动创建它

4、 完整的EIP 1559支持，包括费用设置（用户可以设置固定的费用溢价和最高的总费用，并期望快速纳入并公平收费）

5、 通过付费替换的能力，以比旧操作更高的溢价发送新用户操作，以替换操作或更快地将其包括在内

新的好处：

1、 验证逻辑灵活性：validateUserOp函数可以添加任意签名和nonce验证逻辑（新的签名方案，多重签名……）

2、 足以使执行层量子安全：如果该提议被普遍采用，则不需要在执行层上做进一步的工作来保证量子安全。用户可以单独将他们的钱包升级到量子安全的钱包。即使是包装交易也是安全的，因为矿工可以为每个捆绑交易使用新创建的、因此受哈希保护的 EOA，并且在将交易添加到区块之前不会发布交易。

3、 钱包可升级性：钱包验证逻辑可以是有状态的，因此钱包可以更改其公钥或（如果使用 DELEGATECALL 发布）完全升级其代码。

4、 执行逻辑灵活性：钱包可以为执行步骤添加自定义逻辑，例如。进行原子多操作（EIP 3074 的一个关键目标）

缺点

1、 尽管协议尽了最大努力，但DoS漏洞略有增加，这仅仅是因为允许验证逻辑比单个ECDSA验证的现状更复杂。

2、gas 开销：比常规事务稍微多一些的 gas 开销（尽管在某些用例中由多操作支持来弥补）。

3、 一次一笔交易：账户不能排队并将多笔交易发送到mempool中。但是，执行原子多操作的能力使此功能的必要性大大降低。

与付款人的赞助：

赞助交易有许多关键用例。最常引用的期望用例是：

1. 允许应用开发者代用户付费

2. 允许用户以ERC20代币支付费用，合约作为中介收取ERC20并以ETH支付

该提案可以通过内置的付款管理员机制支持此功能。UserOperation 可以设置另一个地址作为其付款人。如果设置了付款管理员（即非零），则在验证步骤期间，入口点还调用付款管理员以验证付款管理员是否愿意为 UserOperation 付费。如果是这样，那么费用将从在入口点内抵押的付款主管的 ETH 中扣除（为了安全起见，提款延迟）而不是钱包。在执行步骤中，钱包会像往常一样使用 UserOperation 中的 calldata 调用，但之后会使用 postOp 调用 paymaster。

上述两个用例的示例工作流程是：

1、paymaster验证paymaster数据是否包含发起人的签名，从而验证发起人是否愿意为用户操作付费。如果签名有效，出纳员接受，用户操作的费用从发起人的股份中支付

2、 付款管理员验证发件人钱包是否有足够的 ERC20 余额来支付 UserOperation。如果有，paymaster 接受并支付 ETH 费用，然后在 postOp 中索取 ERC20 代币作为补偿（如果 postOp 由于 UserOperation 耗尽了 ERC20 余额而失败，则执行将恢复并且 postOp 将再次被调用，因此 paymaster 总是得到报酬）。请注意，目前，这只能在 ERC20 是由付款管理员本身管理的包装代币时才能完成。

特别要注意的是，在第二种情况下，付款主管可能是完全被动的，可能偶尔会重新平衡和重新设置参数。这是对现有赞助尝试的巨大改进，现有赞助尝试要求付款人始终在线以积极处理个人交易。

这项建议进展如何？

ERC 4337可在此处找到。这里正在实施。早期的开发者alpha版本预计很快就会出现，之后的下一步将是确定最终细节并进行审计，以确认该方案的安全性。

开发人员应该能够很快开始尝试帐户抽象钱包！