Countdown 2029: Ethereum startet mit Hegotá den Marathon zur Quantenresistenz

Autor: KarenZ, Foresight News

Quantencomputer haben die Blockchain noch nicht erreicht, doch die Ethereum Foundation hat bereits ein Datum im Kalender markiert: Dezember 2029.

Es ist der technische Zeitplan, den sich das Protokollteam der Ethereum Foundation selbst gesetzt hat: sich auf ein Szenario vorzubereiten, in dem die Quantenbedrohung früher eintreten könnte, und die Quantenresistenz des Ethereum-Layer-1-Netzwerks abzuschließen, bevor das Risiko wirklich akut wird.

Das geplante Hegotá wird Ethereum zwar nicht direkt in eine vollständig quantenresistente Blockchain verwandeln, aber es wird darüber entscheiden, ob die nachfolgenden Pläne fristgerecht vorankommen.

EF setzt dem „Q-Day“ eine Frist bis 2029

„Q-Day“ bezeichnet üblicherweise einen hypothetischen Zeitpunkt: Wenn Quantencomputer mit realer Angriffsfähigkeit auftauchen, geraten bestehende Public-Key-Kryptosysteme unter substanzielle Bedrohung.

Wann er eintritt, kann niemand genau vorhersagen. Die Ethereum Foundation gibt auch offen zu, dass die meisten glaubwürdigen Prognosen davon ausgehen, dass der Q-Day nach 2030 liegt, möglicherweise sogar deutlich später, und dass es auch möglich ist, dass er noch lange nicht eintritt.

Das Protokollteam der Ethereum Foundation geht von einer eher konservativen technischen Annahme aus: Ethereum Layer 1 sollte sich auf ein Szenario vorbereiten, in dem der Q-Day frühestens 2030 eintreten könnte.

Zu diesem Zweck hat das Protokollteam ein Ziel formuliert: Bis Dezember 2029 sollen die drei Komponenten Ausführung, Konsens und Daten von Ethereum Layer 1 vollständig quantenresistent sein.

Dieses Ziel ist nicht in Stein gemeißelt. Das Protokollteam plant, im Januar 2027 unter Einbeziehung externer Expertenmeinungen die Entwicklung des Quantencomputings neu zu bewerten. Bis dahin wird die Frist 2029 als ein Arbeitsziel behandelt, von dem nicht leicht abgewichen werden soll.

Die Umstellung auf Quantenresistenz erfordert mehrere Jahre Vorlauf, weil Ethereum nicht nur eine einzige kryptografische Technik verwendet und die Migration nicht durch den Austausch eines Signaturalgorithmus abgeschlossen werden kann. Wie Nutzerkonten nachweisen, dass Transaktionen autorisiert sind, wie Validierer am Konsens teilnehmen und wie Daten verifiziert werden – all das betrifft unterschiedliche kryptografische Strukturen. Jede Änderung muss Spezifikationsentwurf, Client-Implementierung, Sicherheitsprüfung, Testnetz-Testphase und Mainnet-Koordination durchlaufen; es ist unmöglich, erst dann zu handeln, wenn die Bedrohung bereits eingetreten ist.

Hegotá ist kein „Quantenresistenz-Upgrade“, aber die erste Prüfung des gesamten Plans

Nach der derzeit vom Protokollteam der Ethereum Foundation veröffentlichten Basis-Roadmap soll das Glamsterdam-Netzwerk-Upgrade im Dezember 2026 im Mainnet starten; die vollständige Quantenresistenz ist für die fünfte Hard Fork L* nach Glamsterdam vorgesehen, mit einem Zieltermin im Dezember 2029. Von Glamsterdam bis L* bleiben nur drei Jahre. Wenn Hegotá, I*, J*, K* und L* nacheinander abgeschlossen werden sollen, liegen zwischen den einzelnen Upgrades im Durchschnitt nur etwa 7,2 Monate.

