Alle News durchlaufen eine strenge Faktenprüfung und werden von Blockchain-Experten sowie erfahrenen Brancheninsidern verfasst und redaktionell geprüft.
- RippleX hat einen als kritisch eingestuften Fehler im XRP Ledger-„Batch“-Amendment bestätigt.
- Als Reaktion kündigt RippleX strengere Sicherheitsprozesse an.
RippleX, der Entwicklerarm von Ripple, hat Stellung zu einer als kritisch eingestuften Schwachstelle im „Batch“-Amendment (XLS-56) des XRP Ledgers genommen und zugleich Konsequenzen für den Sicherheitsprozess angekündigt.
J. Ayo Akinyele, Head of Engineering bei RippleX, erklärte am Dienstag via X, dass der Fehler in der vergangenen Woche von Cantina AI entdeckt und als kritisch bestätigt worden sei. Wichtig sei gewesen, dass die Schwachstelle „im Mainnet nicht ausnutzbar“ war. Das Amendment wurde nicht aktiviert.
Als Sofortmaßnahme wurde ein Hotfix veröffentlicht, um sowohl XLS-56 als auch ein damit verbundenes Fix-Amendment zu deaktivieren, während eine umfassendere Korrektur implementiert und überprüft wird. Akinyele räumte aber ein, dass der Vorgang Fragen über die Kontrollmechanismen im Amendment-Prozess des XRP Ledgers aufwirft:
„Das Batch-Amendment ist weiter fortgeschritten, als es hätte sein sollen. Als aktive Teilnehmer am Lebenszyklus eines Amendments tragen wir Mitverantwortung dafür, dass Prüf-, Signalisierungs- und Aktivierungsschutzmechanismen höchsten Standards genügen. In diesem Fall müssen wir besser werden.“
Die Konsequenzen für Ripple und das XRP Ledger
Der Ripple-Entwickler betonte, dass der Amendment-Prozess selbst funktioniert habe. Laut Akinyele hat der standardisierte Prozess eine Aktivierung von XLS-56 auf dem Mainnet verhindert. Dennoch sei der Fehler zu spät ans Licht gekommen. „Diese Schutzmaßnahmen sind wichtig“, so Akinyele. „Aber sie sollten die letzte Verteidigungslinie sein, nicht die erste.“
Die zentrale Frage laut Akinyele ist deshalb, wie die Sicherheitsarchitektur rund um XRPL-Amendments verschärft werden muss. Akinyele betonte jedoch auch, dass Ripple nicht die alleinige Verantwortung tragen kann. Entwickler, Validatoren, die XRPL Foundation sowie externe Sicherheitsforscher müssten diese gemeinsam tragen:
„Keine einzelne Instanz kontrolliert die Aktivierung. Keine einzelne Instanz trägt das Risiko allein. Dies ist eine Folge der Dezentralisierung und eine Stärke, erfordert aber mehrschichtige Sicherheitsvorkehrungen. Validatoren sollten keine Auditoren sein […].“
Akinyele kündigte in diesem Zusammenhang mehrere Änderungen an. Künftig sollen Releases mit größerer Bedeutung mehrfach unabhängig auditiert werden, in Abstimmung mit der XRPL Foundation. Außerdem will das Unternehmen das Bug-Bounty-Programm ausweiten und Testkampagnen vor einer Aktivierung stärker formalisieren.
Besondere Aufmerksamkeit widmet Ripple dem Einsatz von KI in der Softwareentwicklung. Nach Angaben Akinyeles sollen KI-gestützte Code-Reviews, automatisierte Erkennung von Invarianten, agentische Fuzzing-Systeme und simulierte Angriffsszenarien Teil des Sicherheitsprozesses werden:
„KI ersetzt keine erfahrenen C++-Ingenieure. Aber sie ergänzt sie – gerade in Fällen, in denen subtile logische Wechselwirkungen an kritischen Stellen überproportionale Risiken erzeugen können.“
Parallel dazu arbeitet Ripple nach eigener Darstellung an formaler Verifikation für besonders risikoreiche Komponenten des Ledgers. Ziel sei es, Sicherheitseigenschaften kritischer Bausteine nachzuweisen, das Verhalten von Amendments vor der Aktivierung zu modellieren und Verifikationsanforderungen für konsenskritischen Code zu standardisieren.
