Der XRP Ledger hat die xrpld-Version 3.2.1 veröffentlicht – einen Produktions-Hotfix, der darauf abzielt, Validator-Manifest-Flooding zu stoppen, das am 31. Juli 2026 Teile der Peer-to-Peer-Infrastruktur des Netzwerks belastete. xrpld ist die Referenz-Server-Software, die von Teilnehmern betrieben wird, um Knoten und Validatoren auf dem XRPL zu betreiben. Die Blockchain schloss ohne Unterbrechung weiter Ledgers ab und bestätigte damit, dass der Konsens vollständig funktionsfähig blieb, auch als einzelne Knoten außergewöhnliche Datenlasten verzeichneten.

XRP Ledger Operations kündigte das Release über sein offizielles X-Konto an:

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

Knotenadministratoren wurden angewiesen, den Hotfix unverzüglich zu installieren und kurz nach der erstmaligen Installation einen zweiten Neustart durchzuführen. Das aktualisierte Build führt Kontrollmechanismen ein, die verhindern, dass nicht vertrauenswürdige Validatordaten unverhältnismäßige Mengen an Speicher, Bandbreite, Speicherplatz und Rechenleistung beanspruchen.

Wie das Manifest-Flooding die XRPL-Peer-Infrastruktur belastete

Der XRPL verfügt über eine Gruppe von Validatoren, die jeder Betreiber über eine Unique Node List (UNL) als vertrauenswürdig einstuft. Nur Validatoren auf der UNL eines Knotens nehmen direkt an den Konsensentscheidungen dieses Knotens teil. Validator-Manifeste verknüpfen die permanente Master-Identität eines Validators mit dem temporären Signaturschlüssel, der während der Konsensrunden verwendet wird. Diese Architektur ermöglicht es Betreibern, Arbeitsschlüssel regelmäßig zu rotieren, während die Master-Anmeldedaten offline bleiben und die etablierte Netzwerkidentität des Validators erhalten bleibt.

Frühere xrpld-Versionen hatten keine Begrenzung für die Anzahl von Manifesten, die mit unbekannten Validatorschlüsseln verknüpft waren und die ein Knoten akzeptieren, speichern und weiterleiten konnte. Da jeder Knoten Manifestdaten an seine verbundenen Peers weiterleitete – unabhängig vom Vertrauensstatus –, verbreitete sich ein Übermaß an nicht vertrauenswürdigen Daten im Netzwerk und sammelte sich in lokalen Caches an.

Der Vorfall betraf die Nachrichtenweitergabe auf der Peer-Ebene und nicht Kontostände, einzelne Transaktionen oder Ledger-Validierungsregeln. Diese Unterscheidung ist für die Blockchain-Architektur allgemein bedeutsam: Fehler auf der Konsensebene können eine Chain zum Stillstand bringen, während Fehler auf der Peer-Ebene die Konnektivität beeinträchtigen, ohne die Ledger-Integrität zu gefährden. Obwohl der XRPL weiterhin Transaktionen verarbeitete und pünktlich Ledgers abschloss, verschlechterte die Belastung der Peer-Verbindungen die Konnektivität und verlangsamte die Informationsverteilung im Netzwerk.

Vier Schutzmaßnahmen in Version 3.2.1

Version 3.2.1 führt sechs Commits ein, die 13 Dateien umfassen. Die Änderungen implementieren Kontrollen an vier kritischen Punkten, an denen übermäßiger oder wiederholter Manifest-Datenverkehr einen Knoten belasten könnte:

1. Größenbegrenzung vor dem Dekodieren. xrpld weist nun einzelne Manifeste zurück, die die erwartete kodierte Größe überschreiten, bevor der Dekodierungsprozess beginnt, wodurch verhindert wird, dass übergroße Eingaben unnötige Rechenarbeit auslösen.

2. Verwerfen nicht vertrauenswürdiger Batches. Knoten verwerfen nun eingehende Batches, die eine übermäßige Anzahl nicht vertrauenswürdiger Manifeste enthalten. Dabei vermeidet die Software es, ältere Peers, die übergroße Batches übermitteln, automatisch zu trennen, was das Risiko einer Netzwerkfragmentierung während des Upgrade-Zeitraums verringert.

3. Peer-Greeting-Begrenzungen. Der Hotfix beschränkt den Massen-Manifest-Greeting, der ausgetauscht wird, wenn zwei Knoten eine neue Peer-Verbindung herstellen. Vertrauenswürdige Datensätze bleiben vollständig verfügbar, während nicht vertrauenswürdiger Gossip sowohl auf dem Sende- als auch auf dem Empfangspfad eingeschränkt wird.

4. Speicherbegrenzung für unbekannte Schlüssel. Jeder Knoten kann maximal 100 Manifeste speichern, die mit unbekannten Validatorschlüsseln verknüpft sind. Sobald diese Obergrenze erreicht ist, werden weitere Einträge abgewiesen, und nicht vertrauenswürdige Manifeste werden nicht mehr auf der Festplatte gespeichert.

Erforderlicher zweiter Neustart und Verifizierung des Signaturschlüssels

Nach der Installation des Updates wurden Administratoren angewiesen, ungefähr ein bis zwei Minuten zu warten und zu bestätigen, dass xrpld weiterhin funktionierte. Eine vollständige Synchronisation ist nicht erforderlich, bevor mit dem nächsten Schritt fortgefahren wird.

Sobald bestätigt ist, dass der aktualisierte Dienst läuft, müssen Betreiber xrpld ein zweites Mal neu starten. Das Betriebsteam bezeichnete diesen zweiten Neustart als einen wesentlichen letzten Schritt des Upgrade-Verfahrens.

Administratoren, die Paketinstallationen verwenden, sollten außerdem den aktuellen Softwaresignaturschlüssel von Ripple verifizieren. Ripple rotierte den GPG-Schlüssel, der zum Signieren von xrpld-Paketen verwendet wird, im Februar 2026. Das bedeutet, dass Systeme, die den Ersatzschlüssel noch nicht als vertrauenswürdig eingestuft haben, möglicherweise keine automatischen Upgrades erhalten.

Der Hotfix führt kein Netzwerk-Amendment ein und ändert keine Transaktionsverarbeitungsregeln. Stattdessen etabliert er feste Grenzen für nicht vertrauenswürdige Peer-Daten in jeder Phase – vor dem Dekodieren, Weiterleiten, Zwischenspeichern oder der dauerhaften Speicherung. Durch die Begrenzung von Manifestgröße, Batch-Volumen, Verbindungs-Greetings und der Speicherung unbekannter Schlüssel hat der XRP Ledger die vier Ausnutzungspfade geschlossen, die beim Flooding vom 31. Juli verwendet wurden. Der Vorfall zeigte, dass Peer-Ebene-Missbrauch einzelne Server belasten kann, selbst während der Konsens normal weiterfunktioniert – eine Art von Schwachstelle, die auch andere Blockchain-Netzwerke durch Härtung des Peer-Protokolls angegangen sind.

Ein vollständiger Post-Mortem-Bericht wird voraussichtlich der Community zur Verfügung gestellt.