Ethereumクライアント開発者のNethermindの研究者らは、EIP-8141のMAX_VERIFY_GASパラメータで定義される検証予算が、Ethereumノードがメモリプールへのサービス拒否（DoS）攻撃に晒されるまでどこまで拡大できるかを検証するベンチマークを公開した。研究の中核的な発見は、ブロック処理中にメモリプール検証を一時停止するというクライアントレベルの保護の有無こそが、実現可能な300,000ガスの上限と、持続的な敵対的フラッド下でノードリソースを使い尽くす構成との分かれ目になるというものだ。

EIP-8141の検証予算が制約しようとしているもの

EIP-8141は「Frame Transaction」と題されたDraft Standards Track Core提案である。その明示された目的は、トランザクション検証・実行・ガス支払いのためのフレーム抽象化レイヤーを追加し、トランザクションがメモリプールに受理され最終的にブロックに取り込まれる前に、カスタム検証ロジックを保持できるようにすることだ。提案本文はEthereumのEIPリポジトリで公開されている。メモリプール自体は、検証を通過したトランザクションがブロックへの取り込みを待つ間ノードが保持するキューであり、そのため受理段階での計算量が、ここで論じられているDoS懸念の焦点となっている。

検証予算——MAX_VERIFY_GASと呼ばれるパラメータで定義される——は、単一のフレームトランザクションを受理するためにノードが実行しなければならない計算量を設定する。トランザクションあたり100,000ガスでは、現行のドラフト上限は実際のユースケースには低すぎる。単一ノートのGroth16プライバシー支払いには検証に211,828ガスが必要であり、SPHINCS+署名の変種は最大276,000ガスを要求する。したがって上限は実用性のために引き上げられる必要があるが、引き上げのたびに、高コストな検証失敗トランザクションでノードをフラッドしようとする敵対者への攻撃対象領域が拡大する。

この設計上の緊張関係は、EIP-4337のアカウントアブストラクション議論を追った人には馴染み深いものだ。実行パス外で行われる検証作業は、攻撃者には引き起こすのが安価だが、ノードには吸収するのが高コストである。EIP-8141はその作業をプロトコルで強制される予算の中に移し、少なくともコストに上限を設けている。しかし、その上限をどこに置くかは、機能の豊富さとメモリプールの耐性との直接的なトレードオフを伴う。

EIP-8141は依然としてドラフト提案であり、いかなる稼働中のEthereumネットワークでも有効化されていない。ベンチマークの結果はその設計議論への研究インプットであり、導入済みの構成を示すものではない。

ベンチマークがメモリプールDoSへの露出を測定する方法

Nethermindの研究者らは、性能の異なる3台のマシン上で単一コアのNethermindノードに検証失敗トランザクションをフラッドし、100,000から500,000ガスまでのMAX_VERIFY_GAS上限をテストした。中核的な指標は、検証オーバーヘッドがブロック取り込みレイテンシを25 ms予算内に収められるかどうか——同時進行するメモリプール作業の影響を受けないと見なされる閾値——であった。詳細なレポートはEthereum Researchフォーラムで閲覧できる。

クライアント側の保護がない場合、結果は制約的だった。最も低速なフルノードプロファイルでは、ノードが25 msの取り込み遅延予算内に収まったのは概ね毎秒1,500万検証ガスまでだった。毎秒100件の検証失敗トランザクションのフラッドレートでは、このスループット上限により予算内に収まるのは100,000ガスの上限だけとなった。つまり、実際の暗号検証を可能にするいかなる上限引き上げも、一般のホームノード運用者の典型的なハードウェア上で実現可能なDoSベクトルを生み出すことを意味する。

このベンチマークは、メモリプールの健全性の2つの異なる軸を評価する。ブロック処理の安全性（検証オーバーヘッドがブロック取り込みを遅延させるか？）と、トランザクション受理の公平性（敵対者がフラッドしている間も正規の送信者はフレームトランザクションをメモリプールに投入できるか？）である。この2つの軸は連動しないため、保護機構は最初の軸をうまく処理しても問題全体を解決しない。

保護機構とその残存コスト

提案されているクライアント内保護はシンプルだ。ノードが入力ブロックを処理している間、メモリプール検証を一時停止する。これにより同一CPUコアを奪い合う2つの作業負荷が分離され、検証フラッドがブロック取り込みに必要な時間予算を食いつぶすのを防ぐ。この保護が有効な状態で、ベンチマークは全テストマシンで取り込み遅延が約2 ms以下に低下し、100トランザクション/秒のフラッド下でも300,000ガスの上限が25 msのブロック処理予算内に収まり続けると報告している。Nethermindはこの優先順位付け動作を実装するオープンなプルリクエストを公開している。

