Paymaster研究

提问
- 什么是Paymaster
  - 在4337协议中讲到，Paymaster加速了转账赞助，允许第三方设计机制去支付交易，许多这种机制可以通过有Paymaster自己封装一个UserOperation来实现，但这里又一些重要的基础性的限制
    - 没有可能性对于被动的 paymasters来讲，• No possibility for “passive” paymasters (eg. that accept fees in some EIP-20 token at an exchange rate pulled from an on-chain DEX)
      - 不能被动报价，比如通过一些dex中获得价格。
        
        我理解本质是dex汇率不可预测，会导致 simulate 中的数据与正式上链的数据可能不一致从而产生可以被人利用的漏洞
    - Paymasters run the risk of getting griefed, as users could send ops that appear to pay the paymaster but then change their behavior after a block
      - Paymasters有冒犯用户的可能，因为用户发送gas给到Paymaster之后，可能会在一个区块之后改变他们的行为
    - Paymaster计划允许一个合约被动的支付用户的利益在一个任意的环境下，它甚至允许EIP20代币 paymasters，只有在用户支付他们之后，他们才进行支付：paymaster contract 可以检查EIP20 token是否有足够的余额来支付通过 validatePaymasterUserOp
    - 然后提取它通过transferFrom函数在 postOp 调用中.
    - 如果op本身它自己转移出或者批准了太多EIP20，内部的 PostOp将会失败然后revert这个行为，外部的postOp可以提取payment
      - 什么是外部PostOp，什么是内部PostOp
- who，when，what，where，how，why
- 由哪些部件组成
  - 为什么这样设计？
- 关键工作流是什么样的？
  - 为什么是这样
- 满足了什么需求？
- 还有哪些问题？
- 有哪些部分可以改进
- 为什么要这样做

Untitled

Bundler‘s account 提交交易到 Entry point contract
验证签名，在Wallet contract里 check + pay function 获得一个结果，必须是success
验证Paymaster是否stake
call paymaster函数
执行Op 在 Wallet contract 的Main body中
Post-op在Paymaster的Post-op

根本逻辑

主要的挑战对于aa系统来说是DoS Safety：包含操作的矿工如何保证它（账户抽象钱包）实际上会支付gas，而不需要首先执行完所有的操作？
如果要求矿工来执行整个交易，那么可能会出现DoS攻击的情况
作为攻击者可以很轻易的发送很多交易假装支付gas，但是在长时间的执行之后，最后一刻revert
同样，为了防止攻击者廉价地阻塞内存池，P2P网络中的节点需要在愿意转发该操作之前检查该操作是否会支付费用。
在这个提案中，我们希望Wallets 有一个ValidateUserOp方法接受UserOperation作为输入，验证签名然后pay the fee。这个方法要求almost-pure: 它只允许访问钱包本身的存储，不能使用environment opcodes (eg. TIMESTAMP), 只能编辑钱包的内存，也可以发送ETH（需要支付 entrypoint）这个方法gas-limited by the verificationGasLimit of the UserOperation; 节点可以选择拒绝 VerificationGasLimit 太高的Op。这些限制允许矿工和网络节点在本地模拟一个验证步骤，并且要确信，当操作实际包含到块中时，结果将与结果匹配
entry point-based的方法允许在验证和执行之间有一个清晰的界限，保持钱包的逻辑简洁。另一种选择是要求钱包遵循一个模板，首先自调用验证，然后自调用执行(这样执行是沙盒的，不会导致费用支付恢复)。
基于模板的方法因为难以实现而被拒绝，因为现有的代码编译和验证工具并没有围绕模板验证进行设计。 @cejay 这段话啥意思基于模版的方法…这段话

代码