Durchsatz-Behauptungen zu XRP-Ledger-RPC-Nodes stehen auf dem Prüfstand – verifizierte Benchmarks erzählen eine andere Geschichte
Wichtige Erkenntnisse
- •Verifizierte Benchmarks stützen nicht die virale Behauptung, XRPL-RPC-Nodes würden 30.000 Nachrichten pro Sekunde verarbeiten.
- •Öffentliche XRPL-Server-Cluster haben in Spitzenzeiten über 10.000 Lesezugriffe pro Sekunde bewältigt; die Produktions-Transaktionsrate lag historisch zwischen 100 und 230 TPS.
- •Der öffentliche Endpunkt von XRPL Labs weist eine p50-Latenz von etwa 371 Millisekunden für ledger_current-Aufrufe auf – die niedrigste unter öffentlichen XRPL-Servern.
- •Validator-Nachrichtenverkehr erreichte in optimalen Tests durchschnittlich rund 3.260 Nachrichten pro Sekunde, doch Konsensverkehr ist nicht mit Client-Server-RPC-Anfragen vergleichbar.
- •Da der native AMM auf der Mainnet läuft und eine EVM-kompatible Sidechain in Entwicklung ist, wird die Nachfrage an XRPL-RPC-Infrastruktur voraussichtlich steigen – dokumentierte Latenz-Benchmarks sind dann relevanter als virale Durchsatzbehauptungen.

Die in sozialen Medien kursierende Behauptung, XRP-Ledger-RPC-Nodes könnten 30.000 Nachrichten pro Sekunde verarbeiten, klingt beeindruckend. Das Problem: Verifizierte Benchmarks stützen diese Zahl nicht. Es ist ein Muster, das sich in gesamten Blockchain-Ökosystemen zeigt – durchschlagende Durchsatzzahlen verbreiten sich losgelöst von ihren ursprünglichen Testbedingungen, häufig Labor-Messungen, interne Nachrichten-Zählungen oder optimistische Prognosen – und werden dann als Produktionsfähigkeiten wiederholt.
Was die tatsächlichen Zahlen zeigen
XRPL Labs, einer der wichtigsten Infrastrukturentwickler des XRP Ledger, hat sich auf Latenz statt auf reinen Nachrichtendurchsatz konzentriert. Der öffentliche Endpunkt weist derzeit eine p50-Latenz von rund 371 Millisekunden für ledger_current-Aufrufe auf und ist damit die Option mit der niedrigsten Latenz unter den öffentlichen XRPL-Servern.
Öffentliche Server-Cluster wurden beobachtet, wie sie in Spitzenlastzeiten über 10.000 Lesezugriffe pro Sekunde verarbeiteten. Das ist eine solide Zahl für Blockchain-Infrastruktur, aber nur ein Drittel der behaupteten 30.000.
GetBlock, ein weiterer Infrastrukturanbieter, gibt an, dass seine XRPL-Nodes auf dedizierten Umgebungen über 1.000 Anfragen pro Sekunde ohne Ratenbegrenzung verarbeiten können.
Am nächsten an der Schlagzeilen-Zahl kommt man mit Validator-Nachrichtenverkehr, einer grundlegend anderen Verkehrskategorie. Die Verarbeitung von Validator-Nachrichten erreichte unter optimalen Testbedingungen Durchschnittswerte von etwa 3.260 Nachrichten pro Sekunde, mit Spitzen über 6.100 Nachrichten pro Sekunde. Validator-zu-Validator-Konsensverkehr und Client-Server-RPC-Anfragen sind jedoch nicht vergleichbar.
In Produktionsumgebungen lag die tatsächliche Transaktionsrate des XRPL-Netzwerks historisch zwischen 100 und 230 Transaktionen pro Sekunde bei täglichen Spitzen. Theoretische Maxima in kontrollierten Testumgebungen erreichten über 1.500 TPS – immer noch eine Größenordnung unter der zitierten Zahl von 30.000.
Warum diese Lücke wichtig ist
Die Unterscheidung zwischen Nachrichten pro Sekunde und Transaktionen pro Sekunde ist entscheidend. Ein RPC-Node kann Tausende von Leseanfragen verarbeiten – Kontostandsabfragen, Ledger-Abfragen, Abonnement-Updates –, die nie zu einer Transaktion im Ledger führen. Die Zählung aller eingehenden Nachrichten, einschließlich Pings, Statusprüfungen und fehlgeschlagener Anfragen, liefert stets eine größere Zahl als die Zählung tatsächlich verarbeiteter Transaktionen.
Für XRP ist das specifically relevant, weil Ripple das XRPL als Infrastruktur für institutionelle Zahlungsabwicklung und dezentralen Börsenhandel positioniert. Beide Anwendungsfälle erfordern vorhersehbare, überprüfbare Leistung unter anhaltender Last – keine theoretischen Spitzenwerte aus Laborbedingungen. Auch für Entwickler bei der Infrastrukturwahl ist es relevant: Kapazitätsplanung auf Basis überhöhter Zahlen führt zu unterdimensionierten Systemen und Ausfällen bei Lastspitzen.
Wohin sich die XRPL-Infrastruktur tatsächlich entwickelt
Die p50-Latenz von 371 ms stellt einen bedeutsamen Fortschritt für ein dezentrales Netzwerk dar, das bei jeder Anfrage kryptografische Verifizierung durchführt. Ein Zahlungsnetzwerk, das Anfragen konsequent in unter 400 Millisekunden verarbeitet, ist für eine Bank oder einen Zahlungsanbieter nützlicher als eines, das hochtoupierten Durchsatz behauptet, aber unvorhersehbare Antwortzeiten liefert.
Der Infrastrukturstack diversifiziert sich zudem. Mehrere Anbieter bieten inzwischen dedizierte XRPL-Node-Dienste an, was die Last verteilt und Single Points of Failure reduziert. Die über 10.000 Lesezugriffe pro Sekunde auf öffentlichen Clustern deuten darauf hin, dass das Netzwerk erhebliches Abfragevolumen bewältigen kann – noch bevor dedizierte Enterprise-Systeme hinzukommen.
Da der native Automated Market Maker (AMM) des XRPL inzwischen auf der Mainnet läuft und eine EVM-kompatible Sidechain in Entwicklung ist, wird die Nachfrage an der RPC-Infrastruktur voraussichtlich über einfache Zahlungsabfragen hinauswachsen. Das macht verifizierbares, gut dokumentiertes Benchmarking – wie XRPL Labs es mit Perzentil-Latenzen veröffentlicht – zu einem nützlicheren Maßstab als virale Durchsatzbehauptungen. Das ist die Kennzahl, die es im Blick zu behalten gilt, wenn die Nutzung dieser neueren Funktionen skaliert.