以太坊客户端开发商 Nethermind 的研究人员发布了一项基准测试，考察由 EIP-8141 的 MAX_VERIFY_GAS 参数定义的验证预算可以增长到多大，才不会使以太坊节点暴露于内存池拒绝服务（DoS）攻击。该研究的核心结论是：一项客户端层面的防护——在区块处理期间暂停内存池验证——正是可行的 300,000 gas 上限与在持续对抗性洪泛下耗尽节点资源的配置之间的分界线。

EIP-8141 的验证预算旨在约束什么

EIP-8141 是一份名为 "Frame Transaction" 的草案（Draft）标准跟踪核心提案。根据其声明目的，该提案为交易验证、执行和 gas 支付添加一个帧抽象层，允许交易在进入内存池并最终被打包进区块之前携带自定义验证逻辑。提案文本可在 Ethereum 的 EIP 仓库查看。内存池本身是节点存放已通过验证、等待被打包进区块的交易的队列，这也是为什么准入阶段的计算是此处讨论的 DoS 风险的焦点。

验证预算——由名为 MAX_VERIFY_GAS 的参数定义——规定了节点为一笔帧交易准入所需执行的计算量。按每笔交易 100,000 gas 计算，当前的草案上限过低，无法容纳实际用例：单证明的 Groth16 隐私支出需要 211,828 gas 进行验证，而 SPHINCS+ 签名变体最多需要 276,000 gas。因此，这一上限必须提升才具有实用性，但每一次上调都会扩大愿意用昂贵的失败交易洪泛节点的攻击者的攻击面。

任何关注过 EIP-4337 账户抽象讨论的人都熟悉这种设计上的张力：发生在执行路径之外的验证工作对攻击者来说触发成本低，但节点吸收的成本高。EIP-8141 将这类工作纳入协议强制执行的预算之中，至少使成本有了边界。然而，这一边界应设在哪里，涉及功能丰富性与内存池韧性之间的直接权衡。

EIP-8141 仍是一份草案提案，未在任何以太坊主网上激活。该基准测试的结果只是为这一设计讨论提供研究输入，并非对已部署配置的描述。

基准测试如何衡量内存池 DoS 暴露程度

Nethermind 研究人员在三台性能各异的机器上，用失败验证交易洪泛一台单核 Nethermind 节点，测试了从 100,000 到 500,000 gas 的 MAX_VERIFY_GAS 上限。核心指标是验证开销能否将区块导入延迟保持在 25 ms 预算之内——该阈值以下，正常的区块处理被视为不受并发的内存池工作负载影响。完整报告发布在 Ethereum Research 论坛上。

在没有客户端侧防护的情况下，结果相当受限。在最慢的全节点配置上，节点仅能在大约每秒 1,500 万验证 gas 的水平内保持 25 ms 的导入延迟预算。在每秒 100 笔失败交易的洪泛速率下，这一吞吐上限意味着只有 100,000 gas 的上限在预算之内——也就是说，任何能够实现现实密码学验证的上限提升，都会在典型的家庭节点硬件上制造一个可行的 DoS 攻击向量。

该基准测试评估内存池健康的两个不同维度：区块处理安全性（验证开销是否延迟区块导入？）和交易准入公平性（当攻击者发起洪泛时，诚实发送者的帧交易还能否进入内存池？）。这两个维度并不同步变化，这正是防护机制即便在第一个维度上表现出色也无法解决全部问题的原因。

防护机制及其残余代价

拟议的客户端内防护很直接：在节点处理传入区块时暂停内存池验证。这将竞争同一 CPU 内核的两个工作负载解耦，防止验证洪泛侵蚀区块导入所需的时间预算。在该防护启用的情况下，基准测试报告所有受测机器的导入延迟均降至约 2 ms 或更低，使 300,000 gas 的上限在每秒 100 笔交易的洪泛下仍能保持在 25 ms 区块处理预算之内。Nethermind 已有一个实现这种优先级行为的开放 pull request。

暂停机制解决了区块导入问题，但没有解决准入公平性问题。在 300,000 gas 上限下每秒 100 笔交易的洪泛中，最慢的受测机器仅接纳了 12% 的诚实帧交易。当节点暂停验证以处理区块时，对抗性洪泛会在间隙中填满验证队列，诚实交易被挤占。25 ms 的区块处理预算得以保全，但在持续对抗性压力下，内存池对合法帧发送者的效用急剧下降。

这种接纳崩溃在结构上类似于以太坊在高费用 NFT 铸造或套利机器人活跃时期的内存池垃圾交易动态。但 EIP-8141 使攻击更容易持续，因为攻击者只需生成能到达验证环节的交易，而非被打包上链的交易。由于这些交易验证失败，攻击者除每次验证消耗的 gas 外不承担任何打包成本——而这恰恰是协议试图约束的资源。

研究结果对以太坊客户端和节点运营商可能意味着什么

该基准测试为 300,000 gas 上限确立了一条可信路径——足以支持 Groth16 隐私交易但不支持最昂贵的 SPHINCS+ 变体——前提是每个主要以太坊客户端都实现区块处理优先的防护。这是一项协调要求，而非协议规则：EIP 本身并不强制要求客户端行为，只设定 gas 上限。如果少数节点在未携带该防护的情况下发布，这些节点在洪泛期间将成为不相称的攻击目标。以太坊的多客户端架构放大了这一协调负担：多个独立团队维护节点软件，全网行为取决于每个实现都部署同等的防护。

对于硬件处于基准测试受测范围低端的节点运营商——单核且内存带宽有限的机器——洪泛条件下仅 12% 诚实交易接纳率的结果意味着，即使在完全升级的客户端上，帧交易在对抗性拥堵期间也可能实际上不可靠。这对依赖及时内存池准入的应用影响最大，例如对时间敏感的隐私交易流程或门限签名协调协议。在 EIP-8141 之上构建的协议设计者应将对抗性内存池条件纳入活性假设，正如 Aave 等 DeFi 协议将清算延迟风险视为网络拥堵的函数而非常量一样。

在当前防护设计下、每秒 100 笔失败交易的条件下，该基准测试未将高于 300,000 gas 的上限评估为可行。要达到 500,000 gas 的上限——以容纳最重的 SPHINCS+ 变体——需要在交易传播层实施更强的速率限制、基于质押的垃圾交易过滤，或采用更低的基线洪泛速率假设。每一项都涉及超出当前 EIP-8141 草案规定范围之外的额外协议复杂性和跨客户端协调。

草案状态与待解问题

EIP-8141 仍处于草案状态，基准测试的结果直接进入了正在进行的参数讨论，而非解决它。根据 EIP 流程，处于草案阶段的提案仍需经过 Review 和 Last Call 阶段才能达到 Final 状态，MAX_VERIFY_GAS 等参数仍可基于此类研究输入进行修订。客户端开发商和 EIP 作者需要权衡 300,000 gas 上限的诚实接纳成本与需要更高预算的密码学用例，并判断区块处理优先防护是否足以作为独立缓解措施，还是需要在核心提案中加入额外的抗垃圾交易机制。

最慢机器上 12% 的接纳率数字很可能成为该讨论的焦点：在一个中等洪泛下接纳不到八分之一诚实交易的协议，即便区块最终性本身不受影响，其提供的活性保证也明显弱于当前内存池。Ethereum Research 论坛帖子和 Nethermind 的开放 pull request 是这一评估将继续推进的两个有据可查的场所。