开发者进阶进阶603 次阅读
集成账户抽象钱包：UserOperation、Bundler 与 Paymaster 的分工
EIP-4337 把「发一笔交易」拆成用户操作、打包者与代付者三类角色，本文讲清各自职责与集成时的取舍和失败模式。
#账户抽象#EIP-4337#UserOperation#Bundler#Paymaster
一句话结论
EIP-4337 把「发一笔交易」升级成了「提交一次用户操作」：用户不再直接发交易，而是把意图交给打包者代发，并由代付者决定谁来付 Gas。集成 A 的钱包，等于把一条链上的执行路径换成了四个角色的协作。
四个角色各干什么
用户操作（UserOperation）：一个描述「用户想做什么」的结构化对象，包含调用目标、调用数据、Gas 相关字段和用户签名。它是意图，不是交易。
打包者（Bundler）：收集用户操作、先做验证与模拟，再把多个操作打包进一笔真实交易提交上链。它承担了原本属于钱包的广播职责。
入口合约（EntryPoint）：链上的统一入口，负责校验每个操作的签名与预付费用，然后依次执行。所有实现共享同一个入口，这也是这套方案能互操作的原因。
代付者（Paymaster）：愿意替用户承担 Gas 的一方，可以按规则补贴，例如新用户前几笔免 Gas、或允许用户用其他代币支付 Gas。
集成时真正的难点
- 地址是"先有后部署"的：智能账户地址在部署前就可以计算出来并接收资产，前端必须处理好这种尚未上链的账户状态。
- 签名对象不同：用户签的是用户操作的哈希，与普通的交易签名不是一回事，钱包抽象层要负责衔接。
- 失败模式变多：打包者可能拒绝、模拟可能不通过、Gas 估算依赖打包者的判断，出问题时比普通交易更难归因。
- 代付是策略而非能力：补贴有额度、有白名单、有开关，随时可能收紧。
收益同样明确：免 Gas 上手、批量调用合并成一次确认、以及社交恢复这类传统外部账户做不到的能力。
给你的教训
- 不要让抽象层泄漏：用户操作的字段不要直接暴露给业务代码，包一层，日后换实现成本才低。
- 把失败归因分开：打包者拒绝、模拟失败、链上 revert 是三种提示，别统一报「交易失败」。
- 代付一定要有降级路径：补贴用尽时能自动回落到用户自付，而不是让流程直接断掉。
- 先确认目标链的打包者与代付生态是否可用，测试网与主网的可用性差别很大，别等到上线前才发现没人接单。