为什么 Pay Protocol 暂时不用 ERC-4337?
· 阅读需 7 分钟
在区块链领域,ERC-4337(Account Abstraction)最近几年很火。它提出了一种新的账户体系,让钱包不再局限于传统的外部账户(EOA),而是可以完全用智能合约来定义。
听起来很理想:
- 用户操作通过 UserOperation(UserOps) 来提交,而不是普通的交易。
- Bundler 会收集用户的 UserOps,打包成一笔交易,再提交到区块链。
- 账户逻辑(签名方式、多重验证、限额、恢复机制)完全由合约控制,钱包体验更灵活。
但我们在深入研究后发现:ERC-4337 在支付业务中的现实效果,并没有理想中那么完美。
1. 成本问题:Gas 并没 有更省
-
ERC-4337 的问题
- 每一笔 UserOps 需要单独验证签名、nonce、限额逻辑。
- 这些校验不是由区块链主协议原生执行,而是由 Bundler 在内存池里模拟完成。
- 最终提交到链上的 calldata 会更长、更复杂,导致 交易费用往往是普通交易的 2–3 倍。
- 这笔额外开销,本质上就是“用更高的成本换来了更复杂的钱包逻辑”。
-
Pay Protocol 的方案
- 用户不需要自己操作,商户端可以批量打包,显著降低成本。
- 没有额外验证逻辑,链上数据更简洁,Gas 消耗比标准交易还便宜。
👉 在支付场景里,低成本远比复杂功能更重要。商户要的是“每笔更便宜”,而不是“更炫的签名方式”。
2. 兼容性问题
-
ERC-4337 的问题
- 标准虽然统一了 UserOps 的接口,但具体实现差异很大。
- 不同服务商(如 ZeroDev、Biconomy)提供的智能合约钱包结构并不一致。
- 应用层如果想要支持多家,兼容成本极高。实际上,开发者往往会被迫选择其中一家,然后被锁定在它的生态里。
-
Pay Protocol 的方案
- 我们的无私钥账户基于合约工厂,遵循标准 EVM 逻辑。
- 只要是 EVM 公链,就能开箱即用,不依赖某个特定服务商。
👉 对商户来说,开放的真正意义不是“新标准”,而是“随时换链、随时接入”。
3. 升级与维护:Proxy 的复杂性 vs 模板的简洁性
-
ERC-4337 的问题
-
合约钱包一旦部署,逻辑就固化了。
-
如果需要加新功能,通常要通过 Proxy 升级模式:
- 先写一个新的逻辑合约。
- 修改 Proxy 指针,指向新逻辑。
- 处理旧数据迁移和安全审计。
-
这个过程不仅繁琐,还容易引入新的漏洞,审计成本也会提高。
-
-
Pay Protocol 的方案
- 无私钥账户是基于模板合约批量生成的。
- 如果需要升级,只需发布一个新版模板,再批量生成新账户。
- 不需要处理 Proxy 的复杂性,迁移路径简单直接。
👉 简洁就是安全,越复杂的合约结构,出问题的概率越高。
4. 安全风险:更强的灵活性,也带来更大的攻击面
-
ERC-4337 的问题
- 由于账户逻辑是可编程的,理论上可以支持任何签名或权限控制方式。
- 但灵活性越强,安全边界也越模糊。
- 过去已经出现过案例:攻击者可以通过漏洞创建“未授权的账户”,甚至绕过验证。
- 在支付业务里,这样的风险是不可接受的。
-
Pay Protocol 的方案
- 无私钥账户的逻辑极其简洁:就是一份工厂合约,负责生成标准账户。
- 没有复杂的多重验证或外部依赖,也就没有额外的攻击面。
👉 对支付行业来说,安全第一。
对比总结
维度 | ERC-4337 | Pay Protocol 无私钥账户 |
---|---|---|
成本 | UserOps 成本高出 2–3 倍,Gas 成本增加 | 商户批量汇总,操作低廉,Gas 成本极低 |
兼容性 | 服务商差异大,应用层难以跨平台 | 任意 EVM 链可直接使用 |
升级维护 | 需通过 Proxy 升级,复杂且成本高 | 模板一更,批量搞定,维护简单 |
安全风险 | 灵活但攻击面大,已有漏洞案例 | 逻辑极简,攻击面小 |
我们的结论
ERC-4337 代表了钱包发展的未来方向:更灵活、更个性化、更智能。但它目前还处在早期阶段,生态并不成熟:
- Bundler 运行依赖少数几家服务商 → 现实上的中心化。
- 成本偏高 → 不适合高频 支付。
- 升级与兼容性不够友好 → 增加维护成本。
对支付业务而言,省钱、省心、安全才是最核心的价值。
所以,Pay Protocol 暂时不会采用 ERC-4337,而是选择了 更直接、可控、稳定的无私钥账户方案,为商户和用户提供今天就能用、而且足够安全的支付体验。
一句话总结:ERC-4337 是未来,但 Pay Protocol 要解决的是今天的支付问题。