Eine Sicherheitsüberprüfung durch Sherlock identifizierte 96 Bugs im Code des XRP Ledger, bevor das Release die Nutzer erreichte – eine der umfangreichsten Vorab-Überprüfungen, die für die Software des Netzwerks berichtet wurden.

Was das Sherlock-Audit ergab

Das Audit wurde über Sherlocks kompetitive Überprüfungsplattform abgewickelt, die den Wettbewerb zur Prüfung der XRP-Ledger-Codebasis hostete. Bei diesem Modell untersuchen unabhängige Sicherheitsforscher eine Codebasis während eines definierten Prüfzeitfensters, wobei Probleme markiert werden, bevor der Code ausgeliefert wird. Die Überprüfung zielte auf die Kern-Software des Ledgers ab und nicht auf eine einzelne Anwendung. Dieser Kern ist rippled, die Open-Source-Server-Implementierung, die hauptsächlich in C++ geschrieben ist und die Validatoren und andere Server zum Betrieb des Netzwerks ausführen – das rückt markierte Probleme näher an das Fundament des Ledgers heran als Bugs, die auf eine einzelne Anwendung oder Wallet beschränkt sind.

Wettbewerbsbasierte Überprüfungen dieser Art, bei denen unabhängige Forscher mit verifizierten Ergebnissen um Auszahlungen konkurrieren, sind über Plattformen wie Sherlock und Code4rena zu einem festen Bestandteil der Smart-Contract-Sicherheit geworden. Eine solche Überprüfung der Knoten-Software eines großen Ledgers erweitert dasselbe Modell tiefer in den Stack – von Verträgen auf Anwendungsebene bis hin zu dem Code, der jede Transaktion verarbeitet.

Laut Berichterstattung traten dabei 96 Bugs zutage, bevor der Code an eine einzige Wallet ausgeliefert wurde. Die Zahl bezieht sich auf Probleme, die während des Prüfzeitfensters markiert wurden, und nicht auf bestätigte Exploits im Produktivbetrieb.

Das mit diesem Zyklus verbundene Release ist im eigenen Changelog des rippled-3.3.0-Updates des Netzwerks dokumentiert – die Version, die im Zentrum der geprüften Arbeit steht.

Warum es wichtig ist, die Bugs vor der Veröffentlichung zu finden

Mängel vor der Bereitstellung zu erkennen bedeutet, dass sie behoben werden können, während der Code noch in Überprüfung ist, und nicht erst, nachdem er live auf Validatoren und in den Wallets der Nutzer läuft. Dieses Timing ist der zentrale Wert eines Vorab-Audits.

Für einen auf Abwicklung ausgerichteten Ledger senkt die Entdeckung vor dem Release das Risiko, dass ein Defekt die Produktivumgebung erreicht, in der Gelder, die Transaktionsverarbeitung oder das Konsensverhalten beeinträchtigt werden könnten. Das Audit fungiert als Filter zwischen Entwicklung und Livetrieb. Die Tragweite ist bei Infrastruktur dieser Art besonders groß: Der XRP Ledger bestätigt Zahlungen über einen Einigungsprozess innerhalb seines Validatoren-Sets statt über Proof-of-Work-Mining, sodass Defekte, die die Transaktionsverarbeitung oder den Konsens berühren, in der Schicht liegen, auf die jeder Nutzer des Netzwerks angewiesen ist.

Das Operations-Team des XRP Ledger wies über seinen offiziellen Kanal auf X auf die Überprüfung hin und betonte, dass das Audit Teil des Release-Prozesses war und nicht eine Reaktion auf einen Vorfall.

Was dies für die künftige Aufsicht über den XRP Ledger bedeutet

Das Einbeziehen einer externen Überprüfung durch Dritte fügt über interne Tests hinaus eine weitere Prüfebene hinzu, und die gemeldete Bug-Anzahl zeigt, dass solche Überprüfungen selbst bei etablierter Infrastruktur noch ein erhebliches Volumen an Problemen zutage fördern.

Externe Audits sind in der Kryptobranche zu einem routinemäßigen Vertrauenssignal geworden, ähnlich wie Reserve-Bestätigungen die Debatte um die Deckung von Stablecoins prägten, als Tethers Big-Four-Audit meldete, dass die Reserven die Verbindlichkeiten überstiegen. Code-Überprüfung und finanzielle Bestätigung verfolgen dasselbe Ziel: überprüfbare Sicherheit für Nutzer.

Diese Frage der Sicherheit erstreckt sich auch auf Schutzmaßnahmen auf Wallet-Ebene, ein Bereich, der kürzlich deutlich wurde, als CyberWallet- und Passkey-Nutzer mit einer Unterbrechung von Abhebungen konfrontiert waren. Die Release-Reife auf Protokollebene und die Zuverlässigkeit auf Wallet-Ebene bestimmen gemeinsam, wie stark Nutzer sich auf ein Netzwerk verlassen können.

Die Details zu Schweregradstufen und dazu, wie die einzelnen Probleme behoben wurden, gingen aus der verfügbaren Berichterstattung nicht hervor; die Bedeutung liegt daher im Umfang der Überprüfung und deren Zeitpunkt vor dem Release und nicht in der spezifischen Natur einzelner Bugs. Zu beobachten ist künftig, ob eine Aufschlüsselung nach Schweregraden und Hinweise zur Behebung die Release-Dokumentation begleiten und ob Wettbewerbe von Drittanbietern fester Bestandteil der XRPL-Release-Zyklen werden.

Hinweis: Dieser Artikel dient ausschließlich Informationszwecken und stellt keine finanzielle oder Anlageberatung dar. Die Märkte für Kryptowährungen und digitale Vermögenswerte tragen erhebliche Risiken. Führen Sie vor Entscheidungen immer Ihre eigene Recherche durch.