Das ist ein ziemlich ehrgeiziger Zeitplan. Derzeit hat die Ethereum Foundation für Hegotá, I*, J* und K* keine festen Mainnet-Termine veröffentlicht. Fest steht, dass die Client-Teams voraussichtlich frühestens Ende 2026 mit der Implementierung von Hegotá beginnen werden und Forschung, Spezifikation und Tests mehrerer Folgeversionen parallel vorangetrieben werden müssen.

Nach dem aktuellen Fahrplan sind die wichtigsten Phasen wie folgt gegliedert:

• Hegotá: steht am Anfang dieses Fahrplans. Die offizielle Positionierung ist sehr klar: Hegotá selbst ist kein Quantenresistenz-Upgrade, wird aber darüber entscheiden, ob die nachfolgenden Quantenresistenz-Upgrades rechtzeitig umgesetzt werden können.
• I*: Einführung eines Registers für quantenresistente öffentliche Schlüssel, um die protokollarische Grundlage für die Registrierung und Nutzung quantenresistenter öffentlicher Schlüssel durch Konten zu schaffen; gleichzeitig ist die Entkopplung des Konsenses derzeit die führende Kernkandidaten-Richtung dieser Version, und umfangreichere Arbeiten an Zustandsstruktur-Design und Migration sollen voraussichtlich mit I* beginnen.
• J*: Aufbau eines „minimal funktionsfähigen quantenresistenten“ Layer 1, also MV-PQ. Zu den Schlüsselkomponenten gehören ein quantenresistenter Heartbeat-Mechanismus auf der Konsensebene, post-quanten LeanDA-Sampling auf der Datenebene und post-quanten LeanSPHINCS-Transaktionen auf der Ausführungsebene.
• K*: Einführung von Execution Proofs (obligatorischen Ausführungsnachweisen) gemäß der aktuellen Basis-Reihenfolge. Die Entwicklungsrichtung für Validierer besteht dann darin, kompakte Ausführungsnachweise zu verifizieren, statt dass jeder Validierer vollständige Blöcke erneut ausführt.
• L*: Ergänzung der für vollständige Quantenresistenz des Konsenses erforderlichen quantenresistenten Attestierungsnachrichten, also Post-Quantum-Attestations, gemäß der aktuellen Basis-Reihenfolge, und Erreichen des vollständigen Quantenresistenz-Ziels für Ausführungs-, Konsens- und Datenebene im Dezember 2029.

Allerdings ist die Reihenfolge der Aufgaben von K* und L* noch nicht endgültig festgelegt. Das Protokollteam prüft eine Tauschvariante: die Post-Quantum-Attestations von L* auf K* vorzuziehen, damit die vollständige Quantenresistenz früher erreicht wird, und gleichzeitig die Execution Proofs von K* auf L* zu verschieben. Bei dieser Variante würden sich die konkreten Zuständigkeiten von K* und L* sowie der Upgrade-Rhythmus entsprechend ändern. Die derzeit präziseste Aussage lautet daher: Dezember 2026 ist das aktuelle Mainnet-Ziel für Glamsterdam, Dezember 2029 ist im Basis-Fahrplan das Ziel für L* und die vollständige Quantenresistenz; die interne Reihenfolge von K* und L* kann sich noch ändern.

Forscher, Client-Entwickler, Sicherheitsprüfer und Testteams müssen sowohl Hegotá abschließen als auch frühzeitig Spezifikationen und Prototypen für I*, J*, K* und L* vorbereiten. Wenn Hegotá zu viele sich gegenseitig beeinflussende Funktionen aufnimmt, könnte es nicht nur den eigenen Start verzögern, sondern auch Teams binden, die für die nachfolgende Quantenresistenz-Arbeit benötigt werden.

Daher hat das Protokollteam der Ethereum Foundation die Hegotá-Kandidatenvorschläge in die Stufen S (2), A (15), B (8), C (7), DFI (28) und TBD (2) eingeteilt – insgesamt 62 Kandidatenvorschläge. Stufe S bedeutet: muss geliefert werden; Stufe A: hohe Priorität, Lieferung erwartet; Stufe B: zusätzliche Bedingungen wie Spezifikation, Prototyp oder Verantwortlichen-Bestätigung erforderlich; Stufe C: liegt derzeit unter der Aufnahmeschwelle; DFI: für dieses Upgrade nicht empfohlen; TBD: noch offen.

