J'ai examiné davantage de mécanismes de mise à niveau post-quantique, en particulier ceux qui ne nécessitent pas de changement d'adresse. Les chaînes EdDSA qui suivent la RFC-8032 (style Ed25519) ont un avantage intégré. Votre clé de signature n'est pas un scalaire aléatoire brut, elle est dérivée de manière déterministe à partir d'une courte graine par hachage. Cela signifie que vous pouvez prouver que vous connaissez la graine (dans une preuve ZK post-quantique solide) et lier une nouvelle clé post-quantique à la même adresse. Aucun mouvement de fonds et aucune nouvelle donnée de courbe sur la chaîne. Même les comptes dormants peuvent être mis à niveau si la graine existe. Cela couvre des chaînes comme Sui, Solana, NEAR, Stellar, Aptos. Bitcoin/Ethereum n'ont pas cette invariant par défaut car de nombreuses clés ECDSA proviennent de "choisir simplement un scalaire aléatoire". Mais il existe un chemin possible pour de grands cohortes qui utilisent BIP-39 → BIP-32 avec des chemins bien définis. Vous pouvez prouver cette dérivation exacte et lier une clé post-quantique sans déplacer de fonds. Mais, c'est spécifique au portefeuille et peut être complexe : - Le PBKDF2-HMAC-SHA512 de BIP-39 (2048 tours) est coûteux en ZK - BIP-32 ajoute HMAC-SHA512 et des mathématiques secp256k1 à l'intérieur du circuit Cependant, pour des chemins communs (par exemple, Ethereum m/44’/60’/0’/0/x), cela peut être faisable. En général, il existe deux modèles de déploiement : 1. Preuve unique + mappage : publiez une preuve une fois et enregistrez l'adresse → clé post-quantique. À partir de ce moment, vous signez post-quantique pour cette adresse. 2. Preuve par transaction : chaque transaction porte une seule preuve qui lie la graine à l'adresse et autorise le message. Stateless, mais chaque vérificateur doit vérifier la preuve. Cela peut exclure beaucoup de chaînes compte tenu de la surcharge de performance de la vérification de la preuve par tx. Pourquoi cela fonctionne : l'algorithme de Shor casse les logs discrets (donc les systèmes de clé publique comme ECDSA/EdDSA échouent une fois la clé publique exposée). L'algorithme de Grover ne donne qu'un gain de vitesse quadratique pour les préimages de hachage. Donc, si votre clé privée est dérivée d'une graine via un hachage fort (par exemple, SHA-512), la graine reste cachée même si une machine future récupère la clé d'aujourd'hui. C'est pourquoi le design "seed-first" dans EdDSA aide. De plus, vous n'avez pas besoin d'un hard fork pour commencer. Avant le jour Q, vous pouvez également lier des identités sans ZK en signant croisé l'adresse héritée et la clé post-quantique dans les deux sens et en l'ancrant dans le temps. C'est ce que nous avons construit avec yellowpages. Dans le post, je décompose les mécanismes, ce que vous pouvez économiser aujourd'hui sur les chaînes EdDSA, ce que vous pouvez raisonnablement économiser sur ECDSA, les compromis entre les preuves uniques et par tx, et les limites dont vous devriez vous soucier (gestion des graines, protection contre la répétition, coût de la preuve). Écriture complète ci-dessous.