Ces développements surviennent alors que XRPL étend son rôle dans les paiements institutionnels, les stablecoins et les actifs tokenisés, ce qui renforce l’importance d’une infrastructure de règlement fiable et de garanties régissant les transactions financières.

$XRP Le ralentissement du registre met en évidence les difficultés de traitement des transactions

Le problème opérationnel est apparu le 21 octobre, lorsque certains registres ont commencé à mettre plus de temps que d’habitude à se clôturer, perturbant le rythme habituel de règlement de la blockchain, de trois à cinq secondes.

XRPL Operations a indiqué que la plupart des registres continuaient à se clôturer normalement, mais que des retards intermittents avaient incité les développeurs à examiner le comportement du réseau et à préparer un correctif logiciel.

Alors que les retards persistaient, l’équipe a diffusé aux opérateurs de hubs, de validateurs et de nœuds une modification de configuration recommandée pour xrpld.

Selon l’équipe des opérations, cet ajustement a rétabli des délais de clôture normaux au 22 octobre, bien que les développeurs aient continué à tester une version intermédiaire destinée à s’attaquer à la cause sous-jacente.

David Schwartz, l’un des architectes d’origine de XRPL et ancien directeur technique de Ripple, a apporté des précisions sur ce qui a pu contribuer à l’incident.

Il a déclaré que son propre hub avait continué à fonctionner normalement après un incident antérieur qu’il estimait sans rapport, mais qu’il l’avait redémarré avec la modification de configuration recommandée.

Schwartz a déclaré :

« Je crois comprendre que le problème était lié aux serveurs qui s’efforçaient trop d’inclure trop de transactions dans chaque registre. »

Interrogé sur la possibilité que cela indique que XRPL avait atteint une limite pratique de sa capacité de traitement des transactions, Schwartz a reconnu un lien entre le volume de transactions et la fréquence de clôture.

Il a ajouté :

« Oui et non. Nous ne pouvons pas clôturer un registre plus souvent que toutes les 4 secondes. Limiter le nombre de transactions par registre n’impose donc pas nécessairement une limite au nombre de transactions par seconde. »

Ses remarques suggèrent un compromis potentiel entre le traitement d’un plus grand nombre de transactions dans chaque registre et le maintien de délais de règlement réguliers.

Toutefois, les développeurs n’ont pas établi si l’incident révélait une contrainte plus générale de capacité du réseau ou un comportement logiciel qui peut être corrigé sans affecter le débit.

Cette distinction a des implications commerciales, car XRPL attire des applications qui nécessitent un règlement prévisible, notamment les transferts du stablecoin RLUSD, les titres tokenisés et les services de paiement institutionnels.

De nouvelles perturbations pourraient compliquer le traitement des transactions pour les services qui dépendent de transferts rapides de fonds ou de garanties.

La prochaine version logicielle sera donc importante pour déterminer si la modification de configuration apporte une solution durable ou si d’autres ajustements sont nécessaires pour maintenir les performances sous une charge de transactions plus élevée.

Un revers lors du vote des validateurs retarde les garanties financières

Par ailleurs, l’amendement fixCleanup3_4_0 de XRPL a subi un revers de gouvernance qui prolongera le délai avant l’activation de plusieurs corrections de son infrastructure financière.

L’amendement, introduit dans la version xrpld 3.4.0 de septembre, traite de problèmes techniques liés aux permissions des jetons, aux teneurs de marché automatisés, aux coffres d’actifs, aux opérations de prêt et aux transactions sous séquestre.

L’une des modifications corrige une faille de délégation de permission qui pourrait permettre à un compte autorisé à détruire certains jetons fongibles d’en créer d’autres dans certaines circonstances.

La documentation du réseau conseille aux émetteurs de ne pas déléguer la permission PaymentBurn concernée avant l’entrée en vigueur de la correction.

D’autres modifications améliorent la précision de la comptabilité des coffres, imposent des garanties relatives aux soldes de jetons et corrigent le traitement des transactions dans les fonctions de négociation décentralisée et de prêt.

Les protections proposées se dirigeaient vers une activation le 23 octobre, avant que le soutien des validateurs ne passe brièvement sous la supermajorité requise pour modifier les règles du protocole XRPL.

XRPL exige le soutien de plus de 80 % des validateurs de confiance, maintenu sans interruption pendant 14 jours, avant qu’un amendement puisse être activé.

La perte temporaire de soutien, le 21 octobre, a effacé la période d’approbation accumulée par l’amendement, même si le soutien est ensuite repassé au-dessus du seuil requis.

Le suivi des amendements XRPLWin situe désormais la première date d’activation possible au 4 novembre, à condition que la nouvelle majorité reste intacte.

Le contributeur de XRPL Vet a confirmé que des votes supplémentaires de validateurs avaient rétabli le compte à rebours avant l’activation de l’amendement. Il a également précisé que fixCleanup3_4_0 corrige des problèmes plus anciens du protocole et n’a aucun lien avec les récents retards de clôture des registres.

Le report prolonge la période avant que les garanties concernées relatives aux permissions des jetons ne deviennent applicables. Il retarde également les corrections visant à améliorer la comptabilité et le traitement des transactions dans l’infrastructure de prêt en développement de XRPL.

Cette infrastructure a encore besoin d’approbations supplémentaires du protocole avant que les services de prêt natifs puissent être lancés.

Une nouvelle baisse du soutien des validateurs réinitialiserait la période d’attente de l’amendement, ce qui pourrait repousser son activation au-delà du 4 novembre.