Die zwei S-Stufen von Hegotá: FOCIL und Frames

In der vom Protokollteam veröffentlichten Hegotá-Einstufung haben es nur zwei EIPs in die S-Stufe geschafft: EIP-7805 FOCIL auf der Konsensebene und EIP-8141 Frame Transactions auf der Ausführungsebene.

Sie behandeln jeweils zwei Schlüsselfragen im Lebenszyklus einer Transaktion: ob eine berechtigte Transaktion in einen Block aufgenommen werden kann und auf welche Weise ein Konto Transaktionen verifizieren und ausführen kann.

FOCIL (EIP-7805) steht für „Fork-choice enforced Inclusion Lists“ (durch Fork-Choice-Regeln erzwungene Inklusionslisten). Ziel ist es, die Inklusionsgarantie für Transaktionen bei Ethereum zu verbessern.

Derzeit dominieren spezialisierte Block Builder die Blockerstellung. Diese Arbeitsteilung trägt zur Effizienz der Blockerstellung bei, aber wenn die Blockproduktion langfristig auf wenige Builder konzentriert ist, könnten diese auch eine starke Fähigkeit zur Transaktionsfilterung erlangen. FOCIL fügt daher außerhalb des normalen Blockerstellungsprozesses eine zusätzliche Inklusionsbeschränkung durch Validierer hinzu.

Nach dem FOCIL-Design wird für jeden Slot eine Gruppe von Validierern als „Inclusion List Committee“ (IL-Committee) ausgewählt. Die Committee-Mitglieder erstellen und verbreiten auf Basis der von ihnen beobachteten ausstehenden Transaktionen jeweils Inklusionslisten. Der Block Builder des nächsten Slots sammelt diese Listen und nimmt beim Erstellen des Blocks diejenigen Transaktionen auf, die die Ausführungsbedingungen erfüllen. Die Validierer, die den neuen Block attestieren, speichern ebenfalls die von ihnen rechtzeitig empfangenen Inklusionslisten und prüfen, ob der Block die entsprechenden Anforderungen erfüllt.

Wenn ein Block ohne triftigen Grund Transaktionen aus den von Validierern gespeicherten Listen auslässt, stimmen die Attestierer nicht für diesen Block. Ein solcher Block kann zwar auf Ausführungsebene weiterhin gültig sein, erhält aber nicht die für den Eintritt in die kanonische Kette erforderliche Konsensunterstützung. Genau darin liegt der Sinn von FOCIL: Es geht nicht darum, dass Committee-Mitglieder Blöcke direkt verändern, sondern darum, die Auswahl der Block Builder über das Abstimmungsverhalten der Validierer zu beschränken.

Das begleitende EIP-8369 beschreibt genauer, welche Transaktionen für die erzwungene Inklusionsgarantie von FOCIL geeignet sind. Bei gewöhnlichen Transaktionen lassen sich Auslassungsgründe relativ leicht verifizieren; Frame Transactions erlauben programmierbare Verifikation, deren Beurteilungskosten höher sind, weshalb der lesbare Zustandsbereich und das Verifikationsbudget zusätzlich eingeschränkt werden müssen.

Allgemein gesagt: FOCIL nimmt den Block Buildern nicht die Arbeit weg, sondern fügt ihnen eine Konsensregel hinzu: Du kannst weiterhin den Großteil der Transaktionen in einem Block anordnen, darfst aber berechtigte Transaktionen aus den Committee-Listen nicht ohne triftigen Grund dauerhaft ignorieren.

Frame Transactions (EIP-8141) behandeln das Problem auf Kontoebene. Sie sollen Transaktionsverifikation, Transaktionsausführung und Gaszahlung auf Protokollebene stärker programmierbar machen und damit die Grundlage für native Kontoabstraktion schaffen. Vitalik ist einer der Co-Autoren von EIP-8141.

