Un audit de sécurité mené par Sherlock a identifié 96 bugs dans le code du XRP Ledger avant que la version n'atteigne les utilisateurs, ce qui en fait l'une des revues pré-déploiement les plus substantielles signalées pour le logiciel de ce réseau.

Ce que l'audit de Sherlock a révélé

L'audit a été mené via la plateforme d'examen concurrentiel de Sherlock, qui a hébergé le concours couvrant le code du XRP Ledger. Dans ce modèle, des chercheurs en sécurité indépendants examinent un code pendant une période d'examen définie, les problèmes étant signalés avant la livraison du code. L'examen ciblait le logiciel central du registre plutôt qu'une application isolée. Ce cœur, c'est rippled, l'implémentation serveur open source, écrite principalement en C++, que les validateurs et les autres serveurs exécutent pour faire fonctionner le réseau, ce qui place les problèmes signalés plus près des fondations du registre que des bugs limités à une application ou à un portefeuille.

Les revues de ce type, fondées sur des concours où des chercheurs indépendants se disputent des récompenses pour des constats vérifiés, sont devenues un pilier de la sécurité des contrats intelligents grâce à des plateformes telles que Sherlock et Code4rena. En mener une contre le logiciel de nœud d'un grand registre étend ce même modèle plus profondément dans la pile, des contrats au niveau applicatif jusqu'au code qui traite chaque transaction.

Selon un reportage, le processus a fait apparaître 96 bugs avant que le code ne soit livré à un seul portefeuille. Ce chiffre désigne des problèmes signalés pendant la période d'examen, et non des exploits confirmés en production.

La version associée à ce cycle est documentée dans le journal des modifications de la mise à jour rippled 3.3.0 du réseau lui-même, la version qui se trouve au cœur du travail audité.

Pourquoi la découverte de ces bugs avant la publication est importante

Détecter les défauts avant le déploiement permet de les corriger pendant que le code est encore en cours d'examen, plutôt qu'après son exécution en production sur les validateurs et dans les portefeuilles des utilisateurs. Ce calendrier constitue la valeur essentielle d'un audit pré-publication.

Pour un registre axé sur le règlement, la découverte avant publication réduit le risque qu'un défaut atteigne la production, où des fonds, le traitement des transactions ou le comportement du consensus pourraient être affectés. L'audit fonctionne comme un filtre entre le développement et l'utilisation en production. Les enjeux sont propres à ce type d'infrastructure : le XRP Ledger confirme les paiements grâce à un processus d'accord entre son ensemble de validateurs plutôt que par un minage à preuve de travail, de sorte que les défauts touchant le traitement des transactions ou le consensus se situent dans la couche dont dépend chaque utilisateur du réseau.

L'équipe des opérations du XRP Ledger a évoqué cette revue via son canal officiel sur X, soulignant que l'audit faisait partie du processus de publication et non d'une réponse à un incident.

Ce que cela signifie pour la supervision du XRP Ledger à l'avenir

Faire appel à une revue externe tierce ajoute une couche de contrôle au-delà des tests internes, et le nombre de bugs signalé montre que de telles revues font encore apparaître un volume significatif de problèmes, même sur une infrastructure établie.

Les audits externes sont devenus un signal de confiance habituel dans l'écosystème crypto, à l'instar des attestations de réserves qui ont façonné le débat sur les garanties des stablecoins lorsque l'audit du Big Four de Tether a indiqué que les réserves dépassaient les passifs. L'examen du code et l'attestation financière visent le même objectif : une assurance vérifiable pour les utilisateurs.

Cette question d'assurance s'étend également aux garanties au niveau des portefeuilles, un domaine mis en lumière récemment lorsque les utilisateurs de CyberWallet et de Passkey ont été confrontés à une suspension des retraits. La préparation de la publication au niveau du protocole et la fiabilité au niveau du portefeuille déterminent ensemble le degré de confiance que les utilisateurs peuvent accorder à un réseau.

Les détails des niveaux de gravité et la manière dont chaque problème a été résolu n'ont pas été établis dans les reportages disponibles ; l'importance repose donc sur l'ampleur de la revue et son caractère antérieur à la publication, plutôt que sur la nature spécifique de chaque bug. Les signaux à surveiller désormais sont la présence ou non d'une ventilation par gravité et de notes de remédiation dans la documentation de la version, et la récurrence ou non des concours tiers comme composante permanente des cycles de publication du XRPL.

Avertissement : cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou en investissement. Les marchés des cryptomonnaies et des actifs numériques comportent des risques importants. Faites toujours vos propres recherches avant de prendre une décision.