Ich habe mich mit weiteren post-quantum Upgrade-Mechanismen beschäftigt, insbesondere mit solchen, die keinen Adresswechsel erfordern. EdDSA-Ketten, die RFC-8032 (Ed25519-Stil) folgen, haben einen eingebauten Vorteil. Ihr Signaturschlüssel ist kein rohes zufälliges Skalar, sondern wird deterministisch aus einem kurzen Seed durch Hashing abgeleitet. Das bedeutet, dass Sie beweisen können, dass Sie den Seed kennen (in einem post-quantum-sicheren ZK-Beweis) und einen neuen post-quantum Schlüssel an dieselbe Adresse binden können. Keine Gelder werden bewegt und keine neuen Kurvendaten werden on-chain benötigt. Selbst ruhende Konten können aufgerüstet werden, wenn der Seed existiert. Dies betrifft Ketten wie Sui, Solana, NEAR, Stellar, Aptos. Bitcoin/Ethereum haben dieses Invarianzstandard nicht standardmäßig, da viele ECDSA-Schlüssel von "einfach einen zufälligen Skalar wählen" stammen. Aber es gibt einen möglichen Weg für große Kohorten, die BIP-39 → BIP-32 mit gut definierten Pfaden verwenden. Sie können diese genaue Ableitung beweisen und einen post-quantum Schlüssel binden, ohne Gelder zu bewegen. Aber es ist wallet-spezifisch und kann komplex sein: - BIP-39’s PBKDF2-HMAC-SHA512 (2048 Runden) ist kostspielig in ZK - BIP-32 fügt HMAC-SHA512 und secp256k1 Mathematik innerhalb des Schaltkreises hinzu Dennoch kann es für gängige Pfade (z.B. Ethereum m/44’/60’/0’/0/x) machbar sein. Generell gibt es zwei Bereitstellungsmuster: 1. Einmaliger Beweis + Zuordnung: Veröffentlichen Sie einen Beweis einmal und zeichnen Sie die Adresse → post-quantum Schlüssel auf. Von da an signieren Sie post-quantum für diese Adresse. 2. Pro-Transaktion-Beweis: Jede Transaktion trägt einen einzelnen Beweis, der den Seed mit der Adresse verknüpft und die Nachricht autorisiert. Zustandslos, aber jeder Prüfer muss den Beweis überprüfen. Dies könnte viele Ketten ausschließen, angesichts des Leistungsaufwands, den Beweis pro Transaktion zu überprüfen. Warum das funktioniert: Shor’s Algorithmus bricht diskrete Logs (so dass Public-Key-Systeme wie ECDSA/EdDSA fehlschlagen, sobald der öffentliche Schlüssel exponiert wird). Grover’s Algorithmus bietet nur eine quadratische Beschleunigung für Hash-Vorabbilder. Wenn Ihr privater Schlüssel also aus einem Seed über einen starken Hash (z.B. SHA-512) abgeleitet wird, bleibt der Seed verborgen, selbst wenn eine zukünftige Maschine den heutigen Schlüssel wiederherstellt. Deshalb hilft das "Seed-first" Design in EdDSA. Außerdem benötigen Sie keinen Hard Fork, um zu beginnen. Vor dem Q-Tag können Sie auch Identitäten ohne ZK binden, indem Sie die Legacy-Adresse und den post-quantum Schlüssel in beide Richtungen gegenseitig signieren und zeitlich verankern. Das ist es, was wir mit yellowpages gebaut haben. In dem Beitrag breche ich die Mechanik herunter, was Sie heute auf EdDSA-Ketten sparen können, was Sie realistisch auf ECDSA sparen können, die Vor- und Nachteile von einmaligen vs. pro Transaktion Beweisen und die Grenzen, um die Sie sich kümmern sollten (Seed-Handhabung, Replay-Schutz, Beweis-Kosten). Vollständiger Bericht unten.