Une défaillance technique sur le réseau XRP Ledger (XRPL) qui a ralenti le traitement des transactions s'est transformée en une analyse ouverte de l'architecture du protocole. David Schwartz, ancien directeur de la technologie de Ripple et co-créateur du système, a publiquement nommé les points vulnérables de la blockchain mis en évidence par l'incident.
Les problèmes ont commencé après que l'équipe des opérations du XRP Ledger a enregistré une anomalie : les registres du réseau ont commencé à se fermer nettement plus lentement que d'habitude. Pendant que les ingénieurs cherchaient la cause des retards, des questions ont surgi dans la communauté sur la fiabilité du système décentralisé. Les utilisateurs s'inquiétaient de savoir si le réseau pouvait tomber en panne en raison de la surcharge de plusieurs hubs clés. Schwartz est intervenu dans la discussion pour expliquer les véritables limites de la résilience de XRPL.
Selon l'évaluation de Schwartz, le logiciel XRP Ledger est protégé par un système de sécurité multicouche. Néanmoins, en théorie, seuls deux scénarios sont capables de paralyser complètement l'ensemble du réseau :
Défaillance massive de l'infrastructure : une situation dans laquelle un nombre énorme de serveurs validateurs à travers le monde tombent en panne simultanément. Un tel résultat n'est possible qu'en cas de catastrophe naturelle mondiale, les développeurs le considèrent donc comme improbable.
Défaillance de l'algorithme de consensus : une erreur dans le mécanisme même de recherche d'accord entre les nœuds, ou la défaillance d'une autre fonction de base du protocole au niveau du code.
Le ralentissement enregistré des tours est une preuve directe que les marges de sécurité technologique du système ont diminué. Schwartz a admis qu'il s'agit d'un marqueur indiquant que le réseau est soit sous une attaque ciblée, soit qu'un bug caché a été activé à l'intérieur du code.
En même temps, l'architecte a réfuté les rumeurs sur la vulnérabilité de la blockchain aux points de défaillance uniques. Le réseau est entièrement décentralisé, donc l'arrêt ou la surcharge même d'un grand hub (y compris son propre nœud) n'a aucun effet sur l'opérabilité globale et la disponibilité de XRPL.
Comment le créateur du réseau s'est retrouvé sans journaux
Le principal problème pratique s'est avéré être la vulnérabilité des systèmes de surveillance du réseau pendant les pics de charge. Lorsque les tours de consensus ont ralenti, les validateurs sont brusquement passés à la charge maximale. Le propre nœud de Schwartz n'a pas pu supporter l'afflux de requêtes, ce qui a fait que les connexions RPC locales sont restées bloquées dans l'état CLOSE_WAIT.
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. Par conséquent, l'ingénieur a dû redémarrer le serveur sans comprendre la cause exacte de la défaillance.
Au cours de la discussion, il est apparu que le hub du co-créateur de XRPL envoyait des journaux vers un hôte de test obsolète de la XRP Ledger Foundation (XRPLF).
Actuellement, l'équipe d'ingénieurs et les opérateurs de la communauté analysent manuellement les journaux survivants pour isoler et éliminer complètement le défaut. Schwartz a résumé que, malgré la réduction temporaire des marges de sécurité, l'équipe n'a aucune raison de paniquer. Les développeurs contrôlent pleinement la situation, et l'architecture du code dispose d'une réserve technologique suffisante pour maintenir le réseau opérationnel.
