EIP4337(二)：江浙沪自动包邮的Paymaster模式
EIP4337(二)：江浙沪自动包邮的Paymaster模式
本文是VB的文章学习笔记：https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a
本文补充了Paymaster部分的学习笔记。
Benefits
上文已经说过了一些，这里再深入讨论下合约钱包的好处。
Customer signature schemes
多签, social recovery 钱包 (这二者区别是后者是一个应用，前者是一个实现方式），可选签名算法
Multi-operations
批量操作，不需要approve
paymaster
onboarding或者其他需要第三方支付gas的场景，甚至可以接入credit card。
Future-proofing
这个没太搞懂，未来验证？
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始终在线，以主动包装单个交易。