Onderzoekers van Ethereum-clientontwikkelaar Nethermind hebben een benchmark gepubliceerd die onderzoekt hoe groot het validatiebudget dat wordt gedefinieerd door EIP-8141's parameter MAX_VERIFY_GAS kan worden voordat Ethereum-nodes worden blootgesteld aan denial-of-service-aanvallen (DoS) op de mempool. De centrale bevinding van de studie is dat een bescherming op clientniveau — het pauzeren van mempool-validatie terwijl een blok wordt verwerkt — het verschil is tussen een levensvatbare limiet van 300.000 gas en een configuratie die nodebronnen uitput onder een aanhoudende vijandige vloed.

Wat het validatiebudget van EIP-8141 beoogt te beperken

EIP-8141 is een Draft Standards Track Core-voorstel getiteld "Frame Transaction." Volgens het vermelde doel voegt het voorstel een frame-abstractielaag toe voor transactievalidatie, uitvoering en gasbetaling, waardoor transacties aangepaste validatielogica kunnen meedragen voordat ze worden toegelaten tot de mempool en uiteindelijk in een blok worden opgenomen. De voorsteltekst is beschikbaar in Ethereum's EIP-repository. De mempool zelf is de wachtrij waarin nodes transacties bewaren die validatie hebben doorstaan terwijl ze wachten op opname in een blok, en dat is waarom berekening in de toelatingsfase het brandpunt is van de hier besproken DoS-zorg.

Het validatiebudget — gedefinieerd door een parameter genaamd MAX_VERIFY_GAS — stelt hoeveel rekenwerk een node moet verrichten om één frame-transactie toe te laten. Bij 100.000 gas per transactie is de huidige conceptlimiet te laag voor praktische gebruiksscenario's: een single-note Groth16-privacyuitgave vereist 211.828 gas voor validatie, en SPHINCS+-handtekeningvarianten vragen tot 276.000 gas. De limiet moet dus groeien om praktisch te zijn, maar elke verhoging vergroot het aanvalsoppervlak voor tegenstanders die bereid zijn nodes te overstelpen met dure mislukte transacties.

De ontwerpspanning is bekend bij iedereen die het debat over accountabstratie rond EIP-4337 heeft gevolgd: validatiewerk dat buiten het uitvoeringspad plaatsvindt is goedkoop voor aanvallers om te triggeren maar duur voor nodes om op te vangen. EIP-8141 verplaatst dat werk naar een protocolafgedwongen budget, wat de kosten in elk geval begrenst. Waar die grens moet liggen, is echter een directe afweging tussen functionele rijkdom en mempool-veerkracht.

EIP-8141 blijft een conceptvoorstel en is niet geactiveerd op een live Ethereum-netwerk. De benchmarkresultaten zijn onderzoeksinvoer voor dat ontwerpdebat, geen beschrijving van een uitgerolde configuratie.

Hoe de benchmark mempool-DoS-blootstelling meet

De Nethermind-onderzoekers overspoelden een Nethermind-node met één kern met mislukte validatietransacties op drie machines met uiteenlopende prestaties, waarbij MAX_VERIFY_GAS-limieten van 100.000 tot 500.000 gas werden getest. De kernmetriek was of de validatieoverhead de blokimportlatentie binnen een budget van 25 ms hield — de drempel waaronder normale blokverwerking als onaangetast geldt door de gelijktijdige mempool-werklast. De volledige beschrijving staat op het Ethereum Research-forum.

Zonder bescherming aan de clientzijde waren de resultaten beperkend. Op het langzaamste full-node-profiel bleef de node slechts tot circa 15 miljoen validatie-gas per seconde binnen het importvertragingsbudget van 25 ms. Bij een vloed van 100 mislukte transacties per second liet dat doorvoerplafond alleen de limiet van 100.000 gas binnen budget — wat betekent dat elke limietverhoging die realistische cryptografische validatie mogelijk maakt ook een levensvatbare DoS-vector creëert op hardware die typisch is voor thuis-nodebeheerders.

De benchmark evalueert twee verschillende dimensies van mempool-gezondheid: blokverwerkingsveiligheid (vertraagt validatieoverhead de blokimport?) en toelatingsrechtvaardigheid (krijgen eerlijke verzenders hun frame-transacties nog in de mempool wanneer een tegenstander overstroomt?). Deze twee dimensies bewegen niet samen, en daarom lost het beschermingsmechanisme het volledige probleem niet op, zelfs niet wanneer het de eerste dimensie goed afhandelt.

Het beschermingsmechanisme en de restkosten

De voorgestelde bescherming in de client is eenvoudig: pauzeer mempool-validatie terwijl de node een binnenkomend blok verwerkt. Dit ontkoppelt de twee werklasten die om dezelfde CPU-kern concurreren, zodat een validatievloed niet ten koste gaat van de tijdsbegroting die blokimport nodig heeft. Met deze bescherming actief daalde de importvertraging volgens de benchmark tot circa 2 ms of minder op elke geteste machine, waardoor een limiet van 300.000 gas bij een vloed van 100 transacties per seconde binnen het budget van 25 ms voor blokverwerking bleef. Nethermind heeft een open pull request dat dit prioriteringsgedrag implementeert.

