Ein technischer Fehler im XRP Ledger (XRPL)-Netzwerk, der die Transaktionsverarbeitung verlangsamte, hat sich zu einer offenen Analyse der Architektur des Protokolls entwickelt. David Schwartz, ehemaliger Chief Technology Officer von Ripple und Mitentwickler des Systems, benannte öffentlich die verwundbaren Stellen der Blockchain, die durch den Vorfall hervorgehoben wurden.
Die Probleme begannen, nachdem das XRP Ledger Operations-Team eine Anomalie festgestellt hatte: Die Ledger des Netzwerks begannen, deutlich langsamer als üblich zu schließen. Während die Ingenieure nach der Ursache für die Verzögerungen suchten, kamen in der Community Fragen zur Zuverlässigkeit des dezentralen Systems auf. Die Nutzer waren besorgt darüber, ob das Netzwerk aufgrund der Überlastung mehrerer wichtiger Knotenpunkte ausfallen könnte. Schwartz schaltete sich in die Diskussion ein, um die tatsächlichen Grenzen der Widerstandsfähigkeit von XRPL zu erklären.
Nach Schwartz' Einschätzung ist die XRP Ledger-Software durch ein mehrschichtiges Sicherheitssystem geschützt. Dennoch gibt es theoretisch nur zwei Szenarien, die das gesamte Netzwerk vollständig lahmlegen könnten:
Massenhafter Infrastrukturausfall: eine Situation, in der eine enorme Anzahl von Validator-Servern auf der ganzen Welt gleichzeitig ausfällt. Ein solches Ergebnis ist nur im Falle einer globalen Naturkatastrophe möglich, weshalb die Entwickler es für unwahrscheinlich halten.
Ausfall des Konsensalgorithmus: ein Fehler im eigentlichen Mechanismus zur Erzielung einer Einigung zwischen den Knoten oder der Ausfall einer anderen grundlegenden Protokollfunktion auf der Code-Ebene.
Die festgestellte Verlangsamung der Runden ist ein direkter Beweis dafür, dass die technologischen Sicherheitsmargen des Systems abgenommen haben. Schwartz räumte ein, dass dies ein Marker dafür ist, dass das Netzwerk entweder unter einem gezielten Angriff steht oder ein versteckter Fehler im Code aktiviert wurde.
Gleichzeitig widerlegte der Architekt Gerüchte über die Anfälligkeit der Blockchain für einzelne Ausfallpunkte. Das Netzwerk ist vollständig dezentralisiert, sodass das Abschalten oder Überlasten selbst eines großen Knotenpunkts (einschließlich seines eigenen Knotens) keine Auswirkung auf die allgemeine Funktionsfähigkeit und Verfügbarkeit von XRPL hat.
Wie der Schöpfer des Netzwerks ohne Logs zurückblieb
Das Hauptproblem in der Praxis erwies sich als die Anfälligkeit der Netzwerküberwachungssysteme bei Spitzenlasten. Als sich die Konsensrunden verlangsamten, wechselten die Validatoren abrupt zur maximalen Last. Schwartz' eigener Knoten konnte dem Ansturm von Anfragen nicht standhalten, wodurch lokale RPC-Verbindungen im Zustand CLOSE_WAIT hängen blieben.
Aufgrund dieses Hängens war Schwartz' internes Überwachungssystem nicht in der Lage, im kritischsten Moment Diagnosedaten aufzuzeichnen und zu übertragen. Infolgedessen musste der Ingenieur den Server neu starten, ohne die genaue Ursache des Fehlers zu kennen.
Während der Diskussion stellte sich heraus, dass der Knotenpunkt des XRPL-Mitentwicklers Logs an einen veralteten Test-Host der XRP Ledger Foundation (XRPLF) sendete.
Derzeit analysiert das Team von Ingenieuren und Community-Betreibern manuell die erhaltenen Logs, um den Defekt zu isolieren und vollständig zu beseitigen. Schwartz fasste zusammen, dass das Team trotz der vorübergehenden Verringerung der Sicherheitsmargen keinen Grund zur Panik hat. Die Entwickler haben die Situation vollständig unter Kontrolle, und die Codearchitektur verfügt über ausreichende technologische Reserven, um das Netzwerk betriebsbereit zu halten.
