Die Ethereum Foundation legt den Fokus stärker auf Sicherheit statt Geschwindigkeit – strikte 128-Bit-Regel für 2026 festgelegt

Das zkEVM-Ökosystem hat ein Jahr lang einen Sprint in Sachen Latenz hingelegt. Die Beweiszeit für einen Ethereum-Block ist von 16 Minuten auf 16 Sekunden gesunken, die Kosten sind um das 45-fache gefallen, und teilnehmende zkVMs beweisen nun 99 % der Mainnet-Blöcke in weniger als 10 Sekunden auf Zielhardware.

Die Ethereum Foundation (EF) erklärte am 18. Dezember den Sieg: Echtzeit-Beweise funktionieren. Die Leistungsengpässe sind beseitigt. Jetzt beginnt die eigentliche Arbeit, denn Geschwindigkeit ohne Solidität ist eine Haftung, kein Vorteil, und die Mathematik hinter vielen STARK-basierten zkEVMs ist seit Monaten stillschweigend gebrochen.

Im Juli setzte die EF ein offizielles Ziel für „Echtzeit-Beweise“, das Latenz, Hardware, Energie, Offenheit und Sicherheit bündelte: Mindestens 99 % der Mainnet-Blöcke innerhalb von 10 Sekunden beweisen, auf Hardware, die etwa 100.000 $ kostet und weniger als 10 Kilowatt verbraucht, mit vollständig quelloffenem Code, 128-Bit-Sicherheit und mit Beweisgrößen von maximal 300 Kilobyte.

Der Beitrag vom 18. Dezember behauptet, dass das Ökosystem das Leistungsziel erreicht hat, gemessen auf der EthProofs-Benchmarking-Seite.

Echtzeit ist hier relativ zur 12-Sekunden-Slotzeit und etwa 1,5 Sekunden für die Blockverbreitung definiert. Der Standard ist im Wesentlichen: „Beweise sind schnell genug fertig, damit Validatoren sie überprüfen können, ohne die Liveness zu gefährden.“

Die EF schwenkt nun von Durchsatz zu Solidität, und der Schwenk ist deutlich. Viele STARK-basierte zkEVMs haben sich auf unbewiesene mathematische Vermutungen verlassen, um die beworbenen Sicherheitsniveaus zu erreichen.

In den letzten Monaten wurden einige dieser Vermutungen, insbesondere die „Proximity Gap“-Annahmen, die in Hash-basierten SNARK- und STARK-Niedriggrad-Tests verwendet werden, mathematisch gebrochen, wodurch die effektive Bit-Sicherheit der darauf basierenden Parametersätze gesunken ist.

Die EF sagt, dass das einzige akzeptable Endziel für den L1-Einsatz „nachweisbare Sicherheit“ ist, nicht „Sicherheit unter der Annahme, dass Vermutung X gilt“.

Sie setzen 128-Bit-Sicherheit als Ziel, was mit den gängigen Krypto-Standardisierungsgremien und der akademischen Literatur zu langlebigen Systemen sowie mit realen Rekordberechnungen übereinstimmt, die zeigen, dass 128 Bit für Angreifer realistisch unerreichbar sind.

Die Betonung der Solidität über Geschwindigkeit spiegelt einen qualitativen Unterschied wider.

Wenn jemand einen zkEVM-Beweis fälschen kann, kann er beliebige Token prägen oder den L1-Zustand umschreiben und das System zum Lügen bringen, nicht nur einen Vertrag leeren.

Das rechtfertigt, was die EF als „nicht verhandelbare“ Sicherheitsmarge für jeden L1-zkEVM bezeichnet.

Drei-Meilenstein-Roadmap

Der Beitrag legt eine klare Roadmap mit drei festen Haltepunkten dar. Erstens, bis Ende Februar 2026, integriert jedes zkEVM-Team im Rennen sein Beweissystem und seine Schaltkreise in „soundcalc“, ein von der EF gepflegtes Tool, das Sicherheitsabschätzungen auf Basis aktueller kryptanalytischer Grenzen und der Parameter des Schemas berechnet.

Die Geschichte hier ist „gemeinsames Maß“. Anstatt dass jedes Team seine eigene Bit-Sicherheit mit individuellen Annahmen angibt, wird soundcalc zum kanonischen Rechner und kann aktualisiert werden, wenn neue Angriffe auftauchen.

Zweitens, „Glamsterdam“ bis Ende Mai 2026 verlangt mindestens 100-Bit-nachweisbare Sicherheit über soundcalc, finale Beweise von maximal 600 Kilobyte und eine kompakte öffentliche Erklärung der Rekursionsarchitektur jedes Teams mit einer Skizze, warum sie solide sein sollte.

Das nimmt stillschweigend die ursprüngliche 128-Bit-Anforderung für die frühe Bereitstellung zurück und behandelt 100 Bit als Zwischenziel.

Drittens, „H-star“ bis Ende 2026 ist die volle Hürde: 128-Bit-nachweisbare Sicherheit durch soundcalc, Beweise von maximal 300 Kilobyte sowie ein formales Sicherheitsargument für die Rekursionstopologie. Hier geht es weniger um Engineering und mehr um formale Methoden und kryptografische Beweise.

Technische Hebel

Die EF verweist auf mehrere konkrete Werkzeuge, die das 128-Bit- und Sub-300-Kilobyte-Ziel realisierbar machen sollen. Sie heben WHIR hervor, einen neuen Reed-Solomon-Proximity-Test, der auch als multilineares Polynom-Commitment-Schema dient.

