David Schwartz explique les risques du réseau après le ralentissement sur XRPL

Le ralentissement des transactions sur le réseau XRP Ledger, causé par un problème technique, a entraîné un examen plus large de l'architecture du protocole. David Schwartz, ancien directeur technique de Ripple et l'un des développeurs du système, a expliqué les points de vulnérabilité du réseau dans son évaluation publique après l'incident.

Les ralentissements des clôtures de registre ont déclenché une enquête

Le problème a été identifié lorsque l'équipe des opérations du XRP Ledger a enregistré une anomalie sur le réseau. La fermeture des registres sur le réseau étant nettement plus lente que d'habitude, les ingénieurs ont été amenés à enquêter sur la source du retard. Ce processus a également soulevé des questions sur la résilience de la structure décentralisée au sein de la communauté.

Schwartz a déclaré que le logiciel XRPL est protégé par une architecture de sécurité multicouche. Cependant, il a noté qu'il existe deux scénarios fondamentaux qui pourraient complètement arrêter le réseau. Le premier serait la défaillance simultanée d'un grand nombre de serveurs validateurs à travers le monde. Schwartz a indiqué qu'un tel scénario ne serait envisageable qu'en cas de catastrophe naturelle majeure à l'échelle mondiale.

Le deuxième scénario a été identifié comme une erreur potentielle dans l'algorithme de consensus ou une corruption au niveau du code d'une des fonctions fondamentales du protocole. Schwartz a exprimé que le ralentissement enregistré lors de l'incident récent montre que la marge de sécurité technologique du système s'est réduite, ce qui pourrait indiquer une attaque ciblée ou un bug caché déclenché dans le code.

David Schwartz a souligné que les possibilités de paralyser l'ensemble du réseau se limitaient à une perte d'infrastructure massive ou à une défaillance du mécanisme de consensus, et que le ralentissement récent indiquait une diminution de la marge de sécurité.

Réponse aux allégations de point de défaillance unique

Schwartz a également rejeté les allégations selon lesquelles le réseau serait lié à un seul nœud ou centre. Il a affirmé que le XRPL fonctionne dans une structure entièrement décentralisée, et qu'une grande centrale, voire la fermeture de son propre nœud ou une surcharge, n'affecterait pas directement la fonctionnalité générale du réseau.

Ripple, en tant que l'une des entreprises leaders de l'écosystème XRP, développe des infrastructures de paiement et des solutions financières basées sur la blockchain. Le XRP Ledger est connu comme un réseau blockchain open source fonctionnant indépendamment de Ripple.

Les systèmes de surveillance ont échoué sous la charge

Il a été révélé que le problème le plus concret pendant l'incident était que les systèmes de surveillance du réseau étaient restés faibles sous une charge intense. Lorsque les tours de consensus ralentissaient, les validateurs passaient soudainement à une charge maximale. Le propre nœud de Schwartz n'a pas pu supporter le trafic de requêtes intense et les connexions RPC locales sont restées bloquées dans un état CLOSE_WAIT.

Mini glossaire : RPC est une méthode de communication qui permet à un logiciel de demander des données à distance à un autre système et d'exécuter des commandes. CLOSE_WAIT désigne une situation où une connexion a reçu un signal de fermeture de l'autre côté, mais où le processus local n'est pas encore terminé.

En raison de ce blocage, le système de surveillance interne de Schwartz n'a pas pu enregistrer et transmettre les données de diagnostic au moment le plus critique. L'ingénieur a donc dû redémarrer le serveur sans clarifier la cause exacte de la panne.

Schwartz a rapporté que les données de diagnostic avaient été perdues au moment le plus critique en raison du blocage des connexions sur son nœud, et que le serveur avait été redémarré sans savoir exactement pourquoi il avait posé problème.

Les enregistrements envoyés à un ancien serveur de test sont examinés

Au cours de l'examen, il a également été découvert que les journaux d'un développeur du XRPL avaient été envoyés à un ancien serveur principal de test de la XRP Ledger Foundation. Cela a encore compliqué la collecte complète des données au moment de l'incident.

L'équipe d'ingénierie et les opérateurs de la communauté tentent d'isoler le problème en examinant manuellement les journaux restants. Schwartz a noté que bien qu'il y ait eu une contraction temporaire de la marge de sécurité, l'équipe maintenait la situation sous contrôle et que l'architecture du réseau disposait de réserves techniques suffisantes pour continuer à fonctionner.