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

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

本文是VB的文章学习笔记：https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a

本文补充了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始终在线，以主动包装单个交易。