Le dichiarazioni sul throughput RPC dell'XRP Ledger sotto esame: i benchmark verificati raccontano una storia diversa
Punti chiave
- •I benchmark verificati non supportano l'affermazione virale secondo cui i nodi RPC dell'XRPL elaborano 30.000 messaggi al secondo.
- •I cluster di server XRPL pubblici hanno gestito oltre 10.000 letture al secondo nei periodi di picco, mentre il throughput delle transazioni in produzione è storicamente compreso tra 100 e 230 TPS.
- •L'endpoint pubblico di XRPL Labs registra una latenza p50 di circa 371 millisecondi per le chiamate ledger_current, la più bassa tra i server XRPL pubblici.
- •La messaggistica dei validatori ha registrato una media di circa 3.260 messaggi al secondo nei test ottimali, ma il traffico di consenso dei validatori non è paragonabile alle richieste RPC client-server.
- •Con l'AMM nativo attivo sulla mainnet e una sidechain compatibile EVM in sviluppo, la domanda sull'infrastruttura RPC dell'XRPL è destinata a crescere, rendendo i benchmark di latenza documentati più rilevanti delle dichiarazioni virali di throughput.

Un'affermazione circolante sui social media secondo cui i nodi RPC dell'XRP Ledger possono elaborare 30.000 messaggi al secondo suona impressionante. Il problema è che i benchmark verificati in realtà non supportano quel numero. È uno schema osservabile in vari ecosistemi blockchain, in cui i numeri di throughput da titolo circolano distaccati dalle condizioni di test originali — spesso misurazioni di laboratorio, conteggi di messaggi interni o proiezioni ottimistiche — e vengono ripetuti come capacità di produzione.
Cosa mostrano i numeri reali
XRPL Labs, uno dei principali sviluppatori di infrastrutture per l'XRP Ledger, si è concentrata sulla latenza piuttosto che sul throughput grezzo dei messaggi. Il suo endpoint pubblico registra attualmente una latenza p50 di circa 371 millisecondi per le chiamate ledger_current, il che lo rende l'opzione a latenza più bassa tra i server XRPL pubblici.
I cluster di server pubblici sono stati osservati gestire oltre 10.000 letture al secondo durante i periodi di utilizzo di picco. È un dato solido per un'infrastruttura blockchain, ma rappresenta un terzo della cifra dichiarata di 30.000.
GetBlock, un altro fornitore di infrastrutture, dichiara che i suoi nodi XRPL possono elaborare oltre 1.000 richieste al secondo senza limiti di frequenza su configurazioni dedicate.
Il risultato più vicino alla cifra da titolo riguarda la messaggistica dei validatori, una categoria di traffico fondamentalmente diversa. La gestione dei messaggi dei validatori ha registrato medie intorno a 3.260 messaggi al secondo in condizioni di test ottimali, con picchi superiori a 6.100 messaggi al secondo. Ma il traffico di consenso tra validatori e le richieste RPC client-server non sono paragonabili.
Negli ambienti di produzione, il throughput effettivo delle transazioni della rete XRPL è storicamente oscillato tra 100 e 230 transazioni al secondo durante i picchi giornalieri. I massimi teorici in ambienti di test controllati hanno superato i 1.500 TPS, comunque un ordine di grandezza al di sotto della cifra di 30.000 citata.
Perché il divario è importante
La distinzione tra messaggi al secondo e transazioni al secondo è importante. Un nodo RPC può gestire migliaia di richieste di lettura — consultazioni di saldo, interrogazioni del ledger, aggiornamenti di sottoscrizione — che non si traducono mai in una transazione scritta sul ledger. Contare tutti i messaggi in entrata, inclusi ping, controlli di stato e richieste fallite, produrrà sempre un numero più grande rispetto al conteggio delle transazioni effettivamente elaborate.
Per XRP in particolare, la cosa conta perché Ripple sta posizionando l'XRPL come infrastruttura per l'elaborazione di pagamenti istituzionali e per l'attività di scambio decentralizzato. Entrambi i casi d'uso richiedono prestazioni prevedibili e verificabili sotto carico sostenuto, non picchi teorici raggiunti in laboratorio. Conta anche per gli sviluppatori che scelgono l'infrastruttura: la pianificazione della capacità basata su cifre gonfiate porta a sistemi sottodimensionati e interruzioni durante i picchi di domanda.
Verso dove si dirige davvero l'infrastruttura XRPL
La cifra di latenza p50 di 371 ms rappresenta un progresso significativo per una rete decentralizzata che esegue la verifica crittografica su ogni richiesta. Una rete di pagamenti che elabora costantemente le richieste in meno di 400 millisecondi è più utile a una banca o a un fornitore di servizi di pagamento rispetto a una che dichiara throughput altissimi ma offre tempi di risposta imprevedibili.
Lo stack infrastrutturale si sta anche diversificando. Più fornitori offrono oggi servizi dedicati di nodi XRPL, distribuendo il carico e riducendo i singoli punti di guasto. Le oltre 10.000 letture al secondo osservate sui cluster pubblici suggeriscono che la rete può gestire volumi di interrogazioni significativi ancora prima che entrino in scena configurazioni aziendali dedicate.
Con il market maker automatico (AMM) nativo dell'XRPL ora attivo sulla mainnet e una sidechain compatibile EVM in sviluppo, la domanda sull'infrastruttura RPC probabilmente crescerà oltre le semplici interrogazioni di pagamento. Ciò rende il benchmarking verificabile e ben documentato — del tipo che XRPL Labs pubblica con latenze percentiliche — un metro di misura più utile rispetto alle dichiarazioni virali di throughput, ed è la metrica da osservare man mano che l'adozione di queste nuove funzionalità si amplia.