Forscher des Ethereum-Client-Entwicklers Nethermind haben einen Benchmark veröffentlicht, der untersucht, wie groß das durch den Parameter MAX_VERIFY_GAS von EIP-8141 definierte Validierungsbudget werden kann, bevor Ethereum-Knoten gegenüber Mempool-Denial-of-Service-Angriffen (DoS) exponiert werden. Die zentrale Erkenntnis der Studie lautet, dass ein Schutz auf Client-Ebene — das Pausieren der Mempool-Validierung während der Verarbeitung eines Blocks — den Unterschied zwischen einer tragfähigen Obergrenze von 300.000 Gas und einer Konfiguration ausmacht, die die Ressourcen der Knoten unter anhaltender adversarieller Flut erschöpft.

Wozu das Validierungsbudget von EIP-8141 dienen soll

EIP-8141 ist ein Draft-Entwurf auf dem Standards Track Core mit dem Titel "Frame Transaction." Dem angegebenen Zweck nach fügt der Entwurf eine Frame-Abstraktionsschicht für Transaktionsvalidierung, Ausführung und Gaszahlung hinzu, wodurch Transaktionen benutzerdefinierte Validierungslogik mitführen können, bevor sie in den Mempool aufgenommen und schließlich in einen Block eingebunden werden. Der Entwurfstext ist im EIP-Repository von Ethereum verfügbar. Der Mempool selbst ist die Warteschlange, in der Knoten Transaktionen halten, die die Validierung bestanden haben und auf ihre Aufnahme in einen Block warten — weshalb die Rechenleistung in der Aufnahmephase der Kernpunkt der hier diskutierten DoS-Sorge ist.

Das Validierungsbudget — definiert durch einen Parameter namens MAX_VERIFY_GAS — legt fest, wie viel Rechenleistung ein Knoten aufwenden muss, um eine einzelne Frame-Transaktion aufzunehmen. Mit 100.000 Gas pro Transaktion ist die aktuelle Entwurfsgrenze zu niedrig, um reale Anwendungsfälle abzudecken: Ein Groth16-Privacy-Spend mit einer Note erfordert 211.828 Gas für die Validierung, und SPHINCS+-Signaturvarianten benötigen bis zu 276.000 Gas. Die Obergrenze muss daher wachsen, um praktikabel zu sein, doch jede Anhebung vergrößert die Angriffsfläche für Gegner, die bereit sind, Knoten mit teuren, scheiternden Transaktionen zu fluten.

Die Design-Spannung ist allen vertraut, die die Account-Abstraktion-Diskussion rund um EIP-4337 verfolgt haben: Validierungsarbeit, die außerhalb des Ausführungspfads stattfindet, ist für Angreifer günstig auszulösen, aber für Knoten teuer zu absorbieren. EIP-8141 verlagert diese Arbeit in ein protokollerzwungenes Budget, wodurch die Kosten zumindest begrenzt werden. Wo diese Grenze gezogen wird, ist jedoch ein direkter Kompromiss zwischen Funktionsreichtum und Mempool-Resilienz.

EIP-8141 bleibt ein Entwurf und ist in keinem liveen Ethereum-Netzwerk aktiviert. Die Benchmark-Ergebnisse sind ein Forschungsbeitrag zu dieser Design-Diskussion, keine Beschreibung einer eingesetzten Konfiguration.

Wie der Benchmark die Mempool-DoS-Exposition misst

Die Nethermind-Forscher fluteten einen Ein-Kern-Nethermind-Knoten mit scheiternden Validierungstransaktionen auf drei Maschinen unterschiedlicher Leistung und testeten MAX_VERIFY_GAS-Grenzen von 100.000 bis 500.000 Gas. Die Kernmetrik war, ob der Validierungsaufwand die Blockimport-Latenz innerhalb eines Budgets von 25 ms hielt — der Schwellenwert, unterhalb dessen die normale Blockverarbeitung als unbeeinflusst von der gleichzeitigen Mempool-Last gilt. Der vollständige Bericht ist im Ethereum Research Forum zu finden.

