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

• 多重签名和社会恢复
• 更高效、更简单的签名算法（例如 Schnorr、BLS）
• 后量子安全签名算法（例如 Lamport、Winternitz）
• 可升级性

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

EIP 2938是解决此问题的一种途径，它通过引入一些以太坊协议更改，允许顶级以太坊交易从合约而不是 EOA 开始。合同本身将具有矿工将检查的验证和费用支付逻辑。然而，在协议开发人员高度关注合并和可扩展性的时候，这需要对协议进行重大更改。在我们的新提案 ( ERC 4337 ) 中，我们提供了一种无需更改共识层协议即可获得相同收益的方法。

一. 这个提案如何运作

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

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

• sender: 进行操作的钱包
• nonceand signature: 传递给钱包验证功能的参数，以便钱包可以验证操作
• initCode: 如果钱包尚不存在，则创建钱包的初始代码
• callData: 在实际执行步骤中用什么数据调用钱包

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

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

• validateUserOp, 它以 aUserOperation作为输入。该函数应该验证 上的签名和 nonce UserOperation，如果验证成功则支付费用并递增 nonce，如果验证失败则抛出异常。
• 一个 op 执行函数，它将 calldata 解释为钱包采取行动的指令。这个函数如何解释调用数据以及它的结果是完全开放的；但我们预计最常见的行为是将调用数据解析为钱包进行一次或多次调用的指令。

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

运行时入口点控制流程handleOps

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

如果UserOperation成功模拟了 a 的验证，UserOperation则保证可以包含该帐户，直到sender帐户发生其他内部状态更改（因为另一个UserOperation具有相同的发送者或另一个调用发送者的合约；在任何一种情况下，都会触发一个条件帐户需要在链上花费 7500+ gas）。此外，aUserOperation为validateUserOp步骤，mempool 节点和打包器将拒绝它，除非这个 gas 限制非常小（例如，低于 200000）。这些限制复制了现有以太坊交易的关键属性，使内存池免受 DoS 攻击。捆绑器和内存池节点可以使用类似于当今以太坊事务处理逻辑的逻辑来确定是否包含或转发一个UserOperation.

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

维护属性：

• 没有集中的参与者；一切都通过点对点内存池完成
• DoS 安全性（UserOperation通过模拟检查的 a 保证是可包含的，直到sender有另一个状态变化，这将需要攻击者为每个支付 7500+ gas sender）
• 没有用户端钱包设置的复杂性：用户不必关心自己的钱包合约是否“已经发布”；钱包存在于确定的 CREATE2 地址，如果钱包尚不存在，第一个UserOperation会自动创建它
• 完整的 EIP 1559 支持，包括费用设置的简单性（用户可以设置固定的费用溢价和较高的最高总费用，并期望被快速纳入并公平收费）
• 按费用替换的能力，发送一个UserOperation比旧的溢价高得多的新的来替换操作或更快地包含它

新福利：

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

弱点：

• 尽管协议尽了最大努力，但DoS 漏洞略有增加，这仅仅是因为允许验证逻辑比单个 ECDSA 验证的现状更复杂一些。
• Gas 开销：比常规事务稍微多一些 gas 开销（尽管在某些用例中通过多操作支持弥补）。
• 一次一笔交易：账户不能排队并将多笔交易发送到内存池中。但是，执行原子多操作的能力使得此功能变得不那么必要了。

三. 与出纳员的赞助

赞助交易有许多关键用例。最常被引用的所需用例是：

1. 允许应用程序开发者代表他们的用户支付费用
2. 允许用户使用 ERC20 代币支付费用，合同作为中介来收集 ERC20 代币并用 ETH 支付

该提案可以通过内置的paymaster机制支持此功能。AUserOperation可以设置另一个地址作为其付款人。如果 paymaster 已设置（即非零），则在验证步骤期间，入口点还会调用 paymaster 以验证 paymaster 是否愿意为UserOperation. 如果是，则费用将从入账点内的出纳员的 ETH 中提取（出于安全考虑，有提款延迟），而不是从钱包中提取。在执行步骤中，钱包会UserOperation像往常一样用 calldata 调用，但之后 paymaster 会被调用postOp。

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

• 出纳员验证paymasterData包含来自赞助商的签名，验证赞助商是否愿意支付UserOperation。如果签名有效，付款人接受并UserOperation从赞助商的股份中支付费用。
• 出纳员验证sender钱包是否有足够的 ERC20 余额来支付UserOperation. 如果是这样，paymaster 接受并支付 ETH 费用，然后要求 ERC20 代币作为补偿postOp（如果postOp由于UserOperation耗尽 ERC20 余额而失败，执行将恢复并postOp再次调用，因此 paymaster 总是得到报酬). 请注意，目前，这只能在 ERC20 是由 paymaster 自己管理的包装令牌时才能完成。

特别要注意的是，在第二种情况下，付款人可以是纯粹被动的，也许除了偶尔的重新平衡和参数重新设置之外。这是对现有赞助尝试的巨大改进，现有赞助尝试要求出纳员始终在线以积极包装个人交易。

四. 这个提议有多远

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

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

文章翻译自：https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a