Ho esaminato più meccanismi di aggiornamento post-quantum, specialmente quelli che non richiedono un cambio di indirizzo. Le catene EdDSA che seguono l'RFC-8032 (stile Ed25519) hanno un vantaggio integrato. La tua chiave di firma non è uno scalare casuale grezzo, ma è derivata in modo deterministico da un breve seed tramite hashing. Ciò significa che puoi dimostrare di conoscere il seed (in una prova ZK post-quantum-sound) e associare una nuova chiave post-quantum allo stesso indirizzo. Nessun movimento di fondi e nessun nuovo dato sulla curva on-chain. Anche gli account dormienti possono essere aggiornati se il seed esiste. Questo copre catene come Sui, Solana, NEAR, Stellar, Aptos. Bitcoin/Ethereum non hanno quell'invariante per impostazione predefinita perché molte chiavi ECDSA provengono da "scegli un semplice scalare casuale". Ma c'è un percorso possibile per grandi coorti che utilizzano BIP-39 → BIP-32 con percorsi ben definiti. Puoi dimostrare quella derivazione esatta e associare una chiave post-quantum senza muovere fondi. Ma, è specifico per il wallet e potrebbe essere complesso: -  Il PBKDF2-HMAC-SHA512 di BIP-39 (2048 giri) è costoso in ZK - BIP-32 aggiunge HMAC-SHA512 e matematica secp256k1 all'interno del circuito Tuttavia, per percorsi comuni (ad es., Ethereum m/44’/60’/0’/0/x), potrebbe essere fattibile. In generale ci sono due modelli di distribuzione: 1. Prova una tantum + mappatura: pubblica una prova una volta e registra indirizzo → chiave post-quantum. Da quel momento in poi, firmi post-quantum per quell'indirizzo. 2. Prova per transazione: ogni transazione porta una singola prova che lega il seed all'indirizzo e autorizza il messaggio. Senza stato, ma ogni verificatore deve controllare la prova. Questo potrebbe escludere molte catene dato l'overhead di prestazioni della verifica della prova per tx. Perché questo funziona: l'algoritmo di Shor rompe i log discreti (quindi i sistemi a chiave pubblica come ECDSA/EdDSA falliscono una volta che la chiave pubblica è esposta). L'algoritmo di Grover fornisce solo un'accelerazione quadratica per le preimmagini hash. Quindi, se la tua chiave privata è derivata da un seed tramite un hash forte (ad es., SHA-512), il seed rimane nascosto anche se una futura macchina recupera la chiave di oggi. Ecco perché il design "seed-first" in EdDSA aiuta. Inoltre, non hai bisogno di un hard fork per iniziare. Prima del Giorno Q puoi anche associare identità senza ZK incrociando la firma dell'indirizzo legacy e della chiave post-quantum in entrambe le direzioni e ancorandola nel tempo. Questo è ciò che abbiamo costruito con yellowpages. Nel post analizzo i meccanismi, cosa puoi risparmiare oggi sulle catene EdDSA, cosa puoi realisticamente risparmiare su ECDSA, i compromessi tra prove una tantum e per tx, e i limiti di cui dovresti preoccuparti (gestione del seed, protezione da replay, costo della prova). Scrittura completa qui sotto.