Architektur und Implementierungsstrategie eines Post-Quantum Public Key Registry für Ethereum

8. September 2026 Kryptowährungen

Architektur und Implementierungsstrategie eines Post-Quantum Public Key Registry für Ethereum

Ein künftiger Quantencomputer, der Shors Algorithmus ausführen kann, würde die derzeit genutzten BLS12-381-Signaturen der Validatoren kompromittieren. Um einen plötzlichen Migrationszwang zu vermeiden, sieht das Konzept einen zweistufigen Übergang vor: Zunächst wird ein Public-Key-Registry eingeführt, in dem Validatoren ihre post-quantum (PQ) Schlüssel registrieren, bevor die Signatur-Aktivierung im Konsens-Layer erfolgt. Diese Trennung verhindert operative Engpässe und Netzüberlastungen.

Warum ein Post-Quantum Registry unverzichtbar ist

  • Shors Algorithmus macht elliptische Kurven (BLS12-381) unsicher.
  • Eine rechtzeitige, zweistufige Trennung von Schlüsselregistrierung und Signaturaktivierung reduziert das Risiko von Netzwerk-Overload bei einem abrupten Hard-Fork.
  • Der Registrierungs-Fork kann Jahre vor dem eigentlichen Signatur-Hard-Fork aktiviert werden, wodurch ausreichend Zeit für State-Aufbau und Sicherheits-Monitoring bleibt.

Kern der Kryptografie – eXtended Merkle Signature Scheme (XMSS)

  • Hash-basierte Signaturen (XMSS) erzeugen Signaturen von ca. 3,1 KiB Größe.
  • Im Vergleich zu SPHINCS+ (Dutzende KiB) ist XMSS bandwidth-freundlicher und lässt sich dank deterministischer Slot-Signaturen im Proof-of-Stake sicher verwalten.
  • Public-Key-Größe: 52 Byte (32 Byte Merkle-Root + 20 Byte Public Parameter). Für 1 Million Validatoren bedeutet das nur ca. 52 MiB im State.
  • Statefulness von XMSS birgt ein signifikantes Slashing-Risiko: Wird ein One-Time-Signature-Leaf (OTS-Leaf) zweimal verwendet – etwa durch Backup-Wiederherstellung oder Node-Crash – verliert das System seine Fälschungssicherheit und kann zum Slashing führen.

Funktionsweise von XMSS (Kurzüberblick)

  • Ein Merkle-Baum mit 2^32 Blättern (≈1632 Jahre bei 12-Sekunden-Slots) dient als Quelle für One-Time-Signature-Schlüssel.
  • Jeder Slot nutzt das nächste ungenutzte Blatt, liefert ein OTS-Signature, den Merkle-Auth-Path (1 024 Byte) und 28 Byte Zufallswert.
  • Der Validator signiert exakt einmal pro Slot, wodurch die stateful Natur kontrollierbar bleibt.

Skalierbarkeit durch leanVM-Aggregation

Ohne Aggregation würden rund eine Million aktive Validatoren ihre unkomprimierten XMSS-Signaturen (je ca. 3,1 KiB) pro 12-Sekunden-Slot ins P2P-Gossip-Netzwerk senden – ein Datenvolumen von über 3 GiB pro Slot, das die Slot-Budgets von Ethereum sprengen würde.

  • leanVM ist eine spezialisierte zkVM (KoalaBear-Körper, Grad 5, 123 Bits Sicherheit), die XMSS-Signaturen rekursiv mittels Spartan- und WHIR-Polynomial-Commitments aggregiert.
  • Benchmarks (2026, High-End-Consumer-Hardware Apple M4 Max):
    • Beweis-Durchsatz: ca. 1 000 XMSS-Signaturen pro Sekunde
    • Komprimierte Endbeweisgröße: 128 – 350 KiB (abhängig vom PCS-Rate)
    • Latenz rekursive 2-zu-1-Beweise: 3 Sekunden
    • Bandbreitenbedarf inkl. Signer-Bitfield: < 500 KiB pro Slot
  • Durch rekursive 2-zu-1-Aggregation wird die Flut von 3 GiB/Slot auf ein handhabbares <500 KiB/Slot reduziert.

