Gli account resistenti al calcolo quantistico di XRP Ledger farebbero viaggiare ogni pagamento con circa 3,6 KB di dati in più rispetto a oggi, a commissione invariata. I numeri arrivano dalla XRPL Foundation, la cui roadmap del protocollo, aggiornata blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 4 novembre 2026, elenca un emendamento proposto chiamato Quantum, che permetterebbe agli account di firmare con ML-DSA-44, lo schema di firma post-quantistica standardizzato dal NIST nell’agosto 2024. Secondo lo studio della fondazione, il carico aggiuntivo è di 3.627 byte tra chiave e firma per ogni transazione, e il lavoro costerebbe da 215.000 a 255.000 dollari.
Nulla di tutto questo è attivo, approvato e nemmeno numerato. L’emendamento non ha ancora un numero XLS, la specifica è una bozza ancora sotto revisione pubblica e la roadmap colloca sviluppo, revisione e audit tra la fine del 2027 e il 2028.
Il progetto non è nuovo. Denis Angell ha aperto la specifica come discussione su GitHub l’8 luglio 2025 e l’ha modificata per l’ultima volta il 20 maggio 2026. Ripple ha pubblicato un piano post-quantistico in quattro fasi il 20 aprile 2026. A riportare il tema in primo piano questa settimana sono stati un articolo di CoinDesk uscito a tarda sera del 9 novembre, ora di New York, e un thread di commenti su GitHub in cui sviluppatori esterni segnalavano ancora problemi nel codice di riferimento lo stesso giorno.
Per chi detiene XRP non c’è nulla da fare oggi. XRP quotava intorno a 1,099 dollari alle 05:13 UTC del 10 novembre, in calo del 12,7% su sette giorni secondo il nostro rilevamento di mercato, e nessuna fonte collega questo movimento al progetto quantistico.
Cosa cambierebbe con l’emendamento quantistico di XRP Ledger
Oggi un account di XRP Ledger firma con uno dei due schemi classici, secp256k1 o Ed25519. Entrambi hanno la stessa debolezza di fronte a un computer quantistico di grandi dimensioni: ogni firma pubblicata sul ledger rivela la chiave pubblica dell’account, e il modello di minaccia alla base del lavoro post-quantistico presuppone che una macchina abbastanza potente possa risalire dalla chiave pubblica a quella privata. Qualsiasi account che abbia inviato almeno una transazione, compresi i wallet caldi degli exchange, ha la propria chiave pubblica sul ledger. La nostra guida alle chiavi private e pubbliche spiega perché quel legame conta.
La bozza aggiunge un terzo tipo di chiave, battezzato dilithium dal nome che lo schema aveva prima che il NIST lo ribattezzasse. Si trova dietro un emendamento chiamato Quantum, il cui voto predefinito è no: senza il sostegno dei validatori non cambia nulla. Gli indirizzi verrebbero derivati come oggi. Fino all’attivazione, dice la bozza, i nodi devono rifiutare qualsiasi firma prodotta con una chiave di questo tipo.
Il passaggio riutilizza uno strumento che il ledger ha già. Il titolare imposterebbe una chiave regolare derivata da una coppia di chiavi ML-DSA-44 con la transazione SetRegularKey esistente e firmerebbe con quella, oppure sposterebbe i fondi su un nuovo account derivato da una chiave di questo tipo. La rete non migra gli account esistenti. Ogni titolare, exchange o custode deve muoversi da sé, e la bozza chiede a wallet, exchange e custodi di fornire gli strumenti per farlo. Avverte anche di non anticipare i tempi: una chiave regolare quantistica usata prima dell’attivazione produrrebbe transazioni che nessun nodo accetta, quindi fino ad allora conviene tenere la chiave classica come ripiego.
ML-DSA-44 è il più piccolo dei tre set di parametri di FIPS 204, lo standard pubblicato dal NIST il 13 agosto 2024. È già in uso commerciale fuori dal mondo crypto: AWS ha reso disponibili in via generale le chiavi di firma ML-DSA-44, ML-DSA-65 e ML-DSA-87 nel suo servizio di gestione delle chiavi il 13 giugno 2025, secondo lo studio della fondazione.
Quanto pesano le firme ML-DSA-44 su XRP Ledger
Il prezzo del nuovo schema è la dimensione. Un pagamento classico porta una chiave pubblica da 33 byte e una firma di circa 72 byte, 105 byte in tutto. Un pagamento ML-DSA-44 porta una chiave pubblica da 1.312 byte e una firma da 2.420 byte. Sono 3.732 byte, circa 35 volte la coppia classica. FIPS 204 fissa la firma esattamente a 2.420 byte, ma la bozza la descrive ancora come variabile, «fino a 2420 byte», e accetta firme di consenso a partire da 64 byte. Lo studio della fondazione sostiene che la verifica dovrebbe respingere qualsiasi altra lunghezza, e un revisore esterno ha avanzato la stessa richiesta su GitHub il 2 novembre.
Contata come la conserva un nodo, con cronologia delle transazioni e overhead del database, una di queste transazioni firmate occupa 5.331 byte, contro i 1.704 byte del normale pagamento in XRP che lo studio usa come riferimento: circa 3,1 volte tanto.
| Voce | Pagamento classico | Pagamento ML-DSA-44 |
|---|---|---|
| Chiave pubblica | 33 byte | 1.312 byte |
| Firma | circa 72 byte | 2.420 byte |
| Chiave più firma | 105 byte | 3.732 byte |
| Spazio per transazione firmata | 1.704 byte | 5.331 byte |
| Cronologia aggiuntiva, 1 transazione di questo tipo per ledger | n.d. | circa 42 GB l’anno |
| Cronologia aggiuntiva, 1.000 per ledger | n.d. | circa 42.029 GB l’anno |
Fonte: studio di fattibilità quantistica della XRPL Foundation. La chiave segreta, 2.560 byte nella bozza, resta nel wallet e non arriva mai sul ledger.
Il progetto non crea nuovi oggetti nel ledger, quindi lo stato che ogni validatore tiene in memoria non cresce. Il costo ricade altrove: sulla banda tra i nodi, sulle dimensioni della cronologia completa e sul tempo necessario a verificare ogni firma. Con una transazione a firma quantistica per ledger la cronologia in più è modesta. Con mille per ledger, un livello che la rete raggiungerebbe solo se lo schema diventasse la norma, si aggiungono circa 42 terabyte l’anno.
La commissione resta uguale e il peso ricade sugli operatori dei nodi
La bozza dice chiaramente di non modificare la tabella delle commissioni. Una transazione più grande di circa 3,7 KB pagherebbe la stessa commissione base di una classica: è il «no extra fees» del titolo di CoinDesk. Sul prezzo la bozza rimanda al processo ordinario: gli operatori «SHOULD price reserves and fees accordingly through standard fee-voting mechanisms», scrive, senza proporre alcun valore.
Questo non significa che i dati in più siano gratuiti. Su XRP Ledger le commissioni vengono bruciate, non pagate a qualcuno, quindi non hanno mai compensato gli operatori dei nodi per lo spazio di archiviazione. I byte aggiunti dalle firme a prova di quantistico li pagherebbe chi gestisce validatori e server con cronologia completa, in dischi e banda.
Lo studio della fondazione segnala che sul ledger le commissioni non crescono con le dimensioni della transazione e lascia aperta la questione se le transazioni ML-DSA-44 richiedano una regola propria basata sulla dimensione. La domanda passa a un lavoro successivo. «A post-quantum migration study in the first half of 2027 feeds the spec», si legge nella roadmap: uno studio di migrazione post-quantistica nella prima metà del 2027 alimenta la specifica.
Una voce da 215.000-255.000 dollari su una roadmap da 5 milioni
La roadmap classifica Quantum come lavoro di taglia XL: 640 ore di sviluppo, 400 ore di revisione da parte di Ripple, complessità 3 su 3 e un punteggio di adattamento al mercato di 7 su 12. Il costo si scompone così.
| Voce | Stima |
|---|---|
| Revisione di Ripple, 400 ore a 100-200 dollari l’ora | da 40.000 a 80.000 dollari |
| Audit esterno | 100.000 dollari |
| Implementazione di riferimento | 50.000 dollari |
| Lavoro su ledger e wallet | 25.000 dollari |
| Totale, oltre alle 640 ore di sviluppo | da 215.000 a 255.000 dollari |
Per darsi una misura, l’intera roadmap elenca 24 emendamenti, 2 approvati e 22 proposti, per una spesa da 5,08 a 5,74 milioni di dollari e 6.240 ore di sviluppo. Quantum da solo pesa circa un decimo del tempo di sviluppo.
Il codice esiste, ma solo su branch. La roadmap indica xrplf/quantum nel repository rippled di XRPLF; l’intestazione della bozza elenca un altro branch di rippled, dilithium-full, più branch di xrpl.js e del publisher delle liste. Un branch non è una release, e nulla di tutto questo è stato integrato nel software server che i validatori eseguono.
I titolari devono spegnere la vecchia chiave master, e la bozza non ne parla
Lo studio della fondazione lo dice senza giri di parole: una chiave regolare dilithium non protegge un account la cui chiave master classica è ancora attiva. Lo spiegano le regole stesse del ledger. Secondo la documentazione di XRP Ledger, una chiave master può essere disattivata ma mai cambiata o rimossa, e una volta impostata una chiave regolare, entrambe possono autorizzare transazioni. Un attaccante che recuperasse la chiave master classica potrebbe continuare a firmare con essa.
La soluzione esiste già oggi, come passaggio separato. Il titolare invia una transazione AccountSet con il flag asfDisableMaster, firmata con la chiave master stessa, e il ledger la accetta solo se l’account ha già una chiave regolare o una lista di firmatari multipli, secondo la guida pratica della documentazione. La bozza non cita mai questo passaggio: nomina soltanto la via della chiave regolare e lo spostamento dei fondi su un nuovo account. «Accounts that never rotate stay exposed», aggiunge lo studio, cioè gli account che non ruotano la chiave restano esposti, e vi rientrano wallet smarriti, account dimenticati e titolari che non sapranno mai del cambiamento.
Il piano di aprile di Ripple affronta il caso peggiore in una fase a parte. Se le firme classiche venissero violate prima che la maggior parte degli account sia migrata, la rete smetterebbe di accettarle e i titolari dimostrerebbero il possesso delle vecchie chiavi con prove a conoscenza zero per spostare i fondi su account post-quantistici. Nel piano di Ripple quella fase non ha una data, e la bozza della specifica non la copre.
I validatori hanno un’esposizione propria. I loro manifest, le chiavi dei publisher delle liste di validatori raccomandati e le identità dei nodi usano tutti firme classiche. Lo studio osserva che una chiave di publisher recuperata permetterebbe a un attaccante di sostituire la lista del publisher, e che l’identità di un nodo validatore cambia quando ruota le chiavi, quindi le riserve di peer e le impostazioni dei cluster andrebbero aggiornate in tutta la rete.
I bug aperti nel codice di riferimento
La bozza stessa ammette alcuni difetti del codice attuale, e lo studio della fondazione li ripete. Il publisher Python delle liste di validatori ricava il seed ML-DSA da 48 byte di SHA-512, mentre il server e la libreria xrpl.js ne usano 32. Lo stesso seed produce quindi chiavi diverse a seconda del software, e chi ricostruisse la chiave di un publisher dal suo seed con un altro strumento otterrebbe una coppia di chiavi diversa. La bozza dice che il modulo Python va corretto prima che la specifica diventi definitiva.
Il file condiviso di vettori di test che la specifica richiede non esiste ancora, secondo lo studio. I comandi di amministrazione sign e wallet_propose rifiutano ancora il tipo di chiave dilithium, cosa che la bozza riconosce.
I commenti sulla discussione su GitHub aggiungono altro. Il 15 ottobre l’account quantova-inc, che nello stesso commento promuoveva una propria proposta basata sui memo, sosteneva che il ledger dovrebbe indicare lo schema di firma con un identificatore anziché dedurlo dalla lunghezza della chiave, così da poter aggiungere in seguito un secondo schema post-quantistico senza un altro cambio di formato. Il 2 novembre douglasborthwick-crypto ha sostenuto che i vettori di test generati dal server dimostrano soltanto che il codice è d’accordo con sé stesso, ha notato che lo schema Dilithium2 del terzo round e l’ML-DSA-44 finale derivano chiavi diverse dallo stesso seed e ha suggerito i vettori ufficiali ACVP del NIST. Il 9 novembre quantova-inc, esaminando il branch quantistico su un fork gestito da Transia-RnD, ha segnalato che il controllo dietro il flag pensato per obbligare un account alle firme quantistiche non scatta mai per le chiavi classiche in checkSign, e che i percorsi multisign e batch non hanno alcun controllo del genere. Lo stesso commento afferma che la build usa il codice Dilithium del terzo round, precedente allo standard, con chiavi segrete da 2.528 byte invece di 2.560 e senza la separazione di dominio richiesta da FIPS 204, quindi le sue chiavi non funzionerebbero con altro software FIPS 204. Rimanda a una correzione proposta su quel fork.
Ognuna è l’affermazione di un singolo commentatore. Alla mattina del 10 novembre i manutentori non le avevano confermate nel thread. CoinDesk osserva inoltre che non è stato pubblicato alcun test di rete con tutti i validatori che usano le nuove firme.
Da una bozza su GitHub nel 2025 a un obiettivo al 2028
Le date qui sotto mostrano con quanta lentezza si siano messi insieme i pezzi, e perché le scadenze che contano siano fissate fuori dal mondo crypto.
- 13 agosto 2024: il NIST pubblica FIPS 204, lo standard ML-DSA.
- 13 giugno 2025: AWS rende disponibili in via generale le chiavi di firma ML-DSA nel suo servizio di gestione delle chiavi.
- 8 luglio 2025: Denis Angell apre la discussione XRPL-Standards n. 295, Post-Quantum Signatures (ML-DSA-44).
- 20 aprile 2026: Ripple pubblica il suo piano in quattro fasi, con esperimenti nella prima metà del 2026 e una transizione completa tramite un nuovo emendamento entro il 2028 al più tardi.
- 20 maggio 2026: la bozza della specifica viene aggiornata per l’ultima volta.
- Ottobre 2026: la versione finale del NIST IR 8547 stabilisce che la crittografia a chiave pubblica vulnerabile ai computer quantistici sarà deprecata dopo il 2030 e vietata dopo il 2035.
- 4 novembre 2026: la XRPL Foundation aggiorna la roadmap con l’emendamento Quantum e il relativo budget.
- 9 novembre 2026: CoinDesk riporta il progetto.
Il Cyber Expert Group del G7 chiede alle aziende finanziarie di portare i sistemi più critici alla crittografia post-quantistica tra il 2030 e il 2032. Sono questi traguardi, più di qualunque stima su quando esisterà la macchina, a spiegare perché i ledger che servono banche e gestori di fondi pianifichino già adesso. Quanto sia lontana quella macchina resta oggetto di discussione: il nostro articolo sulla stima di Alice & Bob per violare la curva di Bitcoin mostra quante ipotesi stiano dietro le previsioni più ravvicinate. Nemmeno sul significato di «resistente ai computer quantistici» il settore è d’accordo, ed è la domanda a cui ha cercato di rispondere a ottobre la Quantum Alliance di nove aziende.
Cosa succede ora con le firme post-quantistiche di XRPL
Il passo successivo sulla carta è lo studio di migrazione della prima metà del 2027, che dovrebbe chiarire le questioni di progetto ancora aperte, a cominciare dal trattamento delle commissioni per le transazioni di grandi dimensioni. Sviluppo, revisione e audit esterno seguirebbero tra la fine del 2027 e il 2028. Il piano di Ripple fissa al 2028 la data limite per la transizione completa.
Anche allora, l’emendamento entrerebbe in vigore solo se i validatori votassero a favore, come per ogni modifica alle regole di XRP Ledger. I voti non sempre filano lisci: il recente emendamento di pulizia è slittato al 4 novembre dopo un breve calo del sostegno dei validatori. Per Quantum non esiste alcuna data di attivazione.
Il segnale più vicino è il thread su GitHub. La segnalazione del 9 novembre su checkSign e la discrepanza nella lunghezza del seed sono abbastanza precise da poter essere confermate o smentite nel codice, e una risposta di un manutentore sarebbe il primo indizio sulla velocità con cui la bozza avanza.