Das zkEVM-Ökosystem verbrachte ein Jahr damit, die Latenz zu verbessern. Die Prüfzeit für einen Ethereum-Block sank von 16 Minuten auf 16 Sekunden, die Kosten sanken um das 45-fache und teilnehmende zkVMs beweisen nun 99 % der Mainnet-Blöcke in weniger als 10 Sekunden auf der Zielhardware.
Der Ethereum-Stiftung (EF) erklärte am 18. Dezember den Sieg: Echtzeittests funktionieren. Die Leistungsengpässe werden behoben. Jetzt beginnt die eigentliche Arbeit, denn Geschwindigkeit ohne Solidität ist eine Belastung, kein Vorteil, und die Mathematik vieler STARK-basierter zkEVMs scheitert seit Monaten stillschweigend.
Im Juli legte die EF ein formelles Ziel für „Echtzeitprüfungen“ fest, die Latenz, Hardware, Energie, Offenheit und Sicherheit bündelten: Mindestens 99 % der Mainnet-Blöcke innerhalb von 10 Sekunden nachweisen, auf Hardware, die etwa 100.000 US-Dollar kostet und innerhalb von 10 Kilowatt läuft, mit vollständig Open-Source-Code, bei 128-Bit-Sicherheit und mit Beweisgrößen von 300 Kilobyte oder weniger.
Der Beitrag vom 18. Dezember behauptet, das Ökosystem habe das Leistungsziel erreicht, gemessen auf der EthProofs-Benchmarking-Site.
Die Echtzeit wird hier relativ zur Slot-Zeit von 12 Sekunden und etwa 1,5 Sekunden für die Blockausbreitung definiert. Der Standard lautet im Wesentlichen: „Beweise sind schnell genug fertig, damit Validatoren sie verifizieren können, ohne die Lebendigkeit zu beeinträchtigen.“
Der EF schwenkt jetzt von Durchsatz auf Solidität, und der Drehpunkt ist stumpf. Viele STARK-basierte zkEVMs haben sich auf unbewiesene mathematische Vermutungen gestützt, um die angekündigten Sicherheitsstufen zu erreichen.
In den letzten Monaten wurden einige dieser Vermutungen, insbesondere die „Proximity Gap“-Annahmen, die in Hash-basierten SNARK- und STARK-Low-Grade-Tests verwendet werden, mathematisch widerlegt, wodurch die effektive Bitsicherheit der von ihnen abhängigen Parametersätze zunichte gemacht wurde.
Laut EF ist das einzig akzeptable Endspiel für die L1-Nutzung „nachweisbare Sicherheit“ und nicht „Sicherheit unter der Annahme, dass Vermutung X gilt“.
Sie legen 128-Bit-Sicherheit als Ziel fest und orientieren sich dabei an gängigen Krypto-Standardisierungsgremien und wissenschaftlicher Literatur zu langlebigen Systemen sowie an realen Rekordberechnungen, die zeigen, dass 128 Bit für Angreifer realistischerweise unerreichbar sind.
Die Betonung der Solidität gegenüber der Geschwindigkeit spiegelt einen qualitativen Unterschied wider.
Wenn jemand einen zkEVM-Beweis fälschen kann, kann er beliebige Token prägen oder den L1-Status neu schreiben und das System zum Lügen bringen, anstatt nur einen Vertrag zu entleeren.
Dies rechtfertigt das, was die EF als „nicht verhandelbare“ Sicherheitsmarge für jedes L1-zkEVM bezeichnet.
Roadmap mit drei Meilensteinen
Der Beitrag stellt eine klare Roadmap mit drei harten Stopps vor. Erstens verbindet jedes zkEVM-Team im Rennen bis Ende Februar 2026 sein Beweissystem und seine Schaltkreise mit „soundcalc“, einem von EF gepflegten Tool, das Sicherheitsschätzungen auf der Grundlage aktueller kryptoanalytischer Grenzen und der Parameter des Schemas berechnet.
Die Geschichte hier ist „gemeinsamer Herrscher“. Anstatt dass jedes Team seine eigene Bit-Sicherheit mit maßgeschneiderten Annahmen angibt, wird Soundcalc zum kanonischen Rechner und kann aktualisiert werden, wenn neue Angriffe auftauchen.
Zweitens verlangt „Glamsterdam“ bis Ende Mai 2026 mindestens nachweisbare 100-Bit-Sicherheit über Soundcalc, endgültige Beweise bei oder unter 600 Kilobyte und eine kompakte öffentliche Erklärung der Rekursionsarchitektur jedes Teams mit einer Skizze, warum sie solide sein sollte.
Dadurch wird die ursprüngliche 128-Bit-Anforderung für die frühe Bereitstellung stillschweigend zurückgenommen und 100 Bit als Zwischenziel behandelt.
Drittens ist „H-Star“ bis Ende 2026 die volle Messlatte: nachweisbare 128-Bit-Sicherheit durch Soundcalc, Beweise bei oder unter 300 Kilobyte sowie ein formales Sicherheitsargument für die Rekursionstopologie. Hier geht es weniger um Technik als vielmehr um formale Methoden und kryptografische Beweise.
Technische Hebel
Die EF weist auf mehrere konkrete Tools hin, die das 128-Bit-Ziel mit weniger als 300 Kilobyte realisierbar machen sollen. Sie heben WHIR hervor, einen neuen Reed-Solomon-Proximity-Test, der gleichzeitig als multilineares Polynom-Commitment-Schema dient.
WHIR bietet transparente Post-Quantum-Sicherheit und produziert Beweise, die kleiner und schneller verifiziert sind als die älterer FRI-Schemata bei gleichem Sicherheitsniveau.
Benchmarks mit 128-Bit-Sicherheit zeigen, dass die Beweise etwa 1,95-mal kleiner und die Verifizierung um ein Vielfaches schneller sind als bei Basiskonstruktionen.
Sie verweisen auf „JaggedPCS“, eine Reihe von Techniken zur Vermeidung übermäßiger Auffüllung bei der Codierung von Spuren als Polynome, die es Prüfern ermöglichen, verschwendete Arbeit zu vermeiden und gleichzeitig prägnante Verpflichtungen zu erstellen.
Sie erwähnen „Grinding“, eine Brute-Force-Suche über Protokollzufälligkeiten, um billigere oder kleinere Beweise zu finden und dabei innerhalb der Grenzen der Korrektheit zu bleiben, und „gut strukturierte Rekursionstopologie“, d. h. mehrschichtige Schemata, bei denen viele kleinere Beweise mit sorgfältig argumentierter Korrektheit zu einem einzigen endgültigen Beweis zusammengefasst werden.
Exotische Polynommathematik und Rekursionstricks werden verwendet, um die Beweise wieder zu verkleinern, nachdem die Sicherheit auf 128 Bit erhöht wurde.
Unabhängige Arbeiten wie Whirlaway nutzen WHIR, um multilineare STARKs mit verbesserter Effizienz zu erstellen, und experimentellere Polynom-Commitment-Konstruktionen werden auf der Grundlage von Datenverfügbarkeitsschemata erstellt.
Die Rechnung schreitet schnell voran, aber sie entfernt sich auch von Annahmen, die vor sechs Monaten noch sicher aussahen.
Was ändert sich und die offenen Fragen
Wenn die Proofs stets innerhalb von 10 Sekunden fertig sind und unter 300 Kilobyte bleiben, Ethereum kann das Gaslimit erhöhen, ohne Validatoren zu zwingen, jede Transaktion erneut auszuführen.
Validatoren würden stattdessen einen kleinen Beweis verifizieren und so die Blockkapazität erhöhen, während das Home-Staking realistisch bleibt. Aus diesem Grund knüpfte der frühere Echtzeit-Beitrag des EF Latenz und Leistung explizit an „Home-Proving“-Budgets wie 10 Kilowatt und Anlagen unter 100.000 US-Dollar.
Die Kombination aus großen Sicherheitsmargen und kleinen Nachweisen macht ein „L1 zkEVM“ zu einer glaubwürdigen Abwicklungsschicht. Wenn diese Beweise sowohl schnell als auch nachweislich 128-Bit-sicher sind, können L2s und ZK-Rollups dieselbe Maschinerie über Vorkompilierungen wiederverwenden, und die Unterscheidung zwischen „Rollup“ und „L1-Ausführung“ wird eher zu einer Konfigurationsauswahl als zu einer starren Grenze.
Echtzeitprüfungen sind derzeit ein Off-Chain-Benchmark und keine On-Chain-Realität. Die Latenz- und Kostenzahlen stammen aus den kuratierten Hardware-Setups und Workloads von EthProofs.
Es besteht immer noch eine Lücke zwischen diesem und den Tausenden unabhängigen Validatoren, die diese Prüfer tatsächlich zu Hause betreiben. Die Sicherheitsgeschichte ist im Wandel. Der Grund für die Existenz von Soundcalc liegt darin, dass sich die Sicherheitsparameter von STARK und Hash-basierten SNARK ständig ändern, wenn Vermutungen widerlegt werden.
Jüngste Ergebnisse haben die Grenze zwischen „definitiv sicheren“, „mutmaßlich sicheren“ und „definitiv unsicheren“ Parameterregimen neu gezogen, was bedeutet, dass die heutigen „100-Bit“-Einstellungen möglicherweise erneut überarbeitet werden, wenn neue Angriffe auftauchen.
Es ist nicht klar, ob alle wichtigen zkEVM Teams werden bis Mai 2026 tatsächlich die nachweisbare 100-Bit-Sicherheit und bis Dezember 2026 die 128-Bit-Sicherheit erreichen, während sie unter den Proof-Size-Obergrenzen bleiben, oder ob einige stillschweigend geringere Margen akzeptieren, sich auf strengere Annahmen verlassen oder die Verifizierung länger außerhalb der Kette verschieben.
Der schwierigste Teil ist möglicherweise nicht Mathematik oder GPUs, sondern die Formalisierung und Prüfung der vollständigen Rekursionsarchitekturen.
Die EF räumt ein, dass verschiedene zkEVMs häufig viele Schaltkreise mit erheblichem „Klebercode“ zwischen ihnen bilden, und dass die Dokumentation und der Nachweis der Solidität dieser maßgeschneiderten Stacks von wesentlicher Bedeutung ist.
Das eröffnet einen langen Weg an Arbeit für Projekte wie Verified-zkEVM und formale Verifizierungs-Frameworks, die noch in den Kinderschuhen stecken und in den einzelnen Ökosystemen uneinheitlich sind.
Vor einem Jahr stellte sich die Frage, ob sich zkEVMs als schnell genug erweisen könnten. 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 sich über das P2P-Netzwerk von Ethereum zu verbreiten, und mit Rekursionsarchitekturen, die formal genug verifiziert sind, um Hunderte von Milliarden Dollar zu verankern.
Der Leistungssprint ist vorbei. Der Sicherheitswettlauf hat gerade erst begonnen.
