本流程图只画出了普通类型的交易，未涉及Aggregator。掌握普通流程后才方便掌握聚合型的交易。流程图中箭头不代表程序的调用栈或输入输出，仅代表相关角色、函数、事件的发生的先后顺序。为方便读者对宏观架构的快速理解，流程图中省略了一部分函数调用和逻辑。被省略的部分有可能对你研究的问题或疑惑有很大意义，具体看你想了解什么内容，所以还是需要你必要时仔细阅读源码。核心概念# V, h' }$ [9 S+ F, \9 S
9 i6 K5 K" ^9 m
    主要内容位于流程图中Figma。& b2 s) g6 H2 }

8 n5 K$ b2 Y3 v- y  f3 \( D' i$ ^; ~8 B- D  P: k2 G
    需要配合4337源码阅读GitHub—eth-infinitism/account-abstractionatmain。+ q5 @9 v. F7 d  j7 `
) s! p2 ]: f: Z% N, P
1 w/ b+ t3 Y* F3 X9 d+ E. i
    4337Spec中有更多详细细节EIP-4337:AccountAbstractionusingaltmempool。
* }  |4 R8 D% Q9 ?8 J7 h- S, _. s2 p3 [* A# B% Y9 G$ j& O
    研究4337需要掌握以下核心概念：" q6 K* `1 Z! F3 h9 `# Z+ F

9 m; w  ]9 m2 s2 Z    UserOperation的内容EntryPoint实现Wallet实现Paymaster实现验证阶段、执行阶段的执行流程与错误处理Gas的支付流程与计算UserOperation; ?2 L8 V. i+ d# g! G8 r) P# }
4 u1 H! l- Z8 ?3 L- K+ U; d6 ]
    一种内容类似transaction的伪交易对象，通过新的RPC方法eth_sendUserOperation提交给节点。" L8 N5 s! p2 n% U/ m# m

+ U/ p. Q6 S0 B, b2 N    UO中的字段含义大部分是显然的，仅挑选几个容易误解的进行分析：
3 R/ i) t* H1 K1 ~( r8 f, ~- K8 f# K( A% f
    sender，此处指的是要交互的wallet，而非msg.sender或tx.origin等其他任何概念verificationGasLimit，验证交易时的gasLimitcallGasLimit，执行交易时的gasLimitpreVerificationGas，补偿bundler调用handleOps()时会一部分未计算在内的gas成本（如提交交易的calldata成本）。Prefund( T: H) @/ _8 ]5 g9 L6 G
' P( V! [( l* ?* `) D
    这个并非UO中的一个字段，而是由上面三个gas参数计算而出。代表了该UO在验证阶段预先支付给EntryPoint的总成本。Prefund虽然是在验证阶段支付的，但包含了preVerificationGas，验证和执行三部分的成本。之后不会再向EntryPoint进行支付gas。3 ~2 z# l& h! z

