La Banque des règlements internationaux a publié un document de travail le 2 septembre décrivant un prototype pour vérifier l'authenticité des statistiques officielles. Le système transforme un fichier statistique en uneempreinte cryptographique, ancre un résumé de ces empreintes sur le XRP Ledger et permet à un destinataire de comparer le fichier avec le registre public.
Le résultat crée un verdict partagé pour XRP. Le prototype offre à XRPL un cas d'utilisation crédible de type institutionnel, tandis que sa conception par lot maintient mécaniquement faible le chemin de brûlage direct des frais. Une transaction sur le ledger peut représenter des milliers de jeux de données, de sorte que l'activité utile peut évoluer beaucoup plus rapidement que le nombre de transactions consommant XRP.
La recherche est apparue en ligne pour la première fois via SAGE le 1er août ; le 2 septembre marque sa publication en tant que BIS Working Paper 1374. Le document présente les opinions des auteurs et précise que les références aux entreprises et projets sont illustratives. Sa mise en œuvre reste un proof of concept expérimental sur XRPL DevNet, et les sources examinées ne révèlent aucune relation commerciale avec Ripple.
Comment fonctionne le système d'authentification
Les statistiques officielles sont généralement transmises au format SDMX, une norme pour l'échange de données statistiques et de métadonnées. Le prototype normalise un fichier SDMX et applique un hachage SHA3-512 à l'ensemble du fichier ou à des séries de données individuelles. Il combine ensuite ces empreintes dans une arbre de Merkle, une structure qui compresse un grand ensemble d'enregistrements en une seule valeur résumée appelée racine.
La racine est inscrite dans le champ memo d'une transaction XRPL. Les statistiques sous-jacentes ainsi que les magasins et preuves opérationnelles du prototype restent hors chaîne. Le fichier SDMX renvoyé intègre la référence de la transaction, les empreintes ordonnées et une credential vérifiable signée, fournissant au destinataire les éléments nécessaires pour reconstituer la racine et la comparer avec le registre.
XRPL sert donc de notaire public horodaté pour l'engagement. Il ne sert pas de base de données contenant les chiffres économiques. L'implémentation open-source se décrit comme expérimentale, inadaptée à la production et non maintenue.
Les auteurs ont sélectionné XRPL pour ses frais nominaux faibles, sa rapidité de finalisation de la consensus et ses ressources de développement accessibles. Ils ont également rendu l'interface blockchain remplaçable, afin qu'un autre registre puisse jouer le même rôle d'ancrage. Ce choix de conception fait du prototype une preuve de la méthode d'authentification et de la capacité de XRPL à l'héberger, et non une preuve que la méthode dépend du ledger XRP.
Les résultats de performance proviennent d'une seule station de travail de développeur connectée à XRPL DevNet et utilisant un corpus SDMX synthétique. Dans ces tests contrôlés, la latence médiane de publication était de trois à cinq secondes et la vérification a pris une à deux secondes. L'évaluation n'a pas pris en compte une charge soutenue sur le mainnet, un pare-feu d'entreprise, la signature assistée par un module de sécurité matériel, ni des conditions adverses. DevNet utilise des XRP de test sans valeur réelle, donc l'exécution a produit des mesures techniques plutôt que de la demande réelle de jetons.
Ces limites laissent néanmoins un résultat significatif. Un éditeur statistique pourrait fournir une vérification indépendante de l'intégrité sans exposer des données confidentielles sur un registre public. Le compromis économique apparaît dans le même mécanisme : le regroupement Merkle réduit le nombre d'engagements sur chaîne nécessaires pour authentifier un grand ensemble d'informations.
Le calcul de la capture de valeur de XRP
Le coût standard d'une transaction de XRPL débute normalement à 10 drops, équivalents à 0,00001 XRP. Lorsqu'une transaction est intégrée dans un registre validé, ses frais sont détruits. La charge du réseau peut augmenter ce coût, et certains types de transactions spéciales peuvent avoir des minima différents, mais le document de la BRI utilise 10 drops comme cas de base.
Les frais évoluent avec les transactions d'ancrage, tandis que le volume de jeu de données peut être compressé en lots. L'arithmétique suivante illustre l'écart avec un minimum constant de 10 drops et des transactions standard :
| Schéma d'activité | Transactions d'ancrage | XRP brûlé |
|---|---|---|
| 1 million de jeux de données, regroupés par 1 000 par ancre | 1 000 | 0,01 XRP |
| 1 million d'ancres individuelles | 1 000 000 | 10 XRP |
| 1 ancre par minute pendant 365 jours | 525 600 | 5,256 XRP |
| 1 ancre par seconde pendant 365 jours | 31 536 000 | 315,36 XRP |
Il s'agit d'illustrations d'échelle, et non de prévisions de déploiement. La brûlure réelle dépendra de la fréquence à laquelle les éditeurs soumettent des ancres, du nombre de jeux de données qu'ils regroupent, de la charge réseau actuelle et du type de transaction. Le prototype DevNet n'a généré aucune de cette demande sur le mainnet.
Le modèle de coût de l'article pointe dans la même direction. Il suppose une commission de 10 drops et un prix illustratif de 0,30 $ par XRP, ce qui constitue une entrée du modèle et non une cotation actuelle. Avec une taille de lot de 1 000, les auteurs calculent un coût sur chaîne de 0,000000003 $ par jeu de données. Au-delà d'environ 50 éléments par lot, le traitement et le stockage brut dominent les coûts de chaîne et de stockage de la preuve dans leurs exemples.
Les publications urgentes peuvent favoriser des lots plus petits, car attendre davantage de jeux de données crée un retard. Même ainsi, l'article indique que les faibles frais nominaux de XRPL limitent la pénalité. Pour les détenteurs de XRP, cela signifie que le rythme de production est plus important que le nombre global de fichiers ou de séries authentifiés.
Les réserves mainnet créent un deuxième chemin conditionnel. Selon les règles de réserve XRPL en vigueur, chaque adresse doit détenir une réserve de base de 1 XRP, ainsi que 0,2 XRP supplémentaires pour chaque objet de registre compté comme réserve. Le réseau détient ces soldes comme préfinancement ; les frais de transaction ordinaires correspondent à l'XRP qui est détruit.
La demande de réserve augmente lorsqu'un déploiement nécessite de nouveaux comptes ou objets de registre. Un jeu de données ne porte pas sa propre exigence de réserve, et l'ancrage répété de mémo depuis un compte existant ne verrouille pas 1 XRP à chaque fois. Le vote des validateurs peut également modifier les niveaux de réserve. L'utilisation en production pourrait donc augmenter les XRP détenus sur de nombreux nouveaux comptes institutionnels, mais cet effet dépend de l'architecture du déploiement plutôt que du débit du jeu de données.
Le document soutient une conclusion de capture de valeur restreinte. XRP fournirait les frais et les réserves pour une version Mainnet, tandis que le regroupement Merkle compresse délibérément le flux de frais récurrents. Selon les hypothèses du document et les mécanismes de frais actuels, le canal de brûlage direct reste limité même si le volume de données authentifiées augmente.
Le prix du marché de XRP peut toujours réagir aux attentes, à la liquidité et à l'activité ailleurs sur le réseau. Ces forces se situent en dehors de ce prototype. Le travail de la BRI établit XRPL comme une couche d'authentification à faible coût viable dans des conditions contrôlées ; une demande matérielle de jetons nécessiterait une cadence d'ancrage soutenue, une création massive de comptes ou d'autres activités centrées sur XRP que l'expérience n'a pas démontrées.
Le post BIS explique pourquoi une adoption institutionnelle réelle sur le XRP Ledger ne déclenchera pas la pénurie d'approvisionnement en XRP que les détenteurs attendent est apparu pour la première fois sur CryptoSlate.