Mit EIP-8450 liegt der erste konkrete Protokollvorschlag auf dem Tisch, mit dem Ethereum seine Validatoren auf Quantencomputer vorbereiten will. Die Idee: Jeder Validator hinterlegt schon heute einen zusätzlichen, quantensicheren Schlüssel im Beacon-State, der zunächst ungenutzt bleibt. Erst ein späterer Fork soll die eigentlichen Validator-Aufgaben auf diese Schlüssel umstellen. Seit dem 28. Oktober 2026 liegt zudem eine überarbeitete Fassung als Pull Request vor, die den Entwurf deutlich vereinfacht.
Wichtig vorweg: EIP-8450 ist ein Entwurf (Draft), einem konkreten Netzwerk-Upgrade ist er noch nicht zugeordnet. Für Staker, Pool-Betreiber und Client-Entwickler lohnt der Blick trotzdem, weil der Vorschlag zeigt, wie die Migration praktisch ablaufen könnte.
Key Takeaways
- EIP-8450 („Post-Quantum Validator Key Registry“) wurde am 15. Oktober 2026 erstellt; zu den Autoren gehört Justin Drake von der Ethereum Foundation.
- Validatoren registrieren einen hashbasierten leanXMSS-Schlüssel, der „schlafend“ bleibt: In diesem Fork signiert er noch keine Aufgaben, BLS bleibt im Einsatz.
- Die Registrierung soll messbar machen, wie viel Stake bereit für den Umstieg ist, und einen vertrauenswürdigen Rückfallanker schaffen, falls BLS früher bricht als erwartet.
- Die Überarbeitung vom 28. Oktober streicht den Weg über die Withdrawal-Adresse, nimmt Builder auf und begrenzt Schlüsselwechsel auf einmal pro 256 Epochen.
- Ein Termin steht nicht fest. Die Ethereum Foundation peilt volle Quantenresistenz der L1 bis Dezember 2029 an.
Warum Ethereum neue Validator-Schlüssel braucht
Heute ist laut EIP-Text jede Signatur auf der Konsensebene eine BLS12-381-Signatur: Attestierungen, Block-Vorschläge, RANDAO-Beiträge, Sync-Committee-Nachrichten, freiwillige Exits und mehr. BLS beruht auf dem diskreten Logarithmus in paarungsfreundlichen Gruppen, und genau dieses Problem löst Shors Algorithmus auf einem ausreichend großen Quantencomputer. Ein solcher „kryptografisch relevanter Quantencomputer“ (CRQC) könnte aus einem öffentlichen Schlüssel den geheimen Schlüssel berechnen, und alle öffentlichen Validator-Schlüssel stehen im Beacon-State.
Einen solchen Rechner gibt es heute nicht, und wann oder ob er kommt, ist offen. Das Problem für ein dezentrales Netzwerk ist die Vorlaufzeit: Neue Schlüssel zu erzeugen erfordert neue Werkzeuge und bei Staking-Pools die Abstimmung zwischen Node-Betreibern und Eigentümern des Stakes. Über die Debatte um Quantenrisiken für Ethereum und Bitcoin haben wir bereits im Zusammenhang mit Justin Drakes Einschätzung zu ECDSA und Quantencomputern berichtet.
Was EIP-8450 konkret vorsieht
EIP-8450 teilt den Abschied von BLS in zwei Forks. Im ersten Fork, den dieser Vorschlag beschreibt, registriert jeder Validator einen hashbasierten Schlüssel, gebunden an seinen bestehenden Validator-Index. Verwendet wird leanXMSS, eine zweistufige Variante des zustandsbehafteten Signaturverfahrens XMSS (RFC 8391): Ein oberer Baum mit 216 Einmalschlüsseln zertifiziert jeweils einen unteren Baum mit weiteren 216 Einmalschlüsseln, zusammen also gut 4,29 Milliarden (232) Blattindizes. Gehasht wird mit Keccak-256.
Jede Registrierung enthält einen Besitznachweis (Proof of Possession), also eine Signatur mit dem neuen Schlüssel. So können Clients die Verifikationslogik testen, bevor irgendeine Aufgabe davon abhängt, und niemand kann den veröffentlichten Schlüssel eines anderen kopieren. Die Autoren nennen vier Vorteile der Zwei-Fork-Strategie:
- Vorbereitung: Validatoren erzeugen und registrieren Schlüssel mit im Mainnet getesteten Werkzeugen, während BLS weiter gilt.
- Bereitschaftssignal: Der Anteil des registrierten Stakes ist im State ablesbar, der Umstieg kann an einer beobachteten Schwelle ausgerichtet werden.
- Rückfallanker: Schlüssel, die registriert werden, solange BLS sicher ist, gelten als authentisch. Bricht BLS vor dem Umstieg, kann die Chain auf sie wechseln.
- Frühe Implementierung: Client-Teams arbeiten mit Hashfunktion, Verifizierer und Datenstrukturen, bevor sie kritisch werden.
Für Netz und State nennt der Entwurf klare Grenzen: maximal acht Registrierungen pro Block, rund 20 KiB zusätzliche Blockgröße. Eine Million Validatoren bräuchte bei voller Auslastung 125.000 Blöcke, also etwa 17 Tage. Der Sicherheitsanspruch: 127 Bit klassische Sicherheit, formal in Lean 4 bewiesen, und als Ziel 64 Bit Quantensicherheit (NIST-Level 1), was ausdrücklich keine bewiesene Schranke ist.
Die Überarbeitung von EIP-8450 im Detail
Die auf eips.ethereum.org veröffentlichte Fassung sieht zwei Wege für die Registrierung vor: über den BLS-Signaturschlüssel des Validators (nur Registrieren, kein Ersetzen) oder über die Withdrawal-Adresse mit einer neuen Anfrage auf der Ausführungsebene (Registrieren und Ersetzen). Der am 28. Oktober eröffnete Pull Request #12592 ändert das grundlegend:
- Der Weg über die Withdrawal-Adresse entfällt. Nur noch der BLS-Signaturschlüssel autorisiert Registrierungen und kann registrierte Schlüssel ersetzen, höchstens einmal pro 256 Epochen (rund 27 Stunden). Ein Feld mit der Epoche der letzten Änderung schützt vor Replay-Angriffen.
- Laut neuem Text braucht der Vorschlag damit keine Änderung an der Ausführungsebene mehr; die Registrierung ist eine reine Konsens-Operation.
- Neben Validatoren sollen auch Builder (aus EIP-7732) einen leanXMSS-Schlüssel registrieren, weil auch ihre Gebote mit BLS signiert werden.
- Validatoren hinterlegen zusätzlich die Wurzel eines hashbasierten VRF-Baums für überprüfbare Zufallswerte.
- Der Entwurf beschreibt die Kryptografie nur noch über eine Schnittstelle; leanXMSS mit 32-Byte-Schlüsseln und 2.404-Byte-Signaturen verweist auf eine externe Implementierung.
Der Pull Request ist noch offen (Stand 29. Oktober), ein begleitender Entwurf im consensus-specs-Repository ebenfalls. Bis zur Aufnahme kann sich also noch einiges ändern.
Wo EIP-8450 im Fahrplan steht
Laut den im September veröffentlichten Protokoll-Prioritäten der Ethereum Foundation soll die Ethereum-L1 bis Dezember 2029 auf allen drei Ebenen quantenresistent sein: Ausführung, Konsens und Daten. Das Register für post-quantensichere Schlüssel ist dort für den Fork „I*“ eingeplant, einen „minimal tragfähigen“ Post-Quanten-Meilenstein sieht der Plan im darauffolgenden Fork „J*“. Die Foundation selbst nennt den Zeitplan „ziemlich aggressiv“ und will den Fortschritt bei Quantencomputern im Januar 2027 mit externen Fachleuten neu bewerten. Für die Planung geht sie bewusst davon aus, dass ein CRQC schon 2030 existieren könnte, räumt aber ein, dass die meisten glaubwürdigen Schätzungen später liegen.
Was Staker und Betreiber jetzt wissen sollten
Akuter Handlungsbedarf besteht nicht: EIP-8450 ist ein Entwurf, und selbst nach der Aktivierung würden bestehende BLS-Schlüssel weiter alle Aufgaben signieren. Wer nicht registriert, ist laut EIP von diesem Fork nicht betroffen. Interessant ist die Logik für später: Der Text empfiehlt, früh zu registrieren, weil eine Registrierung nur so vertrauenswürdig ist wie die BLS-Signatur, die sie autorisiert. Zudem ist ein registrierter Schlüssel kein Beweis, dass ein Validator am Stichtag korrekt arbeitet. Der Umstieg soll deshalb mit Abstand oberhalb der Zwei-Drittel-Schwelle geplant werden, die für Finalität nötig ist.
Für Betreiber wird die Schlüsselverwaltung anspruchsvoller. Bei zustandsbehafteten Verfahren wie XMSS darf jeder Blattindex nur eine Nachricht signieren; wer zwei verschiedene Nachrichten mit demselben Index signiert, ermöglicht Fälschungen. Der Seed soll nicht aus dem BLS-Schlüssel abgeleitet werden, und der Verlust des Signer-Zustands birgt Risiken. Wie verwundbar Kryptografie-Annahmen werden können, haben wir auch beim „Bunker Mode“ für Bitcoin und Ethereum beleuchtet.
Fazit
EIP-8450 ist ein nüchterner, technischer Schritt: Ethereum will quantensichere Schlüssel einsammeln, lange bevor sie gebraucht werden, und so den späteren Umstieg planbar machen. Die Überarbeitung vom 28. Oktober macht den Entwurf schlanker, verlagert die Kontrolle aber vollständig auf den BLS-Schlüssel des Operators. Ob und wann der Vorschlag kommt, hängt von Reviews, Client-Implementierungen und dem Fork-Fahrplan ab. Für Staker heißt das vorerst: beobachten, nicht handeln.
