以太坊客戶端開發商 Nethermind 的研究人員發布了一項基準測試，檢視 EIP-8141 的 MAX_VERIFY_GAS 參數所定義的驗證預算可以成長到多高，才不會使以太坊節點暴露於記憶體池阻斷服務（DoS）攻擊。該研究的核心發現是，一項客戶端層級的防護——在處理區塊時暫停記憶體池驗證——正是可行的 300,000 gas 上限，與在持續對抗性洪泛下耗盡節點資源的設定之間的差別。

EIP-8141 的驗證預算旨在約束什麼

EIP-8141 是一份名為「Frame Transaction」的草案（Draft）標準追蹤核心（Standards Track Core）提案。根據其聲明的目的，該提案為交易驗證、執行與 gas 支付增加一個框架（frame）抽象層，使交易在進入記憶體池並最終被納入區塊之前，能夠攜帶自訂驗證邏輯。提案文本可在 以太坊 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 節點，涵蓋三台效能各異的機器，測試的 MAX_VERIFY_GAS 上限範圍為 100,000 至 500,000 gas。核心指標是驗證開銷是否能將區塊導入延遲維持在 25 毫秒預算內——該門檻之下，正常的區塊處理被視為不受並發記憶體池工作負載影響。完整報告發表於 Ethereum Research 論壇。

在缺乏客戶端防護的情況下，結果相當受限。在最慢的全節點設定檔上，節點僅能在每秒約 1,500 萬驗證 gas 的範圍內維持 25 毫秒的導入延遲預算。在每秒 100 筆失敗交易的洪泛率下，該吞吐量上限使只有 100,000 gas 上限在預算之內——這意味著任何能支援實際密碼學驗證的上限提升，都會在一般家庭節點營運者的硬體上創造出可行的 DoS 攻擊向量。

該基準測試評估記憶體池健康的兩個不同軸向：區塊處理安全性（驗證開銷是否延誤區塊導入？）與交易准入公平性（當攻擊者洪泛時，誠實的發送者是否仍能將其框架交易送入記憶體池？）。這兩個軸向並不同步變動，這就是為何即使防護機制在第一個軸向上表現良好，也無法解決完整問題的原因。

防護機制及其殘餘成本

提議的客戶端內防護相當直接：在節點處理傳入區塊時暫停記憶體池驗證。這解耦了爭用同一 CPU 核心的兩個工作負載，防止驗證洪泛侵蝕區塊導入所需的時間預算。在啟用此防護的情況下，基準測試報告指出，所有受測機器的導入延遲都降至約 2 毫秒或更低，使 300,000 gas 上限在每秒 100 筆交易的洪泛下仍能維持在 25 毫秒的區塊處理預算之內。Nethermind 有一個實作此優先行為的開放式 pull request。

暫停機制解決了區塊導入問題，但未解決准入公平性問題。在 300,000 gas 上限下遭遇每秒 100 筆交易洪泛時，最慢的受測機器僅接受了 12% 的誠實框架交易。當節點暫停驗證以處理區塊時，對抗性洪泛會在空檔中填滿驗證佇列，誠實交易便被擠出。25 毫秒的區塊處理預算得以維持，但在持續的對抗性壓力下，記憶體池對合法框架交易發送者的效用急劇下降。

這種准入崩潰在結構上類似於以太坊在高費率 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 流程，處於草案階段的提案在達到最終（Final）狀態前，仍需經過審查（Review）與最後徵求意見（Last Call），使得 MAX_VERIFY_GAS 等參數可以基於這類研究輸入進行修訂。客戶端開發者與 EIP 作者將需要權衡 300,000 gas 上限的誠實准入成本與需要更高預算的密碼學使用場景，並判斷區塊處理優先防護是否足以作為獨立的緩解措施，或者核心提案中是否應加入額外的垃圾交易抵抗機制。

最慢機器上 12% 的准入數字很可能成為該討論的焦點：在中等洪泛下，若某協議接納的誠實交易少於八分之一，其提供的活性保證就明顯弱於目前的記憶體池，即使區塊最終性本身不受影響。Ethereum Research 論壇討論串與 Nethermind 的開放式 pull request 是該評估將持續進行的兩個有據可查的場所。