Een claim die op sociale media de ronde doet — dat RPC-noden van het XRP Ledger 30.000 berichten per seconde kunnen verwerken — klinkt indrukwekkend. Het probleem is dat geverifieerde benchmarks dat getal niet ondersteunen. Het is een patroon dat in blockchain-ecosystemen vaker voorkomt: opvallende doorvoercijfers circuleren losgeraakt van hun oorspronkelijke testomstandigheden — vaak labmetingen, interne berichtentellingen of optimistische projecties — en worden herhaald als productiecapaciteiten.

Wat de werkelijke cijfers laten zien

XRPL Labs, een van de belangrijkste infrastructuurentwikkelaars van het XRP Ledger, heeft zich gericht op latentie in plaats van op ruime berichtdoorvoer. Het publieke eindpunt rapporteert momenteel een p50-latentie van ongeveer 371 milliseconden voor ledger_current-aanroepen, waarmee het de optie met de laagste latentie is onder de publieke XRPL-servers.

Er is waargenomen dat publieke serverclusters tijdens piekperiodes meer dan 10.000 leesbewerkingen per seconde verwerken. Dat is een stevig getal voor blockchain-infrastructuur, maar het is een derde van de geclaimde 30.000.

GetBlock, een andere infrastructuuraanbieder, stelt dat zijn XRPL-noden op dedicated omgevingen meer dan 1.000 verzoeken per seconde kunnen verwerken zonder snelheidslimieten.

Het dichtst bij het opvallende getal komt men met validatorberichten, een fundamenteel andere categorie verkeer. De verwerking van validatorberichten bereikte onder optimale testomstandigheden gemiddelden van rond de 3.260 berichten per seconde, met pieken boven de 6.100 berichten per seconde. Maar consensusverkeer tussen validatoren is niet vergelijkbaar met client-server RPC-verzoeken.

In productieomgevingen lag de werkelijke transactiedoorvoer van het XRPL-netwerk historisch tussen de 100 en 230 transacties per seconde tijdens dagelijkse pieken. Theoretische maxima in gecontroleerde testomgevingen bereikten meer dan 1.500 TPS — nog steeds een orde van grootte onder de genoemde 30.000.

Waarom dit verschil ertoe doet

Het onderscheid tussen berichten per seconde en transacties per seconde is belangrijk. Een RPC-node kan duizenden leesverzoeken verwerken — saldo-opvragingen, ledger-query's, abonnementsupdates — die nooit leiden tot een transactie die naar het grootboek wordt geschreven. Het tellen van alle inkomende berichten, inclusief pings, statuscontroles en mislukte verzoeken, levert altijd een groter getal op dan het tellen van werkelijk verwerkte transacties.

Voor XRP is dit specifiek relevant omdat Ripple het XRPL positioneert als infrastructuur voor institutionele betalingsverwerking en gedecentraliseerde exchange-activiteiten. Beide gebruiksgevallen vereisen voorspelbare, verifieerbare prestaties onder aanhoudende belasting, geen theoretische pieken die in laboratoriumomstandigheden zijn behaald. Het is ook relevant voor ontwikkelaars die infrastructuur kiezen: capaciteitsplanning op basis van opgeblazen cijfers leidt tot ondergedimensioneerde systemen en storingen tijdens vraagpieken.

Waar de XRPL-infrastructuur werkelijk naartoe gaat

De p50-latentie van 371 ms vertegenwoordigt een betekenisvolle vooruitgang voor een gedecentraliseerd netwerk dat bij elk verzoek cryptografische verificatie uitvoert. Een betalingsnetwerk dat verzoeken consistent in minder dan 400 milliseconden verwerkt, is nuttiger voor een bank of betalingsdienstverlener dan een netwerk dat hemelhoge doorvoer claimt maar onvoorspelbare responstijden levert.

De infrastructuurstack diversifieert ook. Meerdere aanbieders bieden inmiddels dedicated XRPL-node-diensten aan, wat de belasting spreidt en single points of failure vermindert. De meer dan 10.000 leesbewerkingen per seconde die op publieke clusters zijn waargenomen, suggereren dat het netwerk aanzienlijke queryvolumes aankan, nog vóórdat dedicated enterprise-omgevingen in beeld komen.

Nu de native automated market maker (AMM) van het XRPL live is op de mainnet en een EVM-compatibele sidechain in ontwikkeling is, zal de vraag naar RPC-infrastructuur waarschijnlijk uitgroeien boven eenvoudige betalingsquery's. Dat maakt verifieerbare, goed gedocumenteerde benchmarking — zoals XRPL Labs publiceert met percentiel-latenties — tot een nuttiger maatstaf dan virale doorvoerclaims, en het is de metriek om in de gaten te houden naarmate het gebruik van deze nieuwere functies schaalt.