Registrierungsmechanik und Durchsatzkapazität

  • Pro Block dürfen maximal 16 Registrierungen verarbeitet werden (MAXPQREGISTRATIONSPERBLOCK = 16).
  • Bei 7 200 Slots pro Stunde (12-Sekunden-Slots) entspricht das 115 200 Registrierungen pro Tag.
  • Für ein Validator-Set von 1 Million wird theoretisch ein Minimum von 8,7 Tagen (≈9 Tage) benötigt, wenn jeder Block voll ausgelastet ist.
  • In der Praxis dauert die vollständige Migration mehrere Monate, weil Fehlversuche, Netzwerk-Latenz und operative Vorgänge berücksichtigt werden müssen.
  • Die Begrenzung dämpft das State-Wachstum, stabilisiert die Block-Verifikation und verhindert Denial-of-Service-Spitzen zum Zeitpunkt des Registrierungs-Forks.

Gegenmaßnahmen und Risiken

  • Zustandsbehaftung (Statefulness) von XMSS: Doppeltes Signieren eines OTS-Leaves führt zu Slashing und Verlust der Fälschungssicherheit.
  • Kryptanalytische Unsicherheit bei Poseidon-Hashfunktionen: Poseidon1/2 sind optimiert für ZK-Schaltkreise, besitzen jedoch eine kürzere Analyse-Historie als SHA-256 oder SHAKE256. Mehrfach-Hash-Agilität muss eingeplant werden.
  • Ressourcenanforderungen an Prover (Beweiser): Die Verifikation bleibt leichtgewichtig, aber die rekursive pqSNARK-Generierung erfordert dedizierte Aggregations-Knoten mit substanzieller Rechenleistung, was zu einer Zentralisierung des Aggregations-Ökosystems führen könnte.

FAQ

  • Warum wird XMSS statt des zustandslosen SPHINCS+ (SLH-DSA) für Konsens-Validatoren bevorzugt? SPHINCS+ erzeugt Signaturen von mehreren Dutzend KiB, was das P2P-Gossip-Netzwerk überlasten würde. XMSS erzeugt kleinere Signaturen (~3,1 KiB) und lässt sich dank deterministischer Slot-Signaturen sicher nachverfolgen.
  • Wie lange dauert es, bis alle Validatoren im neuen Registry erfasst sind? Bei einem Cap von 16 Registrierungen pro Block (maximal 115 200 pro Tag) dauert die vollständige Migration von rund einer Million Validatoren theoretisch mindestens 9 Tage; in der Praxis mehrere Monate.
  • Müssen Validatoren für den Post-Quantum-Schlüssel neue Hardware anschaffen? Nein. Die einmalige Schlüsselgenerierung benötigt spürbare CPU-Zeit und wenige Megabyte Speicher, die laufende Verifikation und das Signieren bleiben ressourcenschonend.

Fazit

Der vorgestellte Post-Quantum Public Key Registry bietet eine sichere, skalierbare und operativ machbare Lösung, um Ethereum langfristig gegen die Bedrohung durch große Quantencomputer zu wappnen. Durch die Trennung von Schlüsselregistrierung und Signaturaktivierung wird das Risiko eines plötzlichen Netzwerk-Overloads minimiert. XMSS liefert kompakte, verifizierbare Signaturen, deren Statefulness zwar Risiken birgt, aber dank der strikten Slot-Signatur-Policy kontrollierbar bleibt. Die Kombination aus einer limitierten Registrierungsrate (16 Operationen/Block) und der leistungsfähigen leanVM-Aggregation reduziert den Bandbreitenbedarf von über 3 GiB pro Slot auf unter 500 KiB, was die Slot-Budgets von Ethereum einhält. Benchmarks aus 2026 belegen, dass die aggregierten Beweise mit einer Durchsatzrate von 1 000 XMSS-Signaturen pro Sekunde und einer Latenz von 3 Sekunden praktisch einsetzbar sind. Trotz offener Fragen zu Hash-Agilität, Prover-Zentralisierung und Schlüssel-Revocation stellt das Design einen klaren, quantifizierten Pfad dar, um die aktuelle BLS-Infrastruktur schrittweise zu ersetzen und die Sicherheit des Netzwerks bis 2029 und darüber hinaus zu gewährleisten.