EIP-8141 的 Mempool 策略

概览

EIP-8141 frame 交易在协议层面上被有意设计得非常灵活。交易格式本身对验证和 Gas 支付逻辑的限制非常少 —— 它只是提供了原语，并将策略留给执行层。

这意味着 Mempool 在决定接受和传播哪种类型的 frame 交易时有很大的选择余地。不同的策略在简单性、安全性和无许可性之间进行权衡。本文概述了三种渐进且更具雄心的方案，每种方案都是 EIP-8141 有效的公共 Mempool 策略。

在启动时采用限制性策略是可以的。Mempool 规则稍后可以放宽。我们目前倾向于策略 2，并且在 该 PR 中有完整定义。

共享验证规则

所有策略都使用相同的基础规则：

• 验证必须是局部稳定的。 一笔交易不能依赖于与其他交易相同的状态。
• 验证期间的存储读取仅限于 tx.sender。 可以调用辅助合约，但它们必须遵守相同的规则。
• 在验证期间禁止使用不稳定或不安全的操作码，包括依赖于区块的值、依赖于交易的值、状态写入、余额读取和其他上下文敏感的操作，但对于确定性部署和标准的 GAS -> *CALL 模式有狭义的例外。
• 节点在 Mempool 中仅模拟验证前缀：一旦 payer_approved 变为 true，交易就被认为是可以包含的。这还额外受到 MAX_VERIFY_GAS 的限制。另一种可能性是将来允许账户白名单 —— 有了这一点，就有可能完全避免模拟并原生实现检查。目前我们仅将其作为一个想法提出，而非提案。
• 公共 Mempool 中每个发送者仅允许一笔待处理的 frame 交易。这与 ERC-4337 和 EIP-7702 的 Mempool 行为一致。
• 仅允许对现有的、非委派的合约进行外部调用，且被调用的代码必须遵守相同的存储/操作码限制。
• 允许通过使用已知的确定性部署器的初始 deploy frame 进行账户部署。
• 难点在于 Paymaster：一个 Paymaster 可以赞助许多用户，这重新引入了共享依赖关系。下面概述了处理这一问题的不同方法。

策略 1：仅限自中继 (Self-Relay)

策略： 公共 Mempool 仅接受自筹资金的交易。

支持的前缀：

• self_verify
• deploy -> self_verify

特性：

• 最简单的实现
• 完整的签名抽象，即完整的 Account Abstraction
• 最小的 DoS 风险
• 赞助交易仍然有效，但 仅通过 Bundler/私有流程

这更多是一种初始策略，或者是在我们打算非常保守时特别选择的。

策略 2：规范 Paymaster 支持

策略： 支持自筹资金的交易，以及通过 标准规范 Paymaster 进行的赞助交易。

支持的前缀：

• self_verify
• deploy -> self_verify
• only_verify -> pay
• deploy -> only_verify -> pay

运作方式：

• 发送者批准执行
• 规范 Paymaster 批准支付
• 通过精确的运行时代码匹配来识别 Paymaster

为什么它是安全的：

• Paymaster 资金只能通过 Gas 支付或延迟提现离开
• 节点为每个 Paymaster 实例预留待处理余额
• 这防止了一个 Paymaster 过度承诺资金或廉价地使许多交易失效

特性：

• 中等复杂度
• 低 DoS 风险
• 无需声誉系统的原生公共 Mempool 赞助

这是一个功能基本齐全且带有原生赞助支持的策略。

策略 3：完整的 ERC-7562

策略： 允许任意的 Paymaster 和其他实体，并通过 质押和声誉 (staking and reputation) 进行门控。

运作方式：

• 质押实体获得更灵活的验证行为，例如使用禁用的操作码和存储等
• 节点跟踪声誉并限制或禁止违规实体

特性：

• 最高灵活性，即接受任意 Paymaster 合约
• 最高的实现和运营复杂度
• DoS 风险通过经济手段而非结构性手段进行管理

这可能是后期阶段的策略，当我们需要灵活的 Paymaster 逻辑且无需对该逻辑达成共同协议时使用。

比较

即使是策略 1) 也能提供广泛的预期 AA 成果，包括对 PQ 加密算法的支持。这主要是一个关于 Paymaster 在公共 Mempool 中应获得多少支持以及对它们施加哪些合理约束的光谱。

建议

从 策略 2 开始。它在以下 PR 中有详细说明：https://github.com/ethereum/EIPs/pull/11415

它保留了 EIP-8141 的主要优势 —— 自定义验证、账户部署和原生 Gas 赞助 —— 同时保持安全模型简单且可审计。策略 1 是一个非常谨慎发布时的良好后备方案。策略 3 是未来可能的扩展。

• 原文链接： hackmd.io/@matt/frame-me...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～