Ohne clientseitigen Schutz fielen die Ergebnisse restriktiv aus. Auf dem langsamsten Full-Node-Profil blieb der Knoten nur bis zu rund 15 Millionen Validierungs-Gas pro Sekunde innerhalb des 25-ms-Importverzögerungs-Budgets. Bei einer Flutrate von 100 scheiternden Transaktionen pro Sekunde ließ dieser Durchsatzdeckel nur die 100.000-Gas-Grenze innerhalb des Budgets — das bedeutet, jede Grenzerhöhung, die reale kryptografische Validierung ermöglicht, würde auch einen brauchbaren DoS-Vektor auf Hardware schaffen, die typisch für Heim-Knotenbetreiber ist.

Der Benchmark bewertet zwei getrennte Dimensionen der Mempool-Gesundheit: Blockverarbeitungssicherheit (verzögert Validierungsaufwand den Blockimport?) und Aufnahmefairness (kommen ehrliche Sender unter Flut noch mit ihren Frame-Transaktionen in den Mempool?). Diese beiden Dimensionen bewegen sich nicht gemeinsam — weshalb der Schutzmechanismus das gesamte Problem nicht löst, selbst wenn er die erste Dimension gut beherrscht.

Der Schutzmechanismus und seine Restkosten

Der vorgeschlagene clientseitige Schutz ist unkompliziert: Die Mempool-Validierung wird pausiert, während der Knoten einen eingehenden Block verarbeitet. Dies entkoppelt die beiden Arbeitslasten, die um denselben CPU-Kern konkurrieren, und verhindert, dass eine Validierungsflut das Zeitbudget des Blockimports auffrisst. Bei aktivem Schutz fiel die Importverzögerung laut Benchmark auf allen getesteten Maschinen auf etwa 2 ms oder weniger, sodass eine 300.000-Gas-Grenze bei einer Flut von 100 Transaktionen pro Sekunde innerhalb des 25-ms-Budgets der Blockverarbeitung blieb. Nethermind hat einen offenen Pull Request, der dieses Priorisierungsverhalten implementiert.

Der Pausierungsmechanismus löst das Blockimport-Problem, nicht jedoch das Problem der Aufnahmefairness. Unter einer Flut von 100 Transaktionen pro Sekunde bei der 300.000-Gas-Grenze nahm die langsamste getestete Maschine nur 12 % der ehrlichen Frame-Transaktionen auf. Wenn der Knoten die Validierung pausiert, um Blöcke zu verarbeiten, füllt die adversarielle Flut die Validierungswarteschlange in den Lücken, und ehrliche Transaktionen werden verdrängt. Das 25-ms-Budget der Blockverarbeitung bleibt erhalten, aber der Nutzen des Mempools für legitime Frame-Sender verschlechtert sich unter anhaltendem adversariellem Druck erheblich.

Dieser Aufnahmeeinbruch ähnelt strukturell der Mempool-Spam-Dynamik, die Ethereum während Phasen von NFT-Mints mit hohen Gebühren oder Arbitrage-Bot-Aktivität betraf. EIP-8141 macht den Angriff jedoch günstiger aufrechtzuerhalten, da der Angreifer nur Transaktionen erzeugen muss, die die Validierung erreichen, nicht solche, die in die Blockchain eingebunden werden. Da die Transaktionen die Validierung nicht bestehen, entstehen dem Angreifer keine Einbindungskosten über das verbrauchte Gas pro Validierung hinaus — genau die Ressource, die das Protokoll begrenzen will.

Was die Ergebnisse für Ethereum-Clients und Knotenbetreiber bedeuten könnten

