Der Ethereum-Forscher ladislaus.eth veröffentlichte letzte Woche eine Anleitung, in der er erklärte, wie Ethereum plant, von der erneuten Ausführung jeder Transaktion zur Verifizierung von Zero-Knowledge-Beweisen überzugehen.
Der Beitrag bezeichnet dies als „stille, aber fundamentale Transformation", und diese Einordnung ist zutreffend. Nicht weil die Arbeit geheim ist, sondern weil ihre Auswirkungen sich durch die gesamte Ethereum-Architektur ziehen, auf eine Weise, die erst offensichtlich wird, wenn sich die Teile verbinden.
Dies ist nicht Ethereum, das „ZK als Feature hinzufügt". Ethereum entwickelt einen alternativen Validierungspfad, bei dem einige Validatoren Blöcke bestätigen können, indem sie kompakte Ausführungsbeweise verifizieren, anstatt jede Transaktion erneut auszuführen.
Wenn es funktioniert, verschiebt sich die Rolle von Ethereums Layer-1 von „Abwicklung und Datenverfügbarkeit für Rollups" hin zu „Hochdurchsatz-Ausführung, deren Verifizierung günstig genug für Heimvalidatoren bleibt".
EIP-8025, mit dem Titel „Optional Execution Proofs", wurde in Entwurfsform veröffentlicht und spezifiziert die Mechanismen.
Ausführungsbeweise werden über das Peer-to-Peer-Netzwerk der Konsensschicht über ein dediziertes Thema geteilt. Validatoren können in zwei neuen Modi arbeiten: beweiserstellend oder zustandslose Validierung.
Der Vorschlag gibt ausdrücklich an, dass er „keinen Hard-Fork erfordert" und abwärtskompatibel bleibt, während Nodes weiterhin wie heute erneut ausführen können.
Das zkEVM-Team der Ethereum Foundation veröffentlichte am 26. Januar eine konkrete Roadmap für 2026, die sechs Unterthemen umreißt: Standardisierung von Ausführungszeugen und Gastprogrammen, Standardisierung der zkVM-Gast-API, Konsensschicht-Integration, Prover-Infrastruktur, Benchmarking und Metriken sowie Sicherheit mit formaler Verifizierung.
Der erste L1-zkEVM-Breakout-Call ist für den 11. Februar um 15:00 UTC geplant.
Die End-to-End-Pipeline funktioniert folgendermaßen: Ein Ausführungsschicht-Client erstellt einen ExecutionWitness, ein eigenständiges Paket, das alle Daten enthält, die zur Validierung eines Blocks benötigt werden, ohne den vollständigen Zustand zu halten.
Ein standardisiertes Gastprogramm verarbeitet diesen Zeugen und validiert den Zustandsübergang. Eine zkVM führt dieses Programm aus, und ein Prover erzeugt einen Beweis korrekter Ausführung. Der Konsensschicht-Client verifiziert dann diesen Beweis, anstatt den Ausführungsschicht-Client zur erneuten Ausführung aufzurufen.
Die Schlüsselabhängigkeit ist ePBS (Enshrined Proposer-Builder Separation), geplant für den kommenden Glamsterdam-Hard-Fork. Ohne ePBS beträgt das Beweisfenster etwa ein bis zwei Sekunden, was für Echtzeit-Beweiserstellung zu knapp ist. Mit ePBS, das Block-Pipelining ermöglicht, erweitert sich das Fenster auf sechs bis neun Sekunden.
Das Diagramm zeigt, dass ePBS Ethereums Beweisfenster von 1-2 Sekunden auf 6-9 Sekunden erweitert und damit Echtzeit-Beweiserstellung im Vergleich zur aktuellen durchschnittlichen Beweiszeit von sieben Sekunden mit 12 GPUs machbar macht.
Der Dezentralisierungs-Trade-off
Wenn optionale Beweise und Zeugenformate reifen, können mehr Heimvalidatoren teilnehmen, ohne den vollständigen Ausführungsschicht-Zustand aufrechtzuerhalten.
Die Erhöhung von Gas-Limits wird politisch und wirtschaftlich einfacher, da die Validierungskosten von der Ausführungskomplexität entkoppelt werden. Verifizierungsarbeit skaliert nicht mehr linear mit der On-Chain-Aktivität.
Allerdings birgt die Beweiserstellung ihr eigenes Zentralisierungsrisiko. Ein Ethereum Research-Beitrag vom 2. Februar berichtet, dass die Beweiserstellung für einen vollständigen Ethereum-Block derzeit etwa 12 GPUs erfordert und durchschnittlich 7 Sekunden dauert.
Der Autor weist auf Bedenken bezüglich Zentralisierung hin und bemerkt, dass Grenzen schwer vorherzusagen bleiben. Wenn die Beweiserstellung GPU-lastig bleibt und sich in Builder- oder Prover-Netzwerken konzentriert, könnte Ethereum „jeder führt erneut aus" gegen „wenige beweisen, viele verifizieren" eintauschen.
Das Design zielt darauf ab, dies durch die Einführung von Client-Diversität auf der Beweisebene zu adressieren. Die Arbeitshypothese von EIP-8025 ist eine Drei-von-fünf-Schwelle, was bedeutet, dass ein Bestätiger die Ausführung eines Blocks als gültig akzeptiert, sobald er drei von fünf unabhängigen Beweisen von verschiedenen Ausführungsschicht-Client-Implementierungen verifiziert hat.
Dies bewahrt Client-Diversität auf Protokollebene, löst aber nicht das Hardware-Zugriffsproblem.
Die ehrlichste Einordnung ist, dass Ethereum das Dezentralisierungs-Schlachtfeld verschiebt. Die heutige Einschränkung lautet „kannst du es dir leisten, einen Ausführungsschicht-Client zu betreiben?" Die morgige könnte lauten „hast du Zugang zu GPU-Clustern oder Prover-Netzwerken?"
Die Wette ist, dass Beweisverifizierung einfacher zu kommerzialisieren ist als Zustandsspeicherung und erneute Ausführung, aber die Hardware-Frage bleibt offen.
Ethereums Roadmap, zuletzt aktualisiert am 5. Februar, listet „Statelessness" als Hauptupgrade-Thema auf: Blöcke verifizieren, ohne großen Zustand zu speichern.
Optionale Ausführungsbeweise und Zeugen sind der konkrete Mechanismus, der zustandslose Validierung praktikabel macht. Ein zustandsloser Node benötigt nur einen Konsens-Client und verifiziert Beweise während der Payload-Verarbeitung.
Die Synchronisierung reduziert sich auf das Herunterladen von Beweisen für aktuelle Blöcke seit dem letzten Finalisierungs-Checkpoint.
Dies ist wichtig für Gas-Limits. Heute macht jede Erhöhung des Gas-Limits das Betreiben eines Nodes schwieriger. Wenn Validatoren Beweise verifizieren können, anstatt erneut auszuführen, skalieren die Verifizierungskosten nicht mehr mit dem Gas-Limit. Ausführungskomplexität und Validierungskosten entkoppeln sich.
Der Benchmarking- und Repricing-Workstream in der 2026-Roadmap zielt ausdrücklich auf Metriken ab, die verbrauchtes Gas auf Beweiszyklen und Beweiszeit abbilden.
Wenn sich diese Metriken stabilisieren, erhält Ethereum einen Hebel, den es zuvor nicht hatte: die Fähigkeit, den Durchsatz zu erhöhen, ohne die Kosten für das Betreiben eines Validators proportional zu steigern.
Ein kürzlicher Beitrag von Vitalik Buterin argumentiert, dass sich Layer-2-Blockchains über Skalierung hinaus differenzieren sollten, und verknüpft explizit den Wert eines „nativen Rollup-Precompiles" mit der Notwendigkeit verankerter zkEVM-Beweise, die Ethereum bereits zur Skalierung von Layer-1 benötigt.
Die Logik ist einfach: Wenn alle Validatoren Ausführungsbeweise verifizieren, können dieselben Beweise auch von einem EXECUTE-Precompile für native Rollups verwendet werden. Layer-1-Beweisinfrastruktur wird zu gemeinsamer Infrastruktur.
Dies verschiebt das Layer-2-Wertversprechen. Wenn Layer-1 auf hohen Durchsatz skalieren kann, während die Verifizierungskosten niedrig bleiben, können sich Rollups nicht mit „Ethereum kann die Last nicht bewältigen" rechtfertigen.
Die neuen Differenzierungsachsen sind spezialisierte virtuelle Maschinen, extrem niedrige Latenz, Preconfirmations und Kompositionsmodelle wie Rollups, die auf schnelle Beweisdesigns setzen.
Das Szenario, in dem Layer-2s relevant bleiben, ist eines, in dem die Rollen zwischen Spezialisierung und Interoperabilität aufgeteilt sind.
Layer-1 wird zur Hochdurchsatz-, Niedrigverifizierungskosten-Ausführungs- und Abwicklungsschicht. Layer-2s werden zu Feature-Laboren, Latenzoptimierern und Kompositions-Brücken.
Dies erfordert jedoch, dass Layer-2-Teams neue Wertversprechen artikulieren und Ethereum die Proof-Verification-Roadmap liefert.
Es gibt drei potenzielle Szenarien für die Zukunft.
Das erste Szenario besteht darin, dass Proof-First-Validierung üblich wird. Wenn optionale Beweise und Zeugenformate reifen und Client-Implementierungen sich um standardisierte Schnittstellen stabilisieren, können mehr Heimvalidatoren teilnehmen, ohne den vollständigen Ausführungsschicht-Zustand zu betreiben.
Gas-Limits steigen, weil die Validierungskosten nicht mehr mit der Ausführungskomplexität übereinstimmen. Dieser Pfad hängt davon ab, dass der ExecutionWitness- und Gastprogramm-Standardisierungs-Workstream auf portable Formate konvergiert.
Szenario zwei ist, wo Prover-Zentralisierung zum neuen Engpass wird. Wenn die Beweiserstellung GPU-lastig bleibt und sich in Builder- oder Prover-Netzwerken konzentriert, verschiebt Ethereum das Dezentralisierungs-Schlachtfeld von der Hardware der Validatoren zur Prover-Marktstruktur.
Das Protokoll funktioniert weiterhin, da ein ehrlicher Prover irgendwo die Chain am Leben hält, aber das Sicherheitsmodell ändert sich.
Das dritte Szenario ist, dass Layer-1-Beweisverifizierung zu gemeinsamer Infrastruktur wird. Wenn die Konsensschicht-Integration sich verhärtet und ePBS das erweiterte Beweisfenster liefert, neigt sich das Wertversprechen von Layer-2s zu spezialisierten VMs, extrem niedriger Latenz und neuen Kompositionsmodellen anstatt nur „Ethereum skalieren".
Dieser Pfad erfordert, dass ePBS planmäßig für Glamsterdam ausgeliefert wird.
| Szenario | Was wahr sein muss (technische Vorbedingungen) | Was bricht / Hauptrisiko | Was sich verbessert (Dezentralisierung, Gas-Limits, Sync-Zeit) | L1-Rollenergebnis (Ausführungsdurchsatz vs. Verifizierungskosten) | L2-Implikation (neue Differenzierungsachse) | „Worauf zu achten ist"-Signal |
|---|---|---|---|---|---|---|
| Proof-First-Validierung wird üblich | Execution Witness + Gastprogramm-Standards konvergieren; zkVM/Gast-API standardisiert sich; CL-Beweisverifizierungspfad ist stabil; Beweise verbreiten sich zuverlässig über P2P; akzeptable Multi-Beweis-Schwellensemantik (z.B. 3-von-5) | Beweisverfügbarkeit / Latenz wird zu neuer Abhängigkeit; Verifizierungsfehler werden konsensempfindlich wenn/falls darauf vertraut wird; Diskrepanz zwischen Clients/Provern | Heimvalidatoren können ohne EL-Zustand bestätigen; Sync-Zeit sinkt (Beweise seit Finalisierungs-Checkpoint); Gas-Limit-Erhöhungen werden einfacher, weil Verifizierungskosten von Ausführungskomplexität entkoppelt werden | L1 verschiebt sich zu Ausführung mit höherem Durchsatz mit konstant-ischen Verifizierungskosten für viele Validatoren | L2s müssen sich über „L1 kann nicht skalieren" hinaus rechtfertigen: spezialisierte VMs, app-spezifische Ausführung, benutzerdefinierte Gebührenmodelle, Datenschutz usw. | Spec/Testvektor-Härtung; Zeugen/Gast-Portabilität über Clients; stabiler Beweis-Gossip + Fehlerbehandlung; Benchmark-Kurven (Gas → Beweiszyklen/Zeit) |
| Prover-Zentralisierung wird zum Engpass | Beweiserstellung bleibt GPU-lastig; Beweismarkt konsolidiert sich (Builder / Prover-Netzwerke); begrenzte „Garagen-Skalen"-Beweiserstellung; Lebendigkeit hängt von kleiner Gruppe ausgefeilter Prover ab | „Wenige beweisen, viele verifizieren" konzentriert Macht; Zensur / MEV-Dynamiken intensivieren sich; Prover-Ausfälle erzeugen Lebendigkeits-/Finalitätsstress; geografisches / regulatorisches Konzentrationsrisiko | Validatoren können immer noch günstig verifizieren, aber dezentralisierte Verschiebungen: einfacheres Bestätigen, schwierigeres Beweisen; etwas Gas-Limit-Spielraum, aber durch Prover-Ökonomie eingeschränkt | L1 wird ausführungsskalierbar in der Theorie, aber praktisch begrenzt durch Prover-Kapazität und Marktstruktur | L2s könnten sich auf based / pre-confirmed Designs, alternative Beweissysteme oder Latenzgarantien stützen – potenziell Abhängigkeit von privilegierten Akteuren erhöhend | Beweiskosten-Trends (Hardware-Anforderungen, Zeit pro Block); Prover-Diversitätsmetriken; Anreize für verteilte Beweiserstellung; Fehlermodus-Übungen (was passiert, wenn Beweise fehlen?) |
| L1-Beweisverifizierung wird zu gemeinsamer Infrastruktur | CL-Integration „härtet sich"; Beweise werden weit produziert / konsumiert; ePBS liefert und bietet ein funktionierendes Beweisfenster; Schnittstellen erlauben Wiederverwendung (z.B. EXECUTE-artiges Precompile / native Rollup-Hooks) | Cross-Domain-Kopplungsrisiko: wenn L1-Beweisinfrastruktur belastet wird, könnten auch Rollup-Verifizierungspfade leiden; Komplexität / Angriffsfläche expandiert | Gemeinsame Infrastruktur reduziert duplizierte Beweisanstrengung; verbessert Interoperabilität; vorhersehbarere Verifizierungskosten; klarerer Pfad zu höherem L1-Durchsatz ohne Validatoren herauszupreisen | L1 entwickelt sich zu einer beweisverifizierten Ausführungs- + Abwicklungsschicht, die auch Rollups nativ verifizieren kann | L2s schwenken zu Latenz (Preconfs), spezialisierten Ausführungsumgebungen und komponierbaren Modellen (z.B. schnelle Beweis- / synchron-ische Designs) statt nur „Skalierung" | ePBS / Glamsterdam-Fortschritt; End-to-End-Pipeline-Demos (Zeuge → Beweis → CL-Verifizierung); Benchmarks + mögliche Gas-Neubepreissung; Einführung minimaler lebensfähiger Beweisverteilungssemantik und Überwachung |
Die Reife der Consensus-Specs-Integration wird signalisieren, ob „optionale Beweise" von größtenteils TODOs zu gehärteten Testvektoren übergehen.
Die Standardisierung von ExecutionWitness und Gastprogramm ist der Schlüssel für zustandslose Validierungsportabilität über Clients hinweg. Benchmarks, die verbrauchtes Gas auf Beweiszyklen und Beweiszeit abbilden, werden bestimmen, ob Gas-Neubepreissung für ZK-Freundlichkeit machbar ist.
ePBS- und Glamsterdam-Fortschritt wird anzeigen, ob das Sechs-bis-neun-Sekunden-Beweisfenster Realität wird. Breakout-Call-Ergebnisse werden enthüllen, ob die Arbeitsgruppen auf Schnittstellen und minimale lebensfähige Beweisverteilungssemantik konvergieren.
Ethereum wechselt nicht bald zu beweisbasierter Validierung. EIP-8025 stellt ausdrücklich fest, dass es „Upgrades noch nicht darauf basieren kann", und die optionale Formulierung ist beabsichtigt. Folglich ist dies ein testbarer Pfad und keine unmittelbare Aktivierung.
Dennoch bedeutet die Tatsache, dass die Ethereum Foundation eine 2026-Implementierungs-Roadmap ausgeliefert, einen Breakout-Call mit Projekteignern geplant und einen EIP mit konkreten Peer-to-Peer-Gossip-Mechanismen entworfen hat, dass diese Arbeit von Forschungsplausibilität zu einem Lieferprogramm übergegangen ist.
Die Transformation ist still, weil sie keine dramatischen Token-Ökonomie-Änderungen oder benutzerseitigen Features beinhaltet. Aber sie ist fundamental, weil sie die Beziehung zwischen Ausführungskomplexität und Validierungskosten neu schreibt.
Wenn Ethereum die beiden entkoppeln kann, wird Layer-1 nicht länger der Engpass sein, der alles Interessante auf Layer-2 zwingt.
Und wenn Layer-1-Beweisverifizierung zu gemeinsamer Infrastruktur wird, muss das gesamte Layer-2-Ökosystem eine schwierigere Frage beantworten: Was baut ihr, das Layer-1 nicht kann?
Der Beitrag Ethereum möchte, dass Heimvalidatoren Beweise verifizieren, aber eine 12-GPU-Realität wirft eine neue Bedrohung auf erschien zuerst auf CryptoSlate.

