Les comptes résistants au quantique du XRP Ledger feraient transporter à chaque paiement qui les utilise environ 3,6 ko de données de plus qu’aujourd’hui, sans que les frais changent. Les chiffres viennent de la XRPL Foundation, dont la feuille de route du protocole, mise à jour le 4 novembre 2026, recense un amendement proposé, baptisé Quantum, qui permettrait aux comptes de signer avec ML-DSA-44, le schéma de signature post-quantique standardisé par le NIST en août 2024. L’étude de la fondation chiffre la charge supplémentaire à 3 627 octets de clé et de signature par transaction, et le coût des travaux entre 215 000 et 255 000 dollars.
Rien de tout cela n’est en service, approuvé ni même numéroté. L’amendement n’a pas encore de numéro XLS, la spécification reste un brouillon soumis à examen public, et la feuille de route situe le développement, la relecture et l’audit à la fin de 2027 ou en 2028.
Le projet n’est pas nouveau non plus. Denis Angell a ouvert la spécification sous forme de discussion GitHub le 8 juillet 2025 et l’a modifiée pour la dernière fois le 20 mai 2026. Ripple a publié un plan post-quantique en quatre phases le 20 avril 2026. Ce qui a relancé le sujet cette semaine, c’est un article de CoinDesk mis en ligne tard le 9 novembre, heure de New York, ainsi qu’un fil de commentaires sur GitHub où des développeurs extérieurs signalaient encore, le même jour, des problèmes dans le code de référence.
Pour les détenteurs de XRP, 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 n’y a rien à faire aujourd’hui. Le XRP s’échangeait vers 1,099 $ à 05 h 13 UTC le 10 novembre, en recul de 12,7 % sur sept jours selon notre relevé de marché, et aucune des sources ne relie ce mouvement au projet quantique.
Ce que l’amendement quantique changerait sur le XRP Ledger
Aujourd’hui, un compte du XRP Ledger signe avec l’un de deux schémas classiques, secp256k1 ou Ed25519. Tous deux ont la même faiblesse face à un ordinateur quantique de grande taille : chaque signature publiée sur le registre révèle la clé publique du compte, et le modèle de menace qui motive les travaux post-quantiques suppose qu’une machine assez puissante pourrait remonter de la clé publique à la clé privée. Tout compte qui a déjà émis une transaction, y compris les portefeuilles chauds des plateformes d’échange, a sa clé publique inscrite sur le registre. Notre explication des clés privées et publiques montre pourquoi ce lien compte.
Le brouillon ajoute un troisième type de clé, nommé dilithium d’après le nom du schéma avant que le NIST ne le rebaptise. Il repose sur un amendement appelé Quantum, dont le vote par défaut est non : rien ne change tant que les validateurs ne choisissent pas de le soutenir. Les adresses seraient dérivées comme aujourd’hui. Jusqu’à l’activation, précise le brouillon, les pairs doivent refuser toute signature produite avec une telle clé.
Le basculement réutilise un outil que le registre possède déjà. Un titulaire définirait une clé régulière dérivée d’une paire de clés ML-DSA-44 avec la transaction SetRegularKey existante, puis signerait avec elle, ou déplacerait ses fonds vers un compte neuf dérivé d’une telle clé. Le réseau ne migre pas les comptes existants. Chaque titulaire, plateforme d’échange ou dépositaire doit agir, et le brouillon demande aux portefeuilles, aux plateformes et aux dépositaires de fournir des outils pour cela. Il déconseille aussi de s’y prendre trop tôt : une clé régulière quantique utilisée avant l’activation produirait des transactions qu’aucun pair n’accepte, de sorte que les détenteurs doivent conserver leur clé classique en secours jusque-là.
ML-DSA-44 est le plus petit des trois jeux de paramètres de la norme FIPS 204, publiée par le NIST le 13 août 2024. Il est déjà utilisé commercialement hors de la crypto : AWS a rendu ses clés de signature ML-DSA-44, ML-DSA-65 et ML-DSA-87 généralement disponibles dans son service de gestion de clés le 13 juin 2025, d’après l’étude de la fondation.
Taille des signatures ML-DSA-44 sur le XRP Ledger
La taille est le prix du nouveau schéma. Un paiement classique transporte une clé publique de 33 octets et une signature d’environ 72 octets, soit 105 octets au total. Un paiement ML-DSA-44 transporte une clé publique de 1 312 octets et une signature de 2 420 octets. Cela fait 3 732 octets, environ 35 fois la paire classique. La norme FIPS 204 fixe la signature à exactement 2 420 octets, mais le brouillon la décrit encore comme variable, « jusqu’à 2 420 octets », et accepte des signatures de consensus à partir de 64 octets. L’étude de la fondation demande que la vérification rejette toute autre longueur, et un relecteur extérieur a formulé la même demande sur GitHub le 2 novembre.
Comptée comme un nœud la stocke, avec l’historique des transactions et les frais de base de données, une telle transaction signée occupe 5 331 octets, contre 1 704 octets pour le paiement XRP ordinaire que l’étude prend pour référence : environ 3,1 fois plus.
| Élément | Paiement classique | Paiement ML-DSA-44 |
|---|---|---|
| Clé publique | 33 octets | 1 312 octets |
| Signature | environ 72 octets | 2 420 octets |
| Clé et signature | 105 octets | 3 732 octets |
| Stockage par transaction signée | 1 704 octets | 5 331 octets |
| Historique supplémentaire, 1 transaction de ce type par ledger | sans objet | environ 42 Go par an |
| Historique supplémentaire, 1 000 par ledger | sans objet | environ 42 029 Go par an |
Source : étude de faisabilité quantique de la XRPL Foundation. La clé secrète, de 2 560 octets dans le brouillon, reste dans le portefeuille et n’atteint jamais le registre.
Le projet ne crée aucun nouvel objet dans le registre, de sorte que l’état que chaque validateur garde en mémoire ne grossit pas. Le coût se déplace ailleurs : la bande passante entre nœuds, la taille de l’historique complet et le temps nécessaire pour vérifier chaque signature. Avec une transaction signée en quantique par ledger, l’historique supplémentaire reste modeste. À mille par ledger, un niveau que le réseau n’atteindrait que si le schéma devenait la norme, il grimpe d’environ 42 téraoctets par an.
Les frais ne bougent pas, les opérateurs de nœuds paient la note
Le brouillon dit sans détour qu’il ne modifie pas le barème des frais. Une transaction plus lourde d’environ 3,7 ko paierait donc les mêmes frais de base qu’une transaction classique. C’est le « no extra fees » du titre de CoinDesk. Le texte laisse la tarification au processus habituel : les opérateurs « devraient » (le brouillon écrit « SHOULD ») fixer les réserves et les frais en conséquence par les mécanismes courants de vote sur les frais, sans proposer le moindre chiffre.
Cela ne veut pas dire que les données supplémentaires sont gratuites. Sur le XRP Ledger, les frais sont détruits et ne sont versés à personne : ils n’ont donc jamais rémunéré les opérateurs de nœuds pour le stockage. Les octets que les signatures quantiques ajouteraient seraient payés par ceux qui font tourner les validateurs et les serveurs à historique complet, en disques et en bande passante.
L’étude de la fondation relève que les frais du registre ne dépendent pas de la taille de la transaction, et laisse ouverte la question d’une règle fondée sur la taille pour les transactions ML-DSA-44. Cette question est renvoyée à un travail ultérieur. « Une étude de migration post-quantique au premier semestre 2027 alimente la spécification », écrit la feuille de route.
Une ligne de 215 000 à 255 000 $ dans une feuille de route à 5 millions
La feuille de route classe Quantum parmi les chantiers de taille XL : 640 heures de développement, 400 heures de relecture par Ripple, une complexité de 3 sur 3 et un score d’adéquation au marché de 7 sur 12. Son coût se décompose ainsi.
| Poste | Estimation |
|---|---|
| Relecture par Ripple, 400 heures à 100–200 $ de l’heure | 40 000 à 80 000 $ |
| Audit externe | 100 000 $ |
| Implémentation de référence | 50 000 $ |
| Travaux sur le registre et les portefeuilles | 25 000 $ |
| Total, en plus de 640 heures de développement | 215 000 à 255 000 $ |
À titre de comparaison, la feuille de route entière compte 24 amendements, dont 2 approuvés et 22 proposés, pour 5,08 à 5,74 millions de dollars et 6 240 heures de développement. Quantum représente à lui seul environ un dixième du temps de développement.
Du code existe, mais seulement sur des branches. La feuille de route renvoie à xrplf/quantum dans le dépôt rippled de XRPLF ; l’en-tête du brouillon cite une autre branche de rippled, dilithium-full, ainsi que des branches de xrpl.js et du publieur de listes. Une branche n’est pas une version publiée, et rien de tout cela n’a été fusionné dans le logiciel serveur qu’exécutent les validateurs.
Les détenteurs doivent désactiver leur ancienne clé maître, et le brouillon n’en dit rien
L’étude de la fondation l’énonce clairement : une clé régulière dilithium ne protège pas un compte dont la clé maître classique est toujours activée. Les règles du registre l’expliquent. Selon la documentation du XRP Ledger, une clé maître peut être désactivée mais jamais modifiée ni supprimée, et dès qu’une clé régulière est définie, l’une comme l’autre peut autoriser des transactions. Un attaquant qui retrouverait la clé maître classique pourrait donc continuer à signer avec elle.
Le remède existe déjà, sous forme d’une étape distincte. Le titulaire envoie une transaction AccountSet avec l’indicateur asfDisableMaster, signée avec la clé maître elle-même, et le registre ne l’accepte que si le compte a déjà une clé régulière ou une liste de signataires multiples, d’après le tutoriel de la documentation. Le brouillon ne mentionne jamais cette étape ; il ne nomme que la voie de la clé régulière et le transfert des fonds vers un nouveau compte. « Les comptes qui ne changent jamais de clé restent exposés », ajoute l’étude, ce qui couvre les portefeuilles perdus, les comptes oubliés et les détenteurs qui n’entendent jamais parler du changement.
Le plan d’avril de Ripple traite le pire scénario dans une phase séparée. Si les signatures classiques étaient cassées avant que la plupart des comptes aient migré, le réseau cesserait de les accepter, et les détenteurs prouveraient qu’ils possèdent leurs anciennes clés au moyen de preuves à divulgation nulle de connaissance pour transférer leurs fonds vers des comptes post-quantiques. Cette phase n’a pas de date dans le plan de Ripple, et le brouillon de spécification ne la couvre pas.
Les validateurs ont leur propre exposition. Leurs manifestes, les clés des éditeurs des listes de validateurs recommandés et les identités des nœuds reposent tous sur des signatures classiques. L’étude note qu’une clé d’éditeur de liste retrouvée permettrait à un attaquant de remplacer la liste de l’éditeur, et que l’identité d’un nœud validateur change quand il renouvelle ses clés, si bien que les réservations de pairs et les réglages de grappe devraient être mis à jour dans tout le réseau.
Bogues ouverts dans le code de référence
Le brouillon reconnaît lui-même certains défauts du code actuel, et l’étude de la fondation les reprend. Le publieur Python des listes de validateurs dérive la graine ML-DSA à partir de 48 octets de SHA-512, alors que le serveur et la bibliothèque xrpl.js en utilisent 32. La même graine produit donc des clés différentes selon le logiciel : un opérateur qui reconstruirait une clé d’éditeur de liste à partir de sa graine avec un autre outil obtiendrait une autre paire de clés. Le brouillon indique que le module Python doit être corrigé avant que la spécification devienne définitive.
Le fichier de vecteurs de test commun, exigé par la spécification, n’existe pas encore, selon l’étude. Les commandes d’administration sign et wallet_propose rejettent toujours le type de clé dilithium, ce que le brouillon reconnaît.
Les commentaires de la discussion GitHub en ajoutent d’autres. Le 15 octobre, le compte quantova-inc, qui a profité du même commentaire pour promouvoir sa propre proposition fondée sur les mémos, a soutenu que le registre devrait désigner le schéma de signature par un identifiant plutôt que de le déduire de la longueur de la clé, afin qu’un second schéma post-quantique puisse être ajouté plus tard sans nouveau changement de format. Le 2 novembre, douglasborthwick-crypto a fait valoir que des vecteurs de test générés par le serveur prouvent seulement que le code est cohérent avec lui-même, a noté que le schéma Dilithium2 de la ronde 3 et le ML-DSA-44 final dérivent des clés différentes à partir de la même graine, et a suggéré les vecteurs officiels ACVP du NIST. Le 9 novembre, quantova-inc, qui a examiné la branche quantique sur un fork tenu par Transia-RnD, a signalé que la vérification liée à un indicateur censé forcer un compte à signer en quantique ne se déclenche jamais pour les clés classiques dans checkSign, et que les chemins de multisignature et de lots n’ont aucune vérification de ce type. Le même commentaire indique que la version fige le code Dilithium de la ronde 3, antérieur à la norme, avec des clés secrètes de 2 528 octets au lieu de 2 560 et sans la séparation de domaine que FIPS 204 exige, de sorte que ses clés ne fonctionneraient pas avec d’autres logiciels conformes à FIPS 204. Il renvoie à un correctif proposé sur ce fork.
Chacun de ces points est l’affirmation d’un seul commentateur. Les mainteneurs ne les avaient pas confirmés dans le fil à la date du matin du 10 novembre. CoinDesk relève aussi qu’aucun test réseau avec tous les validateurs sous les nouvelles signatures n’a été publié.
D’un brouillon GitHub en 2025 à un objectif en 2028
Les dates ci-dessous montrent la lenteur avec laquelle les pièces s’assemblent, et pourquoi les échéances qui comptent sont fixées hors de la crypto.
- 13 août 2024 : le NIST publie FIPS 204, la norme ML-DSA.
- 13 juin 2025 : AWS rend les clés de signature ML-DSA généralement disponibles dans son service de gestion de clés.
- 8 juillet 2025 : Denis Angell ouvre la discussion XRPL-Standards n° 295, Post-Quantum Signatures (ML-DSA-44).
- 20 avril 2026 : Ripple publie son plan en quatre phases, avec des expériences au premier semestre 2026 et une transition complète par un nouvel amendement au plus tard en 2028.
- 20 mai 2026 : dernière mise à jour du brouillon de spécification.
- Octobre 2026 : la version finale de l’IR 8547 du NIST indique que la cryptographie à clé publique vulnérable au quantique sera dépréciée après 2030 et interdite après 2035.
- 4 novembre 2026 : la XRPL Foundation met à jour sa feuille de route avec l’amendement Quantum et son budget.
- 9 novembre 2026 : CoinDesk publie un article sur le projet.
Le Groupe d’experts cyber du G7 demande aux établissements financiers de faire passer leurs systèmes les plus critiques à la cryptographie post-quantique entre 2030 et 2032. Ces échéances, davantage que toute estimation de la date d’arrivée d’une telle machine, expliquent pourquoi les registres qui servent des banques et des gérants d’actifs s’y préparent dès maintenant. La distance qui nous en sépare reste discutée : notre article sur l’estimation d’Alice & Bob pour casser la courbe du Bitcoin montre combien d’hypothèses reposent derrière les calendriers les plus courts. Le secteur ne s’est pas non plus accordé sur le sens de « résistant au quantique », la question que la Quantum Alliance, qui réunit neuf entreprises, s’est donné pour but de trancher en octobre.
Et ensuite pour les signatures post-quantiques du XRPL
La prochaine étape sur le papier est l’étude de migration du premier semestre 2027, censée trancher les questions de conception encore ouvertes, dont le traitement des frais pour les grosses transactions. Le développement, la relecture et un audit externe suivraient fin 2027 ou en 2028. Le plan de Ripple lui-même fixe 2028 comme date limite de la transition complète.
Même alors, l’amendement n’entrerait en vigueur que si les validateurs votent pour, comme pour toute modification des règles du XRP Ledger. Les votes ne se passent pas toujours sans heurt ; l’amendement de nettoyage du réseau a glissé au 4 novembre après une brève baisse du soutien des validateurs. Aucune date d’activation n’existe pour Quantum.
Le repère le plus proche est le fil GitHub. Le signalement du 9 novembre sur checkSign et l’écart de longueur de graine sont assez précis pour être confirmés ou écartés dans le code, et une réponse d’un mainteneur serait le premier signe de la vitesse à laquelle avance le brouillon.