5 Z$ Y4 K; p# `% H3 X    prefund/gasPrice=callGasLimit+verificationGasLimit*mul+preVerificationGas
9 O) f4 ?; ]4 U! x% Z
1 B( y" [+ x6 V    mul=mUserOp.paymaster!=address(0)?3:1;
5 S  k9 X* d, R( s' Y
% p' \: ?' f% ~% e1 @    具体计算参见EntryPoint中的_getRequiredPrefund。9 a( a1 v$ d# Z* T3 ~1 l' z' g5 v

- I& Z- _- I& {4 d% ~    EntryPoint
, S1 K* F. l! e
- o: F; H5 f) z; n* j: ?    EntryPoint是所有功能的核心入口。每个项目自行部署自己的EntryPoint。Bundler，Wallet和Paymaster都需要围绕EntryPoint工作。
2 o4 Z9 D& W8 r+ W8 E5 P( i5 ^" j" D$ p
    Bundler在EntryPoint内实现两个功能
# a: x2 G( X8 r8 J
$ j2 Z+ J8 X" ]' y% I( Z    链下验证UO，剔除不符合要求和有问题的UO。链下验证一是防止DoS，二是避免bundler在链上损失gas。打包合规的UO，提交上链。Wallet与EntryPoint6 |  p% J% r( A2 I" c) Z
9 w1 L+ H6 P5 S* q& f$ C! v
    向EntryPoint支付gas费只响应来自EntryPoint的消息执行来自EntryPoint的具体交易内容注意，EntryPoint不是Wallet的factory。官方给出的图片容易给人造成这种误解，但官方实现并非如此。Paymaster与EntryPoint
; w& l- k" i2 g2 a3 P
7 C/ _: j$ {/ D/ d& Z    向EntryPoint支付gas费只响应来自EntryPoint的消息向EntryPoint确认自己的为某UO服务的意愿在EntryPoint内质押才能成为paymaster我们可以看到Wallet与Paymaster都有可能向EntryPoint支付gas。gas余额会存储在deposits这个mapping中。& n) p4 t% \0 o) [8 H
2 [" R: H/ r' V) s
    注意，虽然deposits字面意思为充值，但并非必须一个需要预先手动完成的动作，也可以在每一笔UO发生时，计算缺少多少gas并自动充值。8 _9 }/ o( P4 f. r

  M& ]2 W. F8 D& b' h    最终，若所有操作的actualGasCost小于prefund，EntryPoint
. [& \7 m( _7 j/ j, M
& W+ d, u' q0 l8 \8 h9 [+ F    会将多余额度退款至你的deposit。
- n2 ]0 X) ]. n& H. l) {4 ~  T% ~. _" U! f" @" X: t
    actualGasCost/gasPrice=validationActualCost+callActualCost+preVerificationGas% e3 l) B/ Z  K5 E6 E
7 J0 B  h  a5 ^) E3 d8 C1 R, q
    注意，validationActualCost&callActualCost仅仅是为了说明而作的标记，并非真实存在的变量。它们是由gasPrice()累加的。
' U7 W8 X9 H, O! v+ |' L( q8 A% C+ C! J* A
    Wallet- n8 b8 ]: Z$ u1 k. b/ P1 Y
0 [( E4 s: w9 G7 i
    代表用户最终使用的钱包。需要开发者至少实现以下两个自定义方法：
$ v& O7 J* K) I# z! V7 j/ j7 F" W; C+ D
    签名验证：你可以使用任何密码学手段来实现签名验证，比如，为了配合使用苹果的SecurityEnclave而实现NISTP-256的ECDSA。如果没有特殊需求可直接使用以太坊的ECDSA。处理交易：EntryPoint通过address(sender).call(callData)来调用wallet中的具体的交易功能。那么call需要有至少一个可执行的函数，如transferEther()，callAnotherContrat()等。开发者还需要自行实现walletfactory，需要创建钱包时，工厂会被SenderCreator合约调用。新建钱包应使用CREATE2方法以保障生成地址的确定性。
, Z6 D5 U7 r* v' ]( S/ v! z* O/ n/ F0 _/ X- x
    Paymaster
: \& q( N  I- L- `& y/ i$ l0 T
    Paymaster可以为用户支付gas，因此可以实现：
, h2 Q1 A4 f* X8 X
8 m8 D& L: W8 l  X1 @" W2 W$ _) O) U    免费交易：用户激励，让用户免费使用钱包gasless交易：不直接用ether支付gas，而使用其他token或nft等等等其他类似的赞助交易功能Paymaster需要开发者实现：
9 Q4 j  s  u: j: U1 z5 U
% O. ~- o' P# p  _    validatePaymasterUserOp()：由于paymaster的开放性，验证逻辑需要开发者完全自己定义。验证后有可能需要实现类似wallet中payPrefund()的功能。_postOp：必须重写此方法，否则会被revert。此方法可以定义在paymaster赞助完交易后需要做什么，如在验证时为用户支付了ether，则此处要求用户支付等价的ERC-20。
& u& x9 c2 p1 t+ E8 U) d3 }6 r: h& R

! f) G/ g4 c% ]. o' W+ w