Verona, il “verified intelligence layer”, ha lanciato oggi Fermi, l’upgrade v32 del mainnet di Verona. Con Fermi, le firme post-quantum diventano operative su ogni account della rete. Gli utenti possono associare un autenticatore ML-DSA a qualsiasi account esistente e, se lo desiderano, revocare la chiave pre-quantum senza modificare l’account. Ogni account Verona è infatti uno smart contract con autenticazioni modulari, così la firma post-quantum diventa un’opzione nativa, non una migrazione forzata.
Perché adesso
Le scadenze del “quantum risk” si stanno avvicinando rapidamente. NIST prevede di deprecare le firme a curva ellittica – che oggi proteggono quasi tutte le blockchain – dopo il 2030 e di vietarne l’uso dopo il 2035. Google ha anticipato al 2029 la propria deadline per la migrazione post-quantum. A marzo, Google Quantum AI ha pubblicato stime secondo cui una macchina con meno di mezzo milione di qubit fisici potrebbe violare secp256k1, la curva che protegge Bitcoin ed Ethereum, in pochi minuti: una riduzione di circa venti volte rispetto alle precedenti valutazioni. Oggi una macchina del genere non esiste, ma Verona ha scelto di muoversi finché c’è margine, e con Fermi trasferisce questo vantaggio di tempo a ogni utente.
Cosa introduce Fermi
- ML-DSA-65, lo standard a reticoli FIPS 204 per firme digitali, come autenticatore nativo di account
- SLH-DSA-128s, lo standard FIPS 205 basato su funzioni hash, pensato per tesorerie e cold vault
- Una policy “PQ-required” sugli account che disabilita le chiavi classiche o le obbliga a co-firmare con una chiave post-quantum
- Migrazione “one-click” tramite Verona SDK e dashboard
Perché l’architettura è decisiva
La maggior parte delle chain deriva l’indirizzo da una singola chiave pubblica. Quando l’algoritmo di quella chiave diventa vulnerabile, i fondi devono essere spostati su un nuovo indirizzo. Questo modello lascia una quota stimata intorno a un terzo dell’offerta di Bitcoin in account con chiavi ormai esposte e costringe la roadmap quantistica di Ethereum a passare da nuovi standard di account.
Verona ha adottato un’impostazione diversa fin dal genesis. Ogni account è uno smart contract distribuito tramite governance che gestisce un insieme di “pluggable authenticators”, oggi inclusivi di secp256k1, passkey, wallet Ethereum, JWT e ZKEmail. Aggiungere ML-DSA richiede la stessa operazione di aggiunta di una passkey. È il contratto a detenere l’indirizzo, non la chiave: in questo modo la crittografia può evolvere “sotto” l’account mentre identità, cronologia e saldi restano intatti.
La scommessa
Calcolo quantistico e crittografia si inseguono in un continuo gioco del gatto col topo, e Fermi non è il punto d’arrivo definitivo. Verona non scommette su un algoritmo “vincitore” per sempre. La tesi è un’altra: una rete deve poter sostituire gli algoritmi con un unico upgrade, senza lasciare indietro neppure un account. Fermi affianca chiavi crittografiche a reticoli e chiavi hash-based, così che, se uno dei due presupposti dovesse cadere, gli utenti possano passare liberamente all’alternativa.
«La resistenza quantistica è un problema di migrazione, non un problema tecnico», afferma Anthony Anzalone, fondatore e CEO di Verona. «Tutte le altre chain devono capire come spostare miliardi di dollari su nuovi indirizzi. Su Verona aggiungi una chiave e rimuovi una chiave. Abbiamo progettato gli account in questo modo anni fa perché sapevamo che la crittografia avrebbe continuato a cambiare, e Fermi è la prima volta in cui questo design si dimostra efficace alla scala di rete.»
Le prossime tappe
La fase due di Fermi migrerà le chiavi dei validatori a ML-DSA-65 tramite Cosmos SDK v0.55 e CometBFT v0.40, spostando il consenso stesso su firme post-quantum quando due terzi della potenza di voto dei validatori saranno ruotati. Verona prevede di aggiungere FN-DSA (Falcon) come autenticatore non appena NIST finalizzerà FIPS 206. Gli “authenticator” pensati per la comodità d’uso e basati su infrastruttura terza – tra cui JWT e ZKEmail – resteranno classici finché identity provider e sistemi di prova non completeranno le proprie migrazioni; nel frattempo, non potranno soddisfare una policy PQ-required.
Su Verona
Verona è il “verified intelligence layer” per AI, imprese e utenti finali, sviluppato da Burnt Labs. In precedenza nota come XION, Verona trasforma fatti verificati del mondo reale in un primitivo programmabile. Per saperne di più: verona.dev.
