深入探讨ERC-4337的主要组件：使用备用内存池的账户抽象——第4部分

深入探讨 ERC-4337 的主要组成部分：使用 Alt Mempool 的账户抽象 — 第 4 部分

欢迎回到我们对 ERC-4337 的探索之旅的第四部分和最后一部分：使用 Alt Mempool 的账户抽象。在这一结尾部分，我们将深入探讨 ERC 基础设施中最具可配置性的部分之一：Paymaster。在这篇文章中，我们将解释交易是如何获得资金的以及费用是如何管理的。在深入了解 Paymaster 之前，首先回顾一些关键点：

• Bundler 和 UserOperations：如 第一部分 中讨论的，Bundler 是负责监听“Alt Mempool”上的 UserOperations 的组件，打包并将它们作为常规交易发送到以太坊节点。这些捆绑包封装了交易意图和验证数据，取代了传统的以 EOA 为基础的工作流程。
• EntryPoint：这个中心合约管理 UserOperations，确保其有效性和执行，详见 第二部分。
• 智能账户：ERC-4337 的最后一个强制性组件，负责抽象掉传统 EOA 一些瓶颈，如 第三部分 所示。

Paymaster

传统上，用户直接支付Gas费。Paymasters 可以通过根据他们的 自定义逻辑 来覆盖交易成本，改变这一产品特性，从而启用多种用例并改善用户体验。

来源：ERC-4337：使用 Alt Mempool 的账户抽象

得益于规范中的这种灵活性，可以实现交易赞助、基于订阅的Gas费支付或动态费率等创新模型。在 Infinitism 仓库中提供的 一些示例 实现了可以用 ERC-20 代币收费的 paymasters，其他则基于外部链下服务提供的消息签名验证津贴。

每个 Paymaster 的特定功能和实现细节取决于合约拥有者，他们部署符合 IPaymaster 接口的实例。

contracts/interfaces/IPaymaster.sol – Medium

   interfaceIPaymaster { 
   function validatePaymasterUserOp( 
   UserOperation calldatauserOp, 
   bytes32userOpHash, 
   uint256maxCost 
   ) externalreturns (bytesmemorycontext, uint256validationData); 

   function postOp( 
   PostOpMode mode, 
   bytescalldatacontext, 
   uint256actualGasCost 
   ) external; 
   } 

   contractMyPaymasterisIPaymaster {} 

查看原文 IPaymaster.sol 由 GitHub 托管 ❤

IPaymaster.sol

理解 Paymaster 流程

Paymaster 流程可以通过与 ERC-4337 的其他组件的交互来更好地解释：

• UserOperations：Paymaster 的详细信息包含在 userOp 参数中，允许 EntryPoint 识别和与正确的 Paymaster 进行交互。
• EntryPoint：Paymaster 在 UserOperation 生命周期的各个阶段与 EntryPoint 进行交互，提供费用估算、Gas费用结算，并可能执行额外逻辑。

来源：账户抽象简介：什么是 Paymasters？

验证阶段

在验证循环中，如果 UserOperation 上指定了 paymaster 参数，EntryPoint 的 validateUserOp 函数会确认 Paymaster 拥有足够的以太存款，以便进行退款。该值是根据在 UserOp 结构中指定的 gas 限制 计算得出的。

需注意的是，Paymaster 必须至少包含三倍于 verificationGasLimit 的值，因为此值也被用作 postOp 调用的限制，而该调用可以被调用两次：第一次在 UserOperation 执行后，第二次在 Paymaster 自身的 postOp 回滚时。这用于通知 Paymaster 他们的赞助失败，以便他们能采取相应的措施，同时 Entrypoint 仍可收取Gas费用并将其发送给 bundler 接收方。这样，Entrypoint 可以确保无论用户操作是否成功，bundler 接收方都能收到其付款。

之后，在 Paymaster 上调用 validatePaymasterUserOp。在这里，Paymaster 内部逻辑检查它是否愿意为此用户操作支付。例如，如果服务提供商为特定用户集提供费用补贴，他们可能会 验证该账户是否在他们的白名单上。另一个例子是一个无权限的 Paymaster，允许用户用 ERC-20 代币支付，该 Paymaster 可能在操作执行之前检查用户的余额，收取代币然后用以太支付。

执行阶段

一旦验证成功，Paymaster 就进入执行阶段，此时实际的用户操作执行。如果 validatePaymasterUserOp 返回非空上下文，handleOps 会在操作执行后调用 Paymaster 的 postOp，在 _handlePostOp 期间。

Post Op

在 postOp 期间，Paymaster 应该分析 mode 参数，以了解用户操作是否成功（ opSucceeded）、回滚（ opReverted），或者是否成功但导致 postOp 回滚（ postOpReverted）。

这种最后一种模式可能发生，例如，在 validatePaymasterUserOp 成功的情况下（意味着 Paymaster 同意为用户操作支付费用），但在用户操作发生后尝试“向用户收费”时却无法成功。在这种情况下，EntryPoint 仍然在 innerHandleOp 后调用 Paymaster。然后，在这第二次执行期间，Paymaster 仍然可以向用户收费。这样，Paymasters 就不会被看似拥有足够资金的用户操作所“欺骗”，而实际上并没有。

更具体地说，假设以下场景，如 以太坊基金会在此演讲中所述：

1. 一个 Token Paymaster 可以为用户操作付费，如果用户以 USDC 付款。
2. 一次用户操作的估计成本为 10 USDC，而该账户的余额为 15 USDC。Paymaster 提取 10 USDC 并继续执行。
3. 用户操作执行一次闪电贷，并使 Paymaster 依赖以 USDC 交换 Ether 的流动池失衡。因此，尽管用户操作成功，但 Paymaster 的 postOp 将回滚。
4. EntryPoint 再次调用 Paymaster，并通知其处于 postOpReverted 模式。Paymaster 可以选择回滚整个捆绑，这反过来影响声誉系统，如下所述。

声誉和节流系统

Paymasters 为网络引入了新的复杂性层，而安全考虑在 ERC 中得到了处理。它解释道：

恶意构建的 Paymaster 可以 阻断系统。为此，我们使用声誉系统。Paymaster 必须限制其存储使用或保存押金。详见 声誉、节流和禁止部分。

由于 Paymasters 是全球实体，因为多个 UserOperations 可能访问它们，可能会导致对整个网络的问题。为了解决这个问题，创建了节流系统。

EntryPoint 通过发出 FailedOp 事件来追究 Paymasters 对后期回滚失败的责任，并提醒 bundlers 执行规范中描述的节流或禁止算法，以及后面的 ERC-7562。

押金 是 Paymaster 锁定的值，至少为 unstakeDelay，bundlers 使用这些值阻止在低押金延迟或低声誉下的用户操作。这个逻辑可以在本系列的 第一部分 中更好地理解。

结论

Paymaster 是账户抽象的一个可选但极其重要的组成部分。它的出现使得创建多个新特性和应用场景成为可能。使用 USDC 等代币支付Gas费、按需服务、无Gas费交易特定群体、去中心化Gas市场，以及许多其他应用场景都被解锁。

到此，在 ERC-4337：使用 Alt Mempool 的账户抽象的深入探讨中，我们已走到尽头！我们希望本系列能够提供有关以太坊上这一令人兴奋的新账户抽象方法的宝贵见解。

请记住，探索的旅程永无止境——继续深入代码，参与社区，为这项创新技术的未来贡献力量。如果你有任何安全问题，请随时 与我们联系。

• 原文链接： medium.com/oak-security/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～