Une affirmation circulant sur les réseaux sociaux selon laquelle les nœuds RPC du ledger XRP peuvent traiter 30 000 messages par seconde semble impressionnante. Le problème est que les benchmarks vérifiés ne soutiennent pas réellement ce chiffre.
Ce que montrent réellement les chiffres
XRPL Labs, l'un des principaux développeurs d'infrastructure pour le XRP Ledger, s'est concentré sur la latence plutôt que sur le débit brut des messages. Leur point de contact public affiche actuellement une latence p50 d'environ 371 millisecondes pour les appels ledger_current, ce qui en fait l'option à la plus faible latence parmi les serveurs XRPL publics.
Des clusters de serveurs publics ont été observés en train de gérer plus de 10 000 lectures par seconde pendant les périodes de pointe. C’est un chiffre solide pour une infrastructure blockchain, mais un tiers du chiffre revendiqué de 30 000.
GetBlock, un autre fournisseur d'infrastructure, affirme que ses nœuds XRPL peuvent traiter plus de 1 000 requêtes par seconde sans limitations de débit sur les configurations dédiées.
La plus proche approximation du chiffre principal concerne les messages des validateurs, qui constituent une catégorie de trafic fondamentalement différente. La gestion des messages des validateurs a enregistré des moyennes d'environ 3 260 messages par seconde dans des conditions de test optimales, avec des pics dépassant 6 100 messages par seconde. Mais le trafic de consensus entre validateurs et les requêtes RPC client-serveur sont des choses différentes.
Dans les environnements de production, le débit réel de transactions du réseau XRPL a historiquement varié entre 100 et 230 transactions par seconde lors des pics quotidiens. Les maximums théoriques atteints dans des environnements de test contrôlés ont dépassé 1 500 TPS, ce qui reste encore un ordre de grandeur en dessous du chiffre de 30 000 qui est évoqué.
Pourquoi l'écart compte
La distinction entre messages par seconde et transactions par seconde est importante ici. Un nœud RPC peut gérer des milliers de demandes en lecture (recherches de solde, requêtes de registre, mises à jour d'abonnement) qui ne se traduisent jamais par l'écriture d'une transaction dans le registre. Compter tous les messages entrants, y compris les pings, les vérifications d'état et les demandes échouées, produira toujours un chiffre plus élevé que le comptage des transactions réellement traitées.
Pour XRP spécifiquement, cela est important car Ripple positionne le XRPL comme une infrastructure pour le traitement des paiements institutionnels et les activités d'échange décentralisé. Ces deux cas d'utilisation nécessitent des performances prévisibles et vérifiables sous charge soutenue, et non des pics théoriques atteints dans des conditions de laboratoire.
Où l'infrastructure XRPL est réellement dirigée
La latence p50 de 371 ms représente des progrès significatifs pour un réseau décentralisé gérant une vérification cryptographique à chaque requête. Un réseau de paiement qui traite de manière constante les requêtes en moins de 400 millisecondes est plus utile pour une banque ou un fournisseur de paiement qu'un réseau qui prétend un débit extrêmement élevé mais offre des temps de réponse imprévisibles.
La pile d’infrastructure se diversifie également. De nombreux 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 gérer un volume important de requêtes, même avant l’entrée en scène des configurations d’entreprise dédiées.