rippled übernimmt Teile 4–9 einer 28-teiligen Reihe gegen ungültige Daten beim Ledger-Abruf
Serguey Asael Shinder3 Min. LesezeitDer XRP-Ledger-Server rippled hat am 15. und 16. Oktober 2026 sechs Pull Requests übernommen, die die Teile 4 bis 9 einer 28-teiligen Reihe bilden. Es geht darum, wie ein Knoten Ledger aus dem lokalen Speicher und von Peers bezieht und was er tut, wenn die empfangenen Daten nicht zu dem angefragten Ledger gehören können. Die Branch-Namen der Reihe tragen das Präfix bthomee/shamap-invalid. Jeder Pull Request beschreibt seinen eigenen Umfang; zusammen führen sie ein einziges Urteil ein und setzen es durch: Eine Map, deren Ungültigkeit bewiesen ist, bleibt ungültig.
Schnell scheitern statt auf den Timeout warten (#8082, Teil 4). Findet tryDB() einen Header, der nie erfüllbar ist – ein Hash oder eine Sequenznummer passt nicht zur Anfrage, oder der Account-Hash ist null –, setzte der Abruf zwar schon ein Fehler-Flag, an zwei von drei Einstiegspunkten erfuhr davon aber niemand. Jetzt rufen init() und trigger() done() auf; wer auf den Abruf wartet, wird benachrichtigt, und der Hash landet in recentFailures_. Laut Pull Request verhindert das, dass die nächste Runde dasselbe aussichtslose Ledger erneut anfragt, statt es auslaufen zu lassen.
Null-Account-Hash auf beiden Wegen geprüft (#8476, Teil 5). Kein Ledger hat eine leere Zustands-Map, ein Header mit Account-Hash null kann also kein Ledger bezeichnen. InboundLedger weist ihn jetzt gleich ab, ob er aus der lokalen Datenbank oder von einem Peer kommt – über eine gemeinsame Hilfsfunktion und bevor irgendein Header-Zustand veröffentlicht wird. Im Peer-Fall gilt der Header als der angefragte, der Peer wird nicht beschuldigt.
Datenrennen im Sync-Pfad (#8083, Teil 6). Vier Felder, die ein Hintergrund-Thread für den Ledger-Abruf gleichzeitig mit dem steuernden Thread liest und schreibt – state_, full_, ledgerSeq_ und fullBelowGen_ –, werden zu std::atomic. Laut Pull Request schließt das Rennen, die ThreadSanitizer heute beobachten kann; statische Zusicherungen halten das gepackte Layout von SHAMapInnerNode bytegleich.
Schlechte Daten beim Namen nennen (#8084, Teil 7). SHAMap::addKnownNode() meldet jetzt invalid() statt nur „nicht nützlich“ für zwei Knoten, die beweisen, dass der angefragte Root-Hash unmöglich ist: einen inneren Knoten auf der Tiefe, die nur einem Blatt zusteht, und einen Knoten, dessen ID nicht zu der Stelle passt, an der der Abstieg endete. Die Tiefenprüfung rückt vor den Full-Below-Cache, der nach Hash indiziert und zwischen Maps geteilt ist, sodass ein Cache-Eintrag einer fremden Map das Urteil nicht kippen kann.
Keine unveränderlichen ungültigen Ledger (#8085, Teil 8). SHAMap::setImmutable() sowie Ledger::setImmutable()/setAccepted() liefern jetzt ein [[nodiscard]] bool und verweigern den Erfolg bei einer Map oder einem Ledger, deren Ungültigkeit bereits bewiesen ist; alle 14 Aufrufstellen werten das Ergebnis aus. Zustandswechsel laufen über ein Compare-Exchange, das Invalid nicht verlässt. Der Autor räumt ein, dass der Schutz nach bestem Bemühen wirkt: Ein Durchlauf, der das Urteil erst erreicht, nachdem beide Maps festgelegt sind, verkleinert das Zeitfenster, schließt es aber nicht.
Den Durchlauf stoppen (#8086, Teil 9). SHAMap::getMissingNodes() markiert die Map als ungültig und bricht den Abstieg ab, sobald eine nur Blättern vorbehaltene Position erreicht ist; Aufrufer müssen isValid() erneut prüfen, bevor sie ein leeres Ergebnis als „nichts mehr zu holen“ lesen. Derselbe Pull Request ergänzt Compile-Defines je Sanitizer (XRPL_ASAN, XRPL_TSAN, XRPL_UBSAN).
Jeder Teil versteht sich als interne Korrektheitsänderung; Teil 4 hält ausdrücklich fest, dass er weder libxrpl noch die öffentliche API oder das Peer-Protokoll berührt.
Quelle: XRPLF/rippled, Pull Requests #8082, #8476, #8083, #8084, #8085 und #8086 — https://github.com/XRPLF/rippled/pull/8085