扩展EIP-8141：构建完整的协议级账户抽象层

EIP-8141 当前的优点

在讨论扩展 EIP-8141 之前，有必要先厘清它已经做对的事情。即使以当前形式来看，它也在原生账户抽象方面取得了有意义的进展，并弥合了几个长期存在的缺口：

• Gas 赞助成为一等公民，而非外部服务。
• 原生支持交易批处理，实现更丰富的用户体验流程。
• 可编程的验证逻辑允许每个账户自定义授权策略。
• 优先兼容 EOA，意味着现有账户无需迁移即可受益。
• 可组合的执行，在单个流程中实现多步骤交互。

与当前基于 ERC-4337 及其相关提案（如 EIP-7702）的技术栈相比，这已经是一个阶跃式的进步。它减少了对 bundler 和 relayer 的依赖，并将账户抽象的重要部分引入协议本身。

但止步于此将是一个错误！

仍然存在的关键缺口

仍然存在一些尚未解决的关键缺口，而这些缺口正逐渐成为实际使用的标准需求：

• 原生不支持 ERC-20 Gas 偿还机制，迫使开发者采用外部中继模式。
• 缺少公钥访问，限制了对替代密码学和后量子准备的支持。
• 缺乏 nonce 灵活性（即二维 nonce），限制了并行交易流程。
• 没有内置有效性窗口（时间绑定执行），而这对现代基于意图的系统至关重要。

这些并非边缘情况。它们是开发者必然需要的基础能力。如果不在协议层面提供，它们将在其他地方被重建，从而重新引入 EIP-8141 试图消除的碎片化问题。

为什么扩展至关重要

重要的观察是，EIP-8141 已经非常接近完善。扩展其优势并不需要全新的架构或臃肿的功能集合。它只需要引入少量额外的原语，就能解锁广泛的用例。

为什么？因为：

• 添加原生 ERC-20 偿还机制，消除了对整个中继生态系统的需求。
• 公开公钥，支持面向未来的认证和后量子密码曲线，而不会引起协议变动。
• 支持二维 nonce 和有效性窗口，直接在基础层实现更安全、并行且更具表达力的交易流程。

每个添加的功能单独看来都很小，但加在一起就补齐了整个拼图。它们将 EIP-8141 从一个坚实的基础转化为一个完全通用的账户抽象层。

这就是为什么在这里选择保守反而是危险的。协议变更非常罕见且难以迭代。如果我们现在范围定义过窄，实际上是在选择以后通过链下系统、供应商依赖和碎片化标准来重新引入复杂性。如果我们深思熟虑地扩展 EIP-8141，我们可以在基础设施变得根深蒂固之前将其整个类别移除。

我们在协议层面重新定义原语的机会寥寥无几。这就是其中之一。

因此，目标不应该是为了“让它能工作”而只做最低限度的事。目标应该是确保原语足够完整，以支持未来十年的创新，而无需不断打补丁。

不是更多的功能。只是正确的功能！

因为如果我们把这些做对了……其他一切都变成可选项。

• 原文链接： x.com/pedrouid/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～