この一時停止機構はブロック取り込みの問題は解決するが、受理の公平性の問題は解決しない。300,000ガス上限での100トランザクション/秒のフラッド下で、最も低速なテストマシンが受理できた正規のフレームトランザクションはわずか12%だった。ノードがブロック処理のために検証を一時停止すると、その隙間に敵対的フラッドが検証キューを埋め、正規のトランザクションは締め出される。25 msのブロック処理予算は維持されるが、持続的な敵対的圧力下では、正規のフレーム送信者にとってメモリプールの有用性が急激に低下する。

この受理の崩壊は、高額な手数料のNFTミントやアービトラージボットの活動が続いた時期にEthereumを襲ったメモリプールスパムの動態と構造的に類似している。ただしEIP-8141は、攻撃者が検証に到達するトランザクションを生成するだけでよく、オンチェーンに取り込まれるトランザクションは必要としないため、攻撃を持続させるコストが低い。トランザクションは検証に失敗するため、攻撃者にとっての取り込みコストは消費された検証ごとのガスのみであり、これはまさにプロトコルが上限を設けようとしているリソースである。

この結果がEthereumクライアントとノード運用者に意味しうること

このベンチマークは、すべての主要Ethereumクライアントがブロック処理優先の保護を実装することを条件に、300,000ガスの上限への信頼できる道筋を示している。これはGroth16プライバシートランザクションを支援するには十分だが、最も高コストなSPHINCS+変種には不十分な水準だ。これは調整要件であってプロトコルのルールではない。EIP自体はクライアントの動作を義務付けておらず、ガス上限のみを設定する。少数のノードが保護なしでリリースされれば、それらのノードはフラッド時に不釣り合いな攻撃対象となる。この調整負担は、複数の独立したチームがノードソフトウェアを保守し、ネットワーク全体の動作が各実装が同等の保護を搭載することに依存するEthereumのマルチクライアントアーキテクチャによって増幅される。

ベンチマークのテスト範囲の下限にあたるハードウェア——メモリ帯域幅が限られたシングルコアマシン——を運用するノード運用者にとって、フラッド条件下で正規トランザクションの受理が12%という結果は、完全にアップグレードされたクライアント上であっても、敵対的な混雑期間中にフレームトランザクションが事実上信頼できなくなりうることを意味する。これは、時間的制約の厳しいプライベートトランザクションフローや閾値署名調整プロトコルなど、迅速なメモリプール受理に依存するアプリケーションに最も影響する。EIP-8141の上に構築するプロトコル設計者は、AaveなどのDeFiプロトコルが清算レイテンシリスクを定数ではなくネットワーク混雑の関数として扱うのと同様に、敵対的なメモリプール条件をライブネスの前提に織り込むべきだ。

このベンチマークは、100検証失敗トランザクション/秒の条件下で現行の保護設計では300,000ガスを超える上限を実現可能と評価していない。最も重いSPHINCS+変種に対応する500,000ガスの上限に到達するには、トランザクション伝播レイヤーでのより強力なレート制限、ステークに基づくスパムフィルタリング、またはより低い基準フラッドレートの前提が必要となる。これらのいずれも、現行のEIP-8141ドラフトが定める範囲を超える追加のプロトコル複雑性とクライアント間調整を伴う。

ドラフト段階と未解決の論点

EIP-8141は依然としてDraft段階にあり、ベンチマークの結果は議論を決着させるのではなく、進行中のパラメータ議論に直接反映される。EIPプロセスでは、Draft段階の提案はFinalに達する前にReviewとLast Callを経過し、MAX_VERIFY_GASなどのパラメータはまさにこの種の研究インプットに基づいて修正可能なままとなる。クライアント開発者とEIPの作者らは、300,000ガス上限の正規トランザクション受理コストと、より高い予算を必要とする暗号学的ユースケースを比較考量し、ブロック処理優先の保護が単独の緩和策として十分か、あるいは追加のスパム耐性機構がコア提案に含まれるべきかを判断する必要がある。

最も低速なマシンでの12%という受理率は、その議論の焦点となりそうだ。中程度のフラッド下で8件に満たない正規トランザクションしか受理しないプロトコルは、ブロックファイナリティ自体が影響を受けないとしても、現行のメモリプールより実質的に弱いライブネス保証を提供する。Ethereum ResearchフォーラムのスレッドとNethermindのオープンなプルリクエストは、その評価が今後展開される2つの文書化された場である。