Forscher der Bank für Internationalen Zahlungsausgleich (BIS) haben den XRP Ledger (XRPL) in einem Proof of Concept zur Absicherung offizieller Statistiken eingesetzt. Kryptografische Fingerabdrücke sollen die Herkunft von Dateien bestätigen und nachträgliche Veränderungen erkennbar machen.

Der Prototyp lief ausschließlich im XRPL-Devnet. Es handelt sich aber weder um eine Mainnet-Einführung noch um eine Partnerschaft der BIS mit Ripple.

BIS-Forscher entscheiden sich für den XRP Ledger

Das am 2. September veröffentlichte BIS Working Paper Nr. 1374 untersucht, wie Zentralbanken, Statistikämter und internationale Organisationen ihre Daten unabhängig überprüfbar machen können.

Tipp der Redaktion: Ripple rüstet XRP gegen Quantencomputer: 4-Stufen-Plan soll Ledger schützen

Vier der fünf Autoren arbeiten für die BIS. Sie wählten den XRP Ledger wegen seiner niedrigen Gebühren, schnellen Finalität und verfügbaren Entwicklerressourcen. Die Architektur ist allerdings blockchainunabhängig und könnte später auf anderen Netzwerken eingesetzt werden.

BIS Working Papers geben zudem die Ansichten der Autoren und nicht zwangsläufig die offizielle Position der BIS oder ihrer Mitgliedszentralbanken wieder.

Internationale Institutionen verwenden SDMX als Standard für den Austausch statistischer Daten. Das Format besitzt bislang jedoch keine native Möglichkeit, die Herkunft und Unverändertheit einer Datei kryptografisch zu prüfen.

Der Prototyp normalisiert die Statistikdatei und erzeugt mit SHA3-512 Hashes für die gesamte Datei oder einzelne Daten. Mehrere Hashes werden über einen Merkle Tree zu einem Merkle Root zusammengeführt.

Dieser Root wird im Memo-Feld einer XRPL-Payment-Transaktion gespeichert. Im Beispiel versendet das System lediglich 10 Drops beziehungsweise 0,00001 XRP. Anschließend werden der Transaktions-Hash, der Merkle Root und die einzelnen Hashes wieder in die Statistikdatei eingefügt. Die Autoren beschreiben den Vorteil wie folgt:

„Ein Ledger-Eintrag kann Tausende Datensätze abdecken.“

Ein W3C Verifiable Credential verbindet die Daten zusätzlich mit der digitalen Identität des Herausgebers. Zur Kontrolle berechnet der Empfänger den Hash erneut und vergleicht ihn mit dem Onchain-Wert. Die eigentlichen Statistiken werden nicht auf dem XRP Ledger gespeichert.

BIS-Prototyp benötigt drei bis fünf Sekunden

Getestet wurde die öffentlich verfügbare Software auf einer Entwickler-Workstation mit synthetischen SDMX-Dateien zwischen 10 Kilobyte und 8 Megabyte. Die mediane Veröffentlichungsdauer lag bei drei bis fünf Sekunden. Eine Überprüfung benötigte ein bis zwei Sekunden. Als beobachtete Netzwerkgebühr nennt das Paper 10 Drops pro Transaktion.

Die Messwerte stammen allerdings aus dem Devnet. Es gab keine Mainnet-Belastungstests, Angriffe oder Prüfungen unter vollständigen Produktionsbedingungen. Entsprechend betonen die Autoren:

„Wir vermeiden bewusst den Begriff ‚produktionsreif‘.“

Auch das GitHub-Repository bezeichnet die Software als experimentellen, nicht gewarteten Prototyp.

Lesetipp: XRP-ETF-Investoren für Q2 2026 enthüllt: Goldman, Jane Street und Millennium führen

Vet schlägt NFT statt Memo-Transaktion vor

Das XRP-Ledger-Foundation-Mitglied Hussein „Vet“ Zangana hält die Nutzung des Memo-Feldes für verbesserungsfähig. Er schlägt vor, den Hash oder einen Verweis auf IPFS beziehungsweise Arweave in der URI eines XRPL-NFTs zu speichern:

„Meiner Meinung nach gibt es einen viel besseren Weg, dies zu erreichen: Man verwendet ein NFT. Sie erwähnen IPFS, aber man kann auch Arweave nutzen. Man bettet den Hash in die NFT-URI ein: Wer die Statistikdatei findet, kann den Hash berechnen und mit dem URI-Hash (der unveränderlich ist) abgleichen. Stimmen sie überein, weiß man, dass es sich um die korrekte, unveränderte Datei handelt.“

Der Einwand betrifft die langfristige Verfügbarkeit. Memos gehören zur Transaktionshistorie und setzen für spätere Abfragen einen Archivserver voraus. Ein NFT bleibt dagegen als Objekt im aktuellen Ledger-Zustand. Zangana erklärt:

„Weil NFTs Objekte im Ledger sind, während das Memo-Feld dies nicht ist. Wenn man also nicht die gesamte Ledger-Historie für immer speichern möchte, sollte man besser Objekte verwenden, da diese in jeden nachfolgenden Ledger-Zustand übernommen werden.“