Betreiber von Nodes, die das XRP Ledger ausführen, werden aufgefordert, schnell zu handeln. Ripples Director of Engineering, Vijay Khanna, drängte Infrastrukturbetreiber am 2. August, ein XRP-Ledger-Node-Upgrade auf xrpld Version 3.2.1 abzuschließen, nachdem Entwickler am 31. Juli eine Validator-Manifest-Flut im Netzwerk festgestellt hatten. Das Ledger produzierte während des gesamten Vorfalls weiterhin Blöcke, doch die Episode legte eine Schwachstelle in Bezug auf Ressourcenerschöpfung offen, die Ripple nun mit einem gezielten Hotfix geschlossen hat.
Summary
Wichtigste Erkenntnisse
- Eine Validator-Manifest-Flut am 31. Juli veranlasste Ripple dazu, xrpld 3.2.1 als Notfall-Hotfix zu veröffentlichen, der am 1. August publiziert wurde.
- Das XRP Ledger schloss während des gesamten Ereignisses die Ledgers weiterhin normal, ohne bestätigten Verlust von Geldern, veränderte Transaktionen oder Konsensfehler.
- Vier neue Schutzmechanismen begrenzen nun die Manifestgröße, die Größe von Nachrichtenbatches, das Wachstum des Caches für unbekannte Validator-Schlüssel und die ausgehende Weitergabe nicht vertrauenswürdiger Daten.
- Betreiber müssen ein Upgrade durchführen, bestätigen, dass xrpld läuft, und den Dienst dann ein zweites Mal neu starten, um alle Manifeste zu löschen, die vor dem Patch bestehen geblieben sind.
- Ripple hat seinen GPG-Schlüssel zur Paket-Signierung am 18. Februar rotiert, daher müssen Betreiber den neuen Schlüssel vertrauen, damit das Update korrekt installiert wird.
Was das XRP-Ledger-Node-Upgrade ausgelöst hat
Die Flut konzentrierte sich auf Validator-Manifeste, die kryptografisch signierten Datensätze, die die permanente Master-Identität eines Validators mit dem temporären Schlüssel verknüpfen, den er für den täglichen Validierungsverkehr verwendet. Wenn ein Validator diesen temporären Schlüssel rotiert, sendet er ein neues Manifest aus, das von seinem Master-Schlüssel signiert ist, damit Peers im gesamten Netzwerk die Legitimität der Änderung überprüfen können.
Vor dem Fix akzeptierten, zwischenspeicherten und verbreiteten Nodes Manifeste, die mit Validator-Schlüsseln verknüpft waren, die sie noch nie zuvor gesehen hatten, solange die Daten strukturell gültig waren. Das eröffnete eine Angriffsfläche: Jemand konnte eine große Anzahl unbekannter Identitäten erzeugen und jeden verbundenen Node dazu zwingen, Speicher, Speicherplatz, Bandbreite und Rechenleistung nur für die Verarbeitung dieses Rauschens zu verbrauchen. Der öffentliche Codeeintrag zu dem Vorfall beschreibt ihn als einen Fehler bei der Manifest-Weiterverbreitung und nicht als eine Kompromittierung eines Kontos oder Schlüssels.
Trotz des Drucks auf die Node-Ressourcen berichteten die XRP Ledger Operations, dass das Netzwerk während der gesamten Zeit die Ledgers weiterhin normal schloss. Dieser Unterschied ist wichtig: Die Flut belastete die Infrastruktur, erreichte aber nie den Punkt, an dem der Konsens gestört oder der Transaktionsverlauf beschädigt wurde.
Details zum xrpld-3.2.1-Hotfix
Ripples Reaktion, datiert auf den 31. Juli und als signierte Veröffentlichung früh am 1. August publiziert, umfasst sechs Commits über 13 geänderte Dateien, von denen vier direkt einschränken, wie Nodes Manifeste von nicht erkannten Validatoren behandeln. Zusammen bilden sie vier Schutzmechanismen, die verhindern sollen, dass eine ähnliche Flut erneut die Ressourcen von Nodes erschöpft.
Der erste weist ein übergroßes Manifest zurück, noch bevor ein Node dessen Dekodierung abgeschlossen hat, und schneidet so die Verarbeitungskosten für ungewöhnlich große Objekte bereits an der Tür ab. Der zweite begrenzt, wie viele nicht vertrauenswürdige Manifeste in einer einzelnen Netzwerk-Nachricht transportiert werden können, unabhängig davon, ob ein Node Daten empfängt oder sie für Peers vorbereitet; übergroße Batches werden verworfen, ohne die Verbindung automatisch zu trennen, was es gepatchten und ungepatchten Nodes ermöglicht, während der Einführung weiterhin miteinander zu kommunizieren.
Eine dritte Änderung begrenzt, wie viele unbekannte Validator-Identitäten der Manifest-Cache eines Nodes halten kann, wobei der endgültige Code diese Obergrenze auf 100 festlegt. Sobald der Cache voll ist, werden neue, nicht gelistete Schlüssel abgewiesen, während vertrauenswürdige und zuvor erkannte Validatoren ohne Unterbrechung weiterarbeiten. Die vierte Anpassung ändert, wie sich nicht vertrauenswürdige Manifestdaten im Netzwerk verbreiten, indem die ausgehende Weitergabe von nicht gelisteten Peer-Gerüchten eingeschränkt wird, während Daten, die mit konfigurierten oder genehmigten Validatoren verknüpft sind, unberührt bleiben. Dieses Gleichgewicht ist beabsichtigt: Die normale Rotation von Validator-Schlüsseln funktioniert weiterhin, aber ein unkontrolliertes Cache-Wachstum durch Fremde nicht.
Was Node-Betreiber jetzt tun müssen
Khannas Anleitung ist unkompliziert, muss aber in der richtigen Reihenfolge befolgt werden. Betreiber sollten das Standardupdate installieren, ein bis zwei Minuten warten, bestätigen, dass xrpld tatsächlich läuft, und dann den Dienst ein zweites Mal neu starten.
Dieser zweite Neustart ist keine Formalität. Alle Manifeste, die der Node eines Betreibers vor dem Patch aufgenommen und gespeichert hat, könnten sich noch im Speicher oder auf der Festplatte befinden. Die Installation von 3.2.1 ändert, wie die Software neue Manifeste künftig behandelt, aber nur ein frischer Neustart löscht Daten, die der Node aufgenommen hat, während er noch verwundbar war. Das Überspringen dieses Schritts birgt das Risiko, veraltete, nicht vertrauenswürdige Manifeste beizubehalten, selbst nachdem der Code selbst korrigiert wurde.
Es gibt einen zweiten, erwähnenswerten Aspekt: Paketvertrauen. Ripple hat den GPG-Schlüssel, mit dem xrpld-Pakete signiert werden, bereits am 18. Februar rotiert, und Installationen, die diesen Ersatzschlüssel noch nicht als vertrauenswürdig eingestuft haben, ziehen das Update möglicherweise nicht automatisch. Jeder, der XRPL-Infrastruktur verwaltet, sollte seine Konfiguration des Signierschlüssels überprüfen, bevor er davon ausgeht, dass das Upgrade reibungslos angewendet wird.
Wichtig ist, dass dieses XRP-Ledger-Node-Upgrade eindeutig auf die Infrastruktur und nicht auf einzelne Inhaber abzielt. Börsen, Verwahrer, Wallet-Backends, Datenanbieter und jedes Unternehmen, das eigene XRPL-Server betreibt, müssen ihre Node-Version und den Neustatus bestätigen. Normale XRP-Inhaber müssen aufgrund dieses Problems keine Gelder bewegen, Wallet-Schlüssel ändern oder neue Konten eröffnen – der Fix befindet sich vollständig auf der Serverebene.
Warum der fehlende Schaden trotzdem wichtig ist
Im Zusammenhang mit der Flut wurde keine CVE-Kennung oder Schätzung finanzieller Verluste veröffentlicht, und die verfügbaren Hinweise deuten auf belastete Node-Ressourcen und Peer-to-Peer-Verkehr hin, nicht auf bestätigten Diebstahl, veränderte Transaktionen oder einen Konsenszusammenbruch. Das ist ein wirklich beruhigendes Ergebnis für ein Netzwerk, das Werte in Milliardenhöhe abwickelt, bedeutet aber nicht, dass der Vorfall kostenfrei war. Angriffe zur Ressourcenerschöpfung, die keine Gelder berühren, können den Dienst dennoch beeinträchtigen, Infrastrukturbetreiber verlangsamen und Angriffsflächen für Folgeversuche schaffen, wenn Patches verzögert eingespielt werden.
Genau dieser Teil fehlt noch in der öffentlichen Dokumentation. XRP Ledger Operations haben angekündigt, dass eine technische Nachanalyse folgen wird, doch bis zum 2. August war dieser Bericht noch nicht veröffentlicht. Bis dahin bleiben die Identität der Person, die die Flut ausgelöst hat, das tatsächliche Volumen der beteiligten Manifeste und die Geschwindigkeit, mit der Node-Betreiber im gesamten Netzwerk 3.2.1 übernommen haben, offene Fragen. Es wird außerdem erwartet, dass der Bericht klarstellt, wann Entwickler den ungewöhnlichen Traffic erstmals entdeckt haben und ob einzelne Nodes zeitweise nicht erreichbar waren, obwohl das gemeinsame Ledger selbst nie aufgehört hat, Blöcke zu produzieren.
Dies ist nicht der erste erzwungene Softwarewechsel des Netzwerks in diesem Jahr. Der 3.2.1-Hotfix folgt auf die größere 3.2.0-Einführung am 15. Juni, die den Referenzserver von rippled in xrpld umbenannte und eine eigene Runde von Konfigurationsupdates erforderte – dieselbe Veröffentlichung, die den XRPL-Infrastrukturbetreiber David Schwartz dazu veranlasste, sein Setup im Vorfeld der neuen Namens- und Protokolländerungen zu migrieren. Node-Betreiber mussten außerdem eine frühere 3.1.3-Frist im Zusammenhang mit einer Amendment-Aktivierung einhalten. Zusammengenommen deutet das Muster darauf hin, dass die Infrastrukturschicht von XRPL angehalten ist, mit einem sich verdichtenden Update-Zyklus Schritt zu halten, und Betreiber, die bei einer einzelnen Veröffentlichung zurückfallen, riskieren, Schwachstellen weiterzutragen, die das Netzwerk an anderer Stelle bereits behoben hat.
FAQ
Was machte das XRP-Ledger-Node-Upgrade notwendig?
Am 31. Juli kam es zu einer Validator-Manifest-Flut, die zu einer Ressourcenerschöpfung auf Nodes führte und den xrpld-3.2.1-Hotfix erforderlich machte, um das Problem zu entschärfen.
Führte die Manifest-Flut zu verlorenen Geldern oder Konsensfehlern im XRP Ledger?
Es wurden während der Flut keine bestätigten finanziellen Verluste, veränderten Transaktionen oder Ledger-Konsensfehler beobachtet, so die XRP Ledger Operations.
Was sind die wichtigsten Schutzmechanismen, die in xrpld 3.2.1 eingeführt wurden?
Das Update begrenzt die Manifestgröße, die Größe von Nachrichtenbatches, das Wachstum des Caches für unbekannte Schlüssel (begrenzt auf 100 Einträge) und die ausgehende Weitergabe nicht vertrauenswürdiger Manifeste.
Wer muss auf xrpld 3.2.1 upgraden und wie lauten die operativen Schritte?
Infrastrukturbetreiber, die XRPL-Nodes betreiben – einschließlich Börsen, Verwahrern und Wallet-Betreibern – müssen ein Upgrade durchführen, verifizieren, dass die Software läuft, und dann einen zweiten Neustart durchführen, um alle verbliebenen Manifeste zu löschen.
{„@context“:“https://schema.org“,“@type“:“FAQPage“,“mainEntity“:[{„@type“:“Question“,“name“:“Was machte das XRP-Ledger-Node-Upgrade notwendig?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Am 31. Juli kam es zu einer Validator-Manifest-Flut, die zu einer Ressourcenerschöpfung auf Nodes führte und den xrpld-3.2.1-Hotfix erforderlich machte, um das Problem zu entschärfen.“}},{„@type“:“Question“,“name“:“Führte die Manifest-Flut zu verlorenen Geldern oder Konsensfehlern im XRP Ledger?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Es wurden während der Flut keine bestätigten finanziellen Verluste, veränderten Transaktionen oder Ledger-Konsensfehler beobachtet, so die XRP Ledger Operations.“}},{„@type“:“Question“,“name“:“Was sind die wichtigsten Schutzmechanismen, die in xrpld 3.2.1 eingeführt wurden?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Das Update begrenzt die Manifestgröße, die Größe von Nachrichtenbatches, das Wachstum des Caches für unbekannte Schlüssel (begrenzt auf 100 Einträge) und die ausgehende Weitergabe nicht vertrauenswürdiger Manifeste.“}},{„@type“:“Question“,“name“:“Wer muss auf xrpld 3.2.1 upgraden und wie lauten die operativen Schritte?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Infrastrukturbetreiber, die XRPL-Nodes betreiben – einschließlich Börsen, Verwahrern und Wallet-Betreibern – müssen ein Upgrade durchführen, verifizieren, dass die Software läuft, und dann einen zweiten Neustart durchführen, um alle verbliebenen Manifeste zu löschen.“}}]}
Artikel mit Unterstützung künstlicher Intelligenz erstellt und von der Redaktion überprüft.
