用户不持有 ETH 也能完成链上操作：代付模型怎么落地？

30 秒回答

代付让签名方与链上付费方分离。ERC-2612 permit 只提供签名授权，不能单独完成后续交易；要让无 ETH 用户完成整个业务操作，还需支持 permit 的业务合约与代发方，或使用 ERC-4337 paymaster、适配 EIP-7702 的赞助流程。费用仍由某一方承担。实现差异与工程取舍见深入回答。

深入回答

• 【协议保证】EIP-2612 的 permit 允许持有者以签名方式给出授权，并由其他地址代为提交，因此签名者本身不需要持有 ETH 来完成这一步（依据：EIP-2612 §Specification、§Rationale）
• 【协议保证】permit 只设置代币的 allowance，不包含转账或业务调用；后续操作需要由其他交易执行。若目标是让用户全程不持有 ETH，业务合约必须支持利用该授权完成操作，并由代发方提交、支付费用（依据：EIP-2612 §Specification、§Motivation；后半句为工程方案）。
• 【协议保证】permit 的签名绑定 nonce 与 deadline，二者共同限制签名的重复使用与有效窗口（依据：EIP-2612 §Specification）
• 【协议保证】ERC-4337 用 UserOperation 表达用户意图，由 bundler 打包为外部交易调用 EntryPoint，EntryPoint 负责校验与执行（依据：EIP-4337 §Specification）
• 【协议保证】paymaster 在这些流程中承担费用，链上依据其自身规则验证并结算这笔费用（依据：EIP-4337 §Specification）
• 【协议保证】EIP-7702 允许 EOA 通过类型 4 交易把自身代码设置为委托指示，这为赞助交易提供了一条不由账户主动发起交易的路径（依据：EIP-7702 §Specification 的委托指示定义、§Motivation 的赞助场景）
• 【协议保证】在赞助交易中，relayer 需要应对授权被撤销或账户资产在执行前被转移的情况，这些风险在规范的安全考量中被点名（依据：EIP-7702 §Security Considerations 的赞助交易中继相关条目）
• 【工程经验】前端把「由谁支付费用、以什么资产结算、失败时成本由谁承担」写进用户可见的摘要，文案上避免使用「免费」这类描述（依据：工程经验，无规范依据）
• 【工程经验】代付入口配合限额、频次与目标合约白名单等风控手段，可以降低被批量滥用的概率（依据：工程经验，无规范依据）

常见错误

• 把「用户不需要持有 ETH」宣传成零成本（依据：EIP-4337 §Specification 的 paymaster 结算语义）
• 拿到 UserOperation 的标识后按交易哈希的方式去查收据（依据：EIP-4337 §Specification 对 UserOperation 与外部交易关系的描述）
• 认为 permit 签名可以长期重复使用（依据：EIP-2612 §Specification 的 nonce 与 deadline 校验）
• 赞助方在没有风控的情况下为大量地址垫付（依据：EIP-7702 §Security Considerations）
• 前端在代付失败或超时后没有把状态与费用归属说清楚（依据：工程经验，无规范依据）

面试官追问

1. 授权在被打包前被撤销，垫付方会承担什么，如何降低这类风险？
2. 三种代付路径分别适合什么产品与用户群？
3. 前端至少要展示哪些信息，用户才能判断成本由谁承担？
4. bundler 服务不可用时，用户的授权与资金处于什么状态？

评分标准

初级回答

• 知道代付是把付费方与签名方分开。
• 知道费用仍然存在，只是承担方变化。

中级回答

• 能区分 permit 授权、paymaster 与委托授权三类机制，并说明 permit 单独不足以完成后续业务交易。
• 能说明各路径的适用条件与用户侧表现。

高级回答

• 能给出包含风控、成本归属展示与失败处理的落地设计。
• 能说明 relayer 在撤销、抢先执行等情况下需要覆盖的风险控制点。

参考资料

• EIP-2612：Permit extension（§Specification、§Rationale）
• EIP-4337：Account Abstraction Using Alt Mempool（§Specification）
• EIP-7702：Set EOA account code（§Motivation、§Specification、§Security Considerations）