WHIR bietet transparente, post-quantensichere Sicherheit und erzeugt Beweise, die kleiner sind und deren Verifikation schneller ist als die älterer FRI-ähnlicher Schemata bei gleichem Sicherheitsniveau.

Benchmarks bei 128-Bit-Sicherheit zeigen, dass die Beweise etwa 1,95-mal kleiner sind und die Verifikation mehrere Male schneller als bei Basis-Konstruktionen.

Sie verweisen auf „JaggedPCS“, eine Reihe von Techniken, um übermäßiges Padding beim Kodieren von Spuren als Polynome zu vermeiden, wodurch Prover unnötige Arbeit vermeiden und dennoch prägnante Commitments erzeugen können.

Sie erwähnen „Grinding“, also das brute-force-Durchsuchen von Protokollzufälligkeit, um günstigere oder kleinere Beweise zu finden, während die Soliditätsgrenzen eingehalten werden, und „gut strukturierte Rekursionstopologie“, also geschichtete Schemata, bei denen viele kleinere Beweise zu einem einzigen finalen Beweis aggregiert werden, dessen Solidität sorgfältig begründet ist.

Exotische Polynom-Mathematik und Rekursionstricks werden eingesetzt, um die Beweise nach der Erhöhung der Sicherheit auf 128 Bit wieder zu verkleinern.

Unabhängige Arbeiten wie Whirlaway verwenden WHIR, um multilineare STARKs mit verbesserter Effizienz zu bauen, und experimentellere Polynom-Commitment-Konstruktionen werden aus Data-Availability-Schemata entwickelt.

Die Mathematik entwickelt sich schnell, entfernt sich aber auch von Annahmen, die vor sechs Monaten noch sicher erschienen.

Was sich ändert und die offenen Fragen

Wenn Beweise konsequent innerhalb von 10 Sekunden fertig sind und unter 300 Kilobyte bleiben, kann Ethereum das Gas-Limit erhöhen, ohne dass Validatoren jede Transaktion erneut ausführen müssen.

Validatoren würden stattdessen einen kleinen Beweis verifizieren, wodurch die Blockkapazität wachsen kann, während Home-Staking realistisch bleibt. Deshalb hat der frühere Echtzeit-Post der EF Latenz und Stromverbrauch explizit an „Home-Proving“-Budgets wie 10 Kilowatt und Sub-100.000-$-Rigs geknüpft.

Die Kombination aus großen Sicherheitsmargen und kleinen Beweisen macht einen „L1-zkEVM“ zu einer glaubwürdigen Settlement-Schicht. Wenn diese Beweise sowohl schnell als auch nachweislich 128-Bit-sicher sind, können L2s und zk-Rollups die gleiche Technik über Precompiles wiederverwenden, und die Unterscheidung zwischen „Rollup“ und „L1-Ausführung“ wird mehr zu einer Konfigurationsfrage als zu einer starren Grenze.

Echtzeit-Beweise sind derzeit ein Off-Chain-Benchmark, keine On-Chain-Realität. Die Latenz- und Kostenzahlen stammen von den kuratierten Hardware-Setups und Workloads von EthProofs.

Es gibt immer noch eine Lücke zwischen dem und Tausenden unabhängiger Validatoren, die diese Prover tatsächlich zu Hause betreiben. Die Sicherheitslage ist im Wandel. Der ganze Grund, warum soundcalc existiert, ist, dass STARK- und Hash-basierte SNARK-Sicherheitsparameter sich ständig ändern, wenn Vermutungen widerlegt werden.

Jüngste Ergebnisse haben die Grenze zwischen „definitiv sicher“, „vermutlich sicher“ und „definitiv unsicher“ bei den Parameterbereichen neu gezogen, was bedeutet, dass die heutigen „100-Bit“-Einstellungen erneut überarbeitet werden könnten, wenn neue Angriffe auftauchen.

Es ist nicht klar, ob alle großen zkEVM-Teams tatsächlich bis Mai 2026 100-Bit-nachweisbare Sicherheit und bis Dezember 2026 128-Bit erreichen werden, während sie unter den Beweisgrößen-Grenzen bleiben, oder ob einige stillschweigend geringere Margen akzeptieren, sich auf schwerwiegendere Annahmen stützen oder die Verifikation länger Off-Chain verschieben.

Der schwierigste Teil ist vielleicht nicht Mathematik oder GPUs, sondern die Formalisierung und Prüfung der vollständigen Rekursionsarchitekturen.

Die EF gibt zu, dass verschiedene zkEVMs oft viele Schaltkreise mit erheblichem „Glue Code“ dazwischen zusammensetzen und dass die Dokumentation und der Nachweis der Solidität für diese maßgeschneiderten Stacks wesentlich ist.

Das eröffnet eine lange Nachlaufzeit für Projekte wie Verified-zkEVM und formale Verifikations-Frameworks, die noch am Anfang stehen und im Ökosystem unterschiedlich weit entwickelt sind.

Vor einem Jahr war die Frage, ob zkEVMs schnell genug beweisen können. Diese Frage ist beantwortet.
Die neue Frage ist, ob sie solide genug beweisen können, auf einem Sicherheitsniveau, das nicht von Vermutungen abhängt, die morgen brechen könnten, mit Beweisen, die klein genug sind, um über das P2P-Netzwerk von Ethereum zu propagieren, und mit Rekursionsarchitekturen, die formal genug verifiziert sind, um Hunderte von Milliarden Dollar abzusichern.

Der Leistungssprint ist vorbei. Das Sicherheitsrennen hat gerade erst begonnen.

Der Beitrag Ethereum Foundation refocuses to security over speed – sets strict 128-bit rule for 2026 erschien zuerst auf CryptoSlate.