Het pauzemechanisme lost het blokimportprobleem op, maar niet het probleem van toelatingsrechtvaardigheid. Onder een vloed van 100 transacties per second bij de limiet van 300.000 gas admitteerde de langzaamste geteste machine slechts 12% van de eerlijke frame-transacties. Wanneer de node validatie pauzeert om blokken te verwerken, vult de vijandige vloed de validatiewachtrij in de tussenliggende gaten en worden eerlijke transacties verdrongen. Het budget van 25 ms voor blokverwerking blijft behouden, maar het nut van de mempool voor legitieme frame-verzenders verslechtert scherp onder aanhoudende vijandige druk.

Deze toelatingsinvaluatie lijkt structureel op de mempool-spam-dynamiek die Ethereum trof tijdens periodes van dure NFT-mints of arbitrage-botactiviteit. EIP-8141 maakt de aanval echter goedkoper om vol te houden, omdat de tegenstander slechts transacties hoeft te genereren die validatie bereiken, niet transacties die on-chain worden opgenomen. Omdat de transacties mislukken bij validatie, dragen ze voor de aanvaller geen opnamekosten buiten het per-validatie verbruikte gas — precies de bron die het protocol probeert te begrenzen.

Wat de bevindingen kunnen betekenen voor Ethereum-clients en nodebeheerders

De benchmark legt een geloofwaardig pad naar een limiet van 300.000 gas bloot — hoog genoeg om Groth16-privacytransacties te ondersteunen maar niet de duurste SPHINCS+-varianten — op voorwaarde dat elke belangrijke Ethereum-client de bescherming met blokverwerkingsprioriteit implementeert. Dit is een coördinatievereiste, geen protocolleregel: de EIP zelf schrijft het clientgedrag niet voor en stelt alleen het gasplafond vast. Als een minderheid van de nodes zonder de bescherming wordt uitgerold, worden die nodes onevenredige doelen tijdens een vloed. Die coördinatielast wordt versterkt door Ethereum's multi-client-architectuur, waarin meerdere onafhankelijke teams node-software onderhouden en netwerkbreed gedrag afhangt van het leveren van gelijkwaardige beschermingen door elke implementatie.

Voor nodebeheerders die hardware aan de onderkant van het geteste bereik van de benchmark draaien — een machine met één kern en beperkte geheugenbandbreedte — betekent het resultaat van 12% toelating van eerlijke transacties onder vloedomstandigheden dat frame-transacties feitelijk onbetrouwbaar kunnen worden tijdens periodes van vijandige congestie, zelfs op een volledig bijgewerkte client. Dit is het relevantst voor applicaties die afhangen van snelle mempool-toelating, zoals tijdsgevoelige privétransactiestromen of coördinatieprotocollen voor drempelhandtekeningen. Protocolontwerpers die bovenop EIP-8141 bouwen moeten vijandige mempool-omstandigheden meenemen in liveness-aannames, op dezelfde manier waarop DeFi-protocollen zoals Aave liquidatielatentierisico behandelen als een functie van netwerkcongestie in plaats van een constante.

De benchmark beoordeelt limieten boven 300.000 gas niet als levensvatbaar onder het huidige beschermingsontwerp bij 100 mislukte transacties per seconde. Het bereiken van het plafond van 500.000 gas — dat de zwaarste SPHINCS+-varianten zou accommoderen — zou sterkere tariefbeperking op de transactiepropagatielaag, op inzet gebaseerde spamfiltering of een lagere aanname over de basisvloedsnelheid vereisen. Elk hiervan brengt extra protocolcomplexiteit en cross-client-coördinatie met zich mee buiten wat het huidige EIP-8141-concept specificeert.

Conceptstatus en open vragen

EIP-8141 bevindt zich nog in de Draft-status, en de benchmarkresultaten voeden rechtstreeks het lopende parameterdebat zonder het op te lossen. Volgens het EIP-proces passeren voorstellen in de Draft-fase nog Review en Last Call voordat ze de Final-status bereiken, waarbij parameters zoals MAX_VERIFY_GAS openstaan voor herziening op basis van precies dit soort onderzoeksinvoer. Clientontwikkelaars en EIP-auteurs zullen de kosten van eerlijke toelating bij de limiet van 300.000 gas moeten afwegen tegen de cryptografische gebruiksscenario's die hogere budgetten vereisen, en moeten vaststellen of de bescherming met blokverwerkingsprioriteit voldoende is als zelfstandige mitigerende maatregel of dat extra spamweerstandsmechanismen in het kernvoorstel thuishoren.

Het toelatingscijfer van 12% op de langzaamste machine wordt waarschijnlijk een brandpunt van dat debat: een protocol dat minder dan één op de acht eerlijke transacties admitteert onder een gematigde vloed biedt aantoonbaar zwakkere liveness-garanties dan de huidige mempool, zelfs als de blokfinaliteit zelf onaangetast blijft. De forumdraad op Ethereum Research en Nethermind's open pull request zijn de twee gedocumenteerde plekken waar die beoordeling zich zal blijven afspelen.