Der Benchmark zeigt einen glaubwürdigen Weg zu einer 300.000-Gas-Grenze — hoch genug für Groth16-Privatstransaktionen, aber nicht für die teuersten SPHINCS+-Varianten — vorausgesetzt, jeder große Ethereum-Client implementiert den Blockverarbeitungs-Prioritätsschutz. Dies ist eine Koordinationsanforderung, keine Protokollregel: Das EIP selbst schreibt das Client-Verhalten nicht vor, es setzt nur die Gas-Obergrenze. Schifft eine Minderheit von Knoten ohne den Schutz, werden diese Knoten während einer Flut zu unverhältnismäßigen Zielen. Diese Koordinationslast wird durch Ethereums Multi-Client-Architektur verstärkt, in der mehrere unabhängige Teams die Knotensoftware pflegen und das netzwerkweite Verhalten davon abhängt, dass jede Implementierung gleichwertige Schutzmechanismen ausliefert.

Für Knotenbetreiber mit Hardware am unteren Ende des getesteten Spektrums — eine Ein-Kern-Maschine mit begrenzter Speicherbandbreite — bedeutet das Ergebnis von 12 % ehrlicher Transaktionsaufnahme unter Flutbedingungen, dass Frame-Transaktionen während adversarieller Überlastung praktisch unzuverlässig werden können, selbst auf einem vollständig aktualisierten Client. Dies ist vor allem für Anwendungen relevant, die auf schnelle Mempool-Aufnahme angewiesen sind, etwa zeitempfindliche private Transaktionsabläufe oder Threshold-Signatur-Koordinationsprotokolle. Protokolldesigner, die auf EIP-8141 aufbauen, sollten adversarielle Mempool-Bedingungen in ihre Liveness-Annahmen einbeziehen, ebenso wie DeFi-Protokolle wie Aave das Liquidationslatenzrisiko als Funktion der Netzwerküberlastung und nicht als Konstante behandeln.

Der Benchmark stuft Grenzen über 300.000 Gas unter dem aktuellen Schutzdesign bei 100 scheiternden Transaktionen pro Sekunde als nicht tragfähig ein. Das Erreichen der 500.000-Gas-Grenze — die die schwersten SPHINCS+-Varianten abdecken würde — erforderte stärkeres Rate-Limiting auf der Transaktionspropagationsebene, stakewissenschaftlichen Spam-Filter oder eine niedrigere angenommene Basisflutrate. Jedes davon bedeutet zusätzliche Protokollkomplexität und clientübergreifende Koordination, die über den aktuellen EIP-8141-Entwurf hinausgehen.

Entwurfsstatus und offene Fragen

EIP-8141 befindet sich weiterhin im Draft-Status, und die Benchmark-Ergebnisse fließen direkt in die laufende Parameterdiskussion ein, statt sie abzuschließen. Nach dem EIP-Prozess durchlaufen Entwürfe im Draft-Stadium noch Review und Last Call, bevor sie den Final-Status erreichen, wodurch Parameter wie MAX_VERIFY_GAS auf Grundlage genau solcher Forschungsbeiträge revidierbar bleiben. Client-Entwickler und EIP-Autoren müssen die Kosten der ehrlichen Aufnahme bei einer 300.000-Gas-Grenze gegen die kryptografischen Anwendungsfälle abwägen, die höhere Budgets erfordern, und entscheiden, ob der Blockverarbeitungs-Prioritätsschutz als eigenständige Minderung ausreicht oder ob zusätzliche Spam-Resistenz-Mechanismen in den Kernentwurf gehören.

Der Aufnahmewert von 12 % auf der langsamsten Maschine dürfte ein Brennpunkt dieser Diskussion sein: Ein Protokoll, das unter mäßiger Flut weniger als eine von acht ehrlichen Transaktionen aufnimmt, bietet deutlich schwächere Liveness-Garantien als der aktuelle Mempool — selbst wenn die Block-Finalität selbst unbeeinflusst bleibt. Der Forumsthread im Ethereum Research Forum und Netherminds offener Pull Request sind die beiden dokumentierten Orte, an denen diese Bewertung weiter vorangetrieben wird.