• Ethereum diskutiert einen Architekturwechsel, bei dem Validatoren Blöcke nicht mehr durch vollständige Re-Ausführung aller Transaktionen prüfen müssen.
  • Im L1-zkEVM-2026-Fahrplan soll EIP-8025 „Optional Execution Proofs“ einführen, ein erster Workshop ist für den 11. Februar 2026 geplant.

Ethereum könnte bei der Block-Validierung einen fundamentalen Hebel ansetzen. Ladislaus.eth, Mitglied der Ethereum Foundation, skizziert eine Richtung, in der das Netzwerk langfristig weniger auf das traditionelle Prinzip „alles noch einmal ausführen“ setzt, sondern auf das Verifizieren von Zero-Knowledge-Proofs.

Vom Re-Execution-Modell zur Proof-Verifikation

Heute überprüfen Validatoren einen Block im Kern dadurch, dass sie den Zustand durch die enthaltenen Transaktionen selbst nachrechnen. Das ist robust, aber teuer in Infrastruktur, Komplexität und Wartung. Im angedachten Modell wird die Prüfung stärker kryptografisch: Statt jede Transaktion erneut zu exekutieren, würde ein Validator einen Beweis prüfen, der die korrekte Ausführung zusammenfasst.

Der Begriff, der dabei fällt, ist L1-zkEVM, also eine Zero-Knowledge-fähige Ausführungsumgebung direkt auf Layer 1. Das Ziel ist nicht unbedingt, jede Operation sofort „voll zk“ zu machen. Eher geht es um eine Migrationslogik, bei der Proofs Schritt für Schritt ein gleichwertiger Bestandteil der Sicherheitsarchitektur werden.

EIP-8025 und die Rolle der zkAttesters

Konkret nennt Ladislaus.eth EIP-8025, „Optional Execution Proofs“. Die Idee: Validatoren, in diesem Kontext auch als zkAttesters beschrieben, könnten Blöcke bestätigen, indem sie kryptografische Beweise verifizieren, ohne dafür einen vollständigen Execution-Client laufen zu lassen. „Optional“ ist dabei ein wichtiges Wort, weil es nahelegt, dass Proofs zunächst ergänzend eingeführt werden, nicht als harter Schnitt von heute auf morgen.

Der nächste praktische Schritt ist schon terminiert. Der erste L1-zkEVM-Workshop ist für den 11. Februar 2026 angesetzt. Dort dürfte es weniger um Marketing gehen und mehr um Details, etwa um Sicherheitsannahmen, Rollenverteilung zwischen Clients, und die Frage, wie sich so ein System sauber in Ethereums bestehende Konsens- und Monitoring-Strukturen einfügt.