Vier Chains, eine Woche, eine Regel: Ein lauter Fehler schlägt eine stille Abweichung

Victoria Shinder11 October 2026, 09:393 Min. Lesezeit

Vier voneinander unabhängige Projekte haben zwischen dem 7. und 9. Oktober Änderungen veröffentlicht. Nebeneinander gelesen machen sie denselben Tausch.

XRP Ledger: eine Summe, die überlief. Der Bericht vom 9. Oktober erklärt, dass die Payment-Engine aufaddierte, was eine Zahlung über viele Angebote schuldete; eine genügend große Summe lief über und wurde zu einer kleinen Zahl, statt einen Fehler auszulösen. Der Fix macht den Überlauf zum Fehler. Ebenso offen benennt der Bericht den verfahrensmäßigen Preis: Die Änderung ging am Amendment-Prozess vorbei live und nahm ein Fenster in Kauf, in dem aktualisierte und nicht aktualisierte Server uneins sein konnten – weil ein stilles Erzeugen neuer XRP schlimmer erschien als ein möglicher Netzstillstand.

Sei: eine Einstellung, die einen Knoten abdriften ließ. In v6.7.1 vom 8. Oktober galt bisher: Passte der festgelegte Schreibmodus nicht zum Migrationsstand auf der Platte, startete der Knoten und wich dann vom Netz ab. Jetzt verweigert er den Start. Der Betreiber bekommt einen Ausfall statt eines Knotens, der gesund aussieht und falschen Zustand ausliefert.

Solana: ein Upgrade, gebunden an eine Adresse statt an Bytes. SIMD-0690 vom 7. Oktober stellt fest, dass die Migration eines Kernprogramms von Loader v2 auf v3 dem vertraut, was bei Aktivierung in einem Buffer-Konto liegt. Der Vorschlag ergänzt einen vorab festgelegten SHA-256-Hash; bei Abweichung bricht die Migration ab, das alte Programm bleibt. Aus einem falschen Upgrade wird kein Upgrade.

Bitcoin Core: ein Bereich, den die Wallet nicht fassen konnte. Pull Request 35989, gemergt am 8. Oktober, lässt importdescriptors einen Bereich bis 2^31-1 ablehnen, der zuvor in der Wallet negativ wurde und den Knoten beim Auffüllen des Keypools abstürzen ließ. Aus einem Absturz tief in einer Hintergrundaufgabe wird ein Fehler im Moment des Aufrufs – und, wie ein Reviewer anmerkte, eine Verhaltensänderung mit Release Note, weil gestern akzeptierte Eingaben heute scheitern.

Das gemeinsame Muster. Jedes Mal nahm der ursprüngliche Code etwas an, das er nicht darstellen oder prüfen konnte, und machte weiter. Die Fixes verlegen den Fehler früher und näher an die Ursache: an den Start, an den RPC-Aufruf, an den Moment der Aktivierung, an die Arithmetik. Das ist das klassische Fail-fast-Prinzip, und bei verteilten Ledgern wiegt es schwerer als bei gewöhnlicher Software, weil eine stille Abweichung nicht lokal bleibt. Ein Knoten mit falschem Zustand gibt allen falsche Antworten, die ihn fragen; eine Zahlung, die Wert erzeugt, lässt sich nicht still rückgängig machen.

Auch der Preis ist derselbe. Jede dieser Änderungen bricht etwas, das bisher funktionierte. Sei-Betreiber mit festgelegtem Modus sehen Knoten, die nicht starten. Software, die extreme Descriptor-Bereiche erzeugt hat, bekommt Fehler. Eine Solana-Migration mit unpassendem Buffer findet schlicht nicht statt. Und der XRPL-Fix nahm bewusst ein kurzes Risiko der Uneinigkeit im Netz in Kauf. In allen vier Fällen haben die Projekte diesen Preis in der Änderung selbst dokumentiert – Release Notes, Sicherheitsabschnitt eines SIMD, Zeitleiste eines Berichts –, statt ihn die Betreiber selbst entdecken zu lassen.

Für Leser, die Knoten betreiben, lautet die praktische Lehre dieser Woche: Upgrade-Notes nach dem Wort refuses ebenso aufmerksam lesen wie nach fixes. Das Verhalten, das einen jetzt stoppt, war in jedem dieser Fälle genau das Verhalten, das früher ein Problem verdeckte.

Quellen: XRPL.org, Vulnerability Disclosure Report, 9. Oktober 2026 — https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009 ; Sei v6.7.1 — https://github.com/sei-protocol/sei-chain/releases/tag/v6.7.1 ; SIMD-0690 — https://github.com/solana-foundation/solana-improvement-documents/pull/690 ; Bitcoin Core PR 35989 — https://github.com/bitcoin/bitcoin/pull/35989