Une affirmation circulant sur les réseaux sociaux selon laquelle les nœuds RPC du XRP Ledger peuvent traiter 30 000 messages par seconde semble impressionnante. Le problème, c'est que les benchmarks vérifiés ne soutiennent pas ce chiffre. C'est un schéma observé dans tout l'écosystème blockchain : les chiffres de débit vedettes circulent détachés de leurs conditions de test d'origine — souvent des mesures en laboratoire, des comptages de messages internes ou des projections optimistes — avant d'être répétés comme s'il s'agissait de capacités en production.

Ce que révèlent les chiffres réels

XRPL Labs, l'un des principaux développeurs d'infrastructure du XRP Ledger, s'est concentré sur la latence plutôt que sur le débit brut de messages. Son endpoint public affiche actuellement une latence p50 d'environ 371 millisecondes pour les appels ledger_current, ce qui en fait l'option la plus rapide parmi les serveurs XRPL publics.

Les clusters de serveurs publics ont été observés traitant plus de 10 000 lectures par seconde pendant les périodes de pointe. C'est un bon chiffre pour une infrastructure blockchain, mais il représente un tiers du chiffre de 30 000 revendiqué.

GetBlock, un autre fournisseur d'infrastructure, affirme que ses nœuds XRPL peuvent traiter plus de 1 000 requêtes par seconde sans limites de débit sur des configurations dédiées.

Ce qui se rapproche le plus du chiffre vedette concerne la messagerie des validateurs, une catégorie de trafic fondamentalement différente. Le traitement des messages de validateurs a enregistré des moyennes d'environ 3 260 messages par seconde dans des conditions de test optimales, avec des pics supérieurs à 6 100 messages par seconde. Mais le trafic de consensus entre validateurs et les requêtes RPC client-serveur ne sont pas comparables.

En environnement de production, le débit réel de transactions du réseau XRPL s'est historiquement situé entre 100 et 230 transactions par seconde lors des pics quotidiens. Les maximums théoriques dans des environnements de test contrôlés ont dépassé 1 500 TPS, soit un ordre de grandeur en dessous du chiffre de 30 000 cité.

Pourquoi cet écart est important

La distinction entre messages par seconde et transactions par seconde est essentielle. Un nœud RPC peut gérer des milliers de requêtes de lecture — consultations de soldes, requêtes de registre, mises à jour d'abonnements — qui ne aboutissent jamais à une transaction inscrite dans le registre. Compter tous les messages entrants, y compris les pings, les vérifications de statut et les requêtes échouées, donnera toujours un chiffre plus élevé que le comptage des transactions réellement traitées.

Pour XRP en particulier, cela compte car Ripple positionne le XRPL comme une infrastructure pour le traitement des paiements institutionnels et l'activité de exchange décentralisé. Ces deux cas d'usage exigent des performances prévisibles et vérifiables sous charge soutenue, pas des pics théoriques atteints en laboratoire. Cela compte aussi pour les développeurs qui choisissent leur infrastructure : une planification de capacité basée sur des chiffres gonflés conduit à des systèmes sous-dimensionnés et à des pannes lors des pics de demande.

Vers où se dirige réellement l'infrastructure XRPL

Le chiffre de latence p50 de 371 ms représente un progrès significatif pour un réseau décentralisé effectuant une vérification cryptographique sur chaque requête. Un réseau de paiement qui traite systématiquement les requêtes en moins de 400 millisecondes est plus utile à une banque ou à un fournisseur de paiement qu'un réseau revendiquant un débit stratosphérique mais livrant des temps de réponse imprévisibles.

La pile d'infrastructure se diversifie également. Plusieurs fournisseurs proposent désormais des services de nœuds XRPL dédiés, ce qui répartit la charge et réduit les points de défaillance uniques. Les plus de 10 000 lectures par seconde observées sur les clusters publics suggèrent que le réseau peut absorber un volume de requêtes significatif, même avant l'arrivée des configurations d'entreprise dédiées.

Avec le marché automatisé natif (AMM) du XRPL désormais actif sur le mainnet et une sidechain compatible EVM en développement, la demande sur l'infrastructure RPC devrait dépasser les simples requêtes de paiement. Cela rend le benchmarking vérifiable et bien documenté — celui que XRPL Labs publie avec des latences par centile — un indicateur plus utile que les affirmations virales de débit, et c'est la métrique à surveiller à mesure que l'adoption de ces nouvelles fonctionnalités s'intensifie.