EIP4337(二)：江浙沪自动包邮的Paymaster模式

本文是VB的文章学习笔记：medium.com/infinitism/erc-4337-account-abst..

本文补充了Paymaster部分的学习笔记。

Benefits

上文已经说过了一些，这里再深入讨论下合约钱包的好处。

1. Customer signature schemes

   多签, social recovery 钱包 (这二者区别是后者是一个应用，前者是一个实现方式），可选签名算法

2. Multi-operations

   批量操作，不需要approve

3. paymaster

   onboarding或者其他需要第三方支付gas的场景，甚至可以接入credit card。

4. Future-proofing

   这个没太搞懂，未来验证？

5. Universal programming interface

   统一的编程接口

Paymaster的赞助

赞助交易类似于促销商品包邮的思路，一些交易场景中的服务方产品方，提供免gas服务，本质是gasfee被服务方垫付了gas，通过的机制被定义为Paymaster，这个是基于EIP4337来实现的。当然，还有其他ERC20 swap和转化fiat功能可以集成。

赞助交易有许多关键用例，最常引用的理想使用案例有:

1.允许应用程序开发者代表他们的用户付费

2.允许用户以ERC20代币支付费用，合约作为收取ERC 20代币并以ETH支付的中介 本提案可以通过内置的paymaster机制支持此功能。

UserOperation可以将另一个地址设置为其付款人。如果设置了Paymaster(即非零)，在验证步骤期间，EntryPoint（4337的机制）还呼叫Paymaster以验证Paymaster愿意为UserOperation付费。

如果是，那么费用将从Paymaster的EntryPoint预存的ETH支付(为了安全起见，有取款延迟)而不是钱包中取出。在执行步骤中，通常使用UserOperation中的calldata调用wallet，但之后使用potOp调用paymaster。

以上两种使用情形的工作流程示例如下:

• Paymaster验证paymasterData包含来自赞助者的签名，验证赞助者愿意为UserOperation签名有效，Paymaster接受，并且从发起人的权益中支付UserOperation的费用。
• Paymaster验证sender的钱包有足够的ERC20余额来支付UserOperation。如果是这样，Paymaster接受并支付ETH费用，然后在postOp中要求ERC20代币作为补偿(如果postOp由于UserOperation耗尽ERC20余额而失败，执行将恢复，并且postOp将再次被调用，因此Paymaster总是得到支付)。请注意，目前只有当ERC20是由paymaster本身管理的wrapper token时，才能做到这一点。

特别要注意的是，在第二种情况下，Paymaster可能完全是被动的，除了偶尔的重新平衡和参数重新设置。

与现有的sponsorship尝试相比，这是一个巨大的进步，现有的赞助尝试需要Paymaster始终在线，以主动包装单个交易。