Derzeit verlassen sich die meisten gewöhnlichen Ethereum-Konten auf feste Typen von Private-Key-Signaturen. Frames soll es Konten ermöglichen, flexiblere Verifikationslogik zu verwenden, etwa neue Signaturschemata einzusetzen, mehrere Autorisierungsbedingungen zu kombinieren oder andere Konten die Transaktionsgebühren zahlen zu lassen. Es kann auch Signaturaggregation unterstützen und erlaubt künftig die Einführung neuer Signaturschemata, ohne für jedes Schema eine eigene Hard Fork durchführen zu müssen.

Frames selbst ist jedoch kein vollständiges quantenresistentes Signaturschema und wird bestehende Schlüssel nach dem Start von Hegotá auch nicht sofort obsolet machen. Es bietet „Krypto-Agilität“: Falls künftig ein Signaturschema gewechselt werden muss, können Konten die Migration über programmierbare Verifikation vollziehen, statt dauerhaft an ein einziges Schlüsselsystem gebunden zu sein.

Frames benötigt außerdem zwei A-Stufen-Vorschläge als zentrale Begleitung. EIP-8250 Keyed Nonces erlaubt demselben Absender die Nutzung voneinander unabhängiger Nonce-Kanäle, sodass verschiedene Transaktionen sich nicht gegenseitig blockieren, weil sie sich eine strikte Reihenfolge teilen; EIP-8272 ermöglicht Transaktionen die Nutzung eines für Validierer überprüfbaren jüngeren On-Chain-Zustands, sodass auch entsprechende private Transaktionen die Inklusionsgarantie von FOCIL erhalten können.

FOCIL und Frames sind also keine zwei voneinander unabhängigen Funktionen. Ersteres verändert, welche berechtigten Transaktionen ein Block enthalten muss, letzteres verändert die Verifikationsstruktur der Transaktion selbst. Ob beide sicher zusammenwirken können, ist eine der wichtigsten Testaufgaben von Hegotá.

Welche EIPs sind außerhalb der S-Stufe noch beachtenswert?

Die S-Stufen-Vorschläge definieren die Hauptlinie von Hegotá, aber mehrere A-Stufen-Vorschläge beeinflussen ebenfalls die künftige Kontosicherheit, die Quantenresistenz-Migration, Execution Proofs und die Ressourcenbepreisung von Ethereum.

Zunächst EIP-8365. Es soll den schrittweisen Ausstieg aus einem Teil der BLS-Withdrawal-Credentials einleiten, da diese weiterhin auf kryptografischen Verfahren beruhen, die bei einem ausreichend starken Quantenangriff ihre Sicherheit verlieren könnten. Das Protokollteam ist der Ansicht, dass diese Migration frühzeitig begonnen werden kann, ohne auf die endgültige Festlegung des vollständigen quantenresistenten Konsensdesigns warten zu müssen.

Im Bereich Kontosicherheit gelten EIP-7906, EIP-8298 und EIP-8151 als Erweiterungskombination für Frames.

EIP-7906 führt einen Mechanismus für Transaction Assertions ein, mit dem eine Transaktion vor der endgültigen Einreichung prüft, ob ein bestimmtes Ergebnis eingetreten ist. Dieser Mechanismus soll Verluste durch bösartige Verträge, die Wallet-Vermögen abziehen, sowie durch bestimmte MEV-Verhaltensweisen verringern. Der konkrete Lesebereich dieses Vorschlags wird jedoch noch erforscht und eingegrenzt; das aktuelle Design darf daher nicht als bereits festgeschriebene finale Spezifikation dargestellt werden.

EIP-8298 erlaubt Konten die Wiederverwendung bestehenden Vertragscodes, sodass delegierte Konten weiter zu Smart-Contract-Konten mit vollständigem Code werden können. EIP-8151 beschränkt, dass Adressen mit bestehendem Kontocode weiterhin auf die traditionelle ecRecover-Authentifizierung angewiesen sind.

Erst durch die Kombination dieser beiden Vorschläge können Konten wirklich aufhören, den alten secp256k1-Schlüssel als höchste Kontrollberechtigung zu verwenden, und es entsteht ein vollständiger Pfad für den künftigen Ausstieg aus dem alten Schlüsselsystem.

