Un reclamo que circula en redes sociales que los nodos RPC de XRP Ledger pueden procesar 30,000 mensajes por segundo suena impresionante. El problema es que los benchmarks verificados no respaldan realmente ese número.
Lo que realmente muestran los números
XRPL Labs, uno de los principales desarrolladores de infraestructura para el XRP Ledger, se ha centrado en la latencia en lugar del rendimiento bruto de mensajes. Su punto final público actualmente registra una latencia p50 de aproximadamente 371 milisegundos para llamadas ledger_current, convirtiéndolo en la opción de menor latencia entre los servidores públicos de XRPL.
Se ha observado que los clústeres de servidor públicos manejan más de 10,000 lecturas por segundo durante los períodos de uso pico. Esa es una cifra sólida para la infraestructura de cadena de bloques, pero es un tercio de la cifra reclamada de 30,000.
GetBlock, otro proveedor de infraestructura, afirma que sus nodos XRPL pueden procesar más de 1,000 solicitudes por segundo sin límites de tasa en configuraciones dedicadas.
Lo más cercano que alguien ha estado de la cifra principal involucra mensajes de validadores, que es una categoría fundamentalmente diferente de tráfico. El manejo de mensajes de validadores ha registrado promedios de alrededor de 3.260 mensajes por segundo en condiciones óptimas de prueba, con picos por encima de 6.100 mensajes por segundo. Pero el tráfico de consenso entre validadores y las solicitudes RPC cliente-servidor son cosas distintas.
En entornos de producción, el rendimiento real de transacciones de la red XRPL ha oscilado históricamente entre 100 y 230 transacciones por segundo durante los picos diarios. Los máximos teóricos en entornos de prueba controlados han alcanzado más de 1.500 TPS, lo que aún está un orden de magnitud por debajo de la cifra de 30.000 que se menciona.
Por qué importa la brecha
La distinción entre mensajes por segundo y transacciones por segundo es importante aquí. Un nodo RPC podría manejar miles de solicitudes de lectura (consultas de saldo, consultas de libro mayor, actualizaciones de suscripción) que nunca dan como resultado una transacción escrita en el libro mayor. Contar todos los mensajes entrantes, incluidos los pings, las verificaciones de estado y las solicitudes fallidas, siempre producirá un número mayor que contar las transacciones procesadas realmente.
Para XRP en particular, esto es importante porque Ripple ha posicionado al XRPL como infraestructura para el procesamiento de pagos institucionales y la actividad de intercambio descentralizado. Ambos casos de uso requieren un rendimiento predecible y verificable bajo carga sostenida, no picos teóricos alcanzados en condiciones de laboratorio.
Hacia dónde se dirige realmente la infraestructura de XRPL
La cifra de latencia p50 de 371 ms representa un progreso significativo para una red descentralizada que maneja verificación criptográfica en cada solicitud. Una red de pagos que procesa consistentemente solicitudes en menos de 400 milisegundos es más útil para un banco o proveedor de pagos que una que afirma tener un rendimiento extremadamente alto pero ofrece tiempos de respuesta impredecibles.
La pila de infraestructura también se está diversificando. Varios proveedores ahora ofrecen servicios de nodo dedicado XRPL, lo que distribuye la carga y reduce los puntos únicos de fallo. Los más de 10.000 lecturas por segundo observadas en clústeres públicos sugieren que la red puede manejar un volumen significativo de consultas incluso antes de que entren en escena configuraciones empresariales dedicadas.