EIP-8025 (optionale Execution Proofs) steht im Zusammenhang mit der künftigen zkEVM-Roadmap. Es soll die für optionale Execution Proofs erforderlichen Änderungen in eine einheitliche Ausführungsspezifikation aufnehmen, um das Problem zu verringern, dass verschiedene zkVM-Projekte langfristig voneinander abgespaltene Versionen pflegen.

EIP-8279 (Byte-Ebene der Block Access Lists) und EIP-8131 (einheitliche Transaktionsinhaltsebene) bilden eine Gruppe von Vorschlägen zur Ausführungssicherheit. Beide legen Mindestpreisstandards für Block Access Lists bzw. Transaktionsinhalte fest, um Angreifer daran zu hindern, unterbewertete Inhalte zur Erzeugung extremer Ressourcenlasten zu nutzen. Sie adressieren zunächst die Worst-Case-Kosten der Blockverarbeitung, statt direkt eine Erhöhung der Netzkapazität anzukündigen. Ob der dadurch entstehende Sicherheitsspielraum für Kapazitätserweiterungen genutzt wird, muss später separat entschieden werden.

EIP-3298 plant die vollständige Entfernung des Gas-Refund-Mechanismus, um Sonderfälle bei Messung, Implementierung und Tests zu reduzieren; EIP-5920 (PAY Opcode) erlaubt Verträgen den Transfer von ETH ohne Ausführung des Empfängervertragscodes und trennt damit „Wert übertragen“ und „Vertrag aufrufen“ klar voneinander.

Gleichzeitig verbleiben einige viel beachtete Vorschläge weiterhin auf Stufe B.

Beispielsweise möchte EIP-8198 (Quick Slots) die Slot-Zeit verkürzen, aber das Protokollteam verlangt zunächst eine Spezifikation, die die Änderungen am Kernprotokoll abdeckt, einen vollständigen Prototyp, eine Bewertung der Downstream-Auswirkungen sowie den Nachweis, dass das nachfolgende Entkopplungs-Konsensdesign nicht gestört wird. Der Grund: Die Slot-Zeit beeinflusst nicht nur die Blockgeschwindigkeit, sondern auch Netzwerkpropagation, Konsensentscheidungen und die Zeitannahmen von Anwendungen.

Darüber hinaus werden EIP-8368 und EIP-8372 als „TBD“ (offen) geführt. Beide Vorschläge betreffen Gas-Limits und die Bepreisung von Zustandsressourcen; das Protokollteam will die Mainnet-Daten nach dem Start von Glamsterdam im Dezember 2026 abwarten, bevor es über eine Neukalibrierung entscheidet.

Wie viele EIPs Hegotá letztlich aufnimmt, ist nicht der einzige Maßstab für den Erfolg dieses Upgrades.

Wichtiger ist, ob es FOCIL, Frames und deren zentrale Begleitkomponenten liefern kann, ohne Sicherheit und Testqualität zu opfern, und gleichzeitig genügend Forschungs- und Entwicklungsressourcen für das Public-Key-Register und die Konsensentkopplung von I*, die minimal funktionsfähige Quantenresistenz von J* sowie die Execution Proofs und den vollständigen quantenresistenten Konsens von K* und L* übrig lässt.

Nach den aktuellen Zielen wird Glamsterdam im Dezember 2026 diesen dichten Upgrade-Zyklus starten, und L* wird im Basis-Fahrplan im Dezember 2029 das Ziel erreichen. Jedes einzelne Upgrade dazwischen darf nicht nur die eigene Funktion erfüllen, sondern muss auch sicherstellen, dass die nächste Phase weiter vorankommen kann.

Ob die Quantenbedrohung vor 2030 Realität wird, kann niemand mit Sicherheit beantworten. Doch die derzeitige Entscheidung von Ethereum ist bereits klar: zuerst eine Frist für das Risiko setzen und dann jeden Vorschlag durch Spezifikation, Prototyp und Tests beweisen lassen, dass er die Bedingungen für den Mainnet-Einsatz erfüllt.

Artikelreferenzen:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446