Mide la velocidad y la fiabilidad de tu RPC. Benchmark RPC gratis frente a GetBlock

El benchmark envía un número limitado de solicitudes JSON-RPC de solo lectura durante una ventana de prueba corta. La cantidad exacta depende de la duración actual del benchmark, del perfil seleccionado en “¿Qué estás construyendo?”, del tiempo de respuesta del endpoint y de la rapidez con la que responde cada proveedor antes del timeout. Está diseñado como un diagnóstico ligero, no como una prueba de carga pesada. El informe del benchmark muestra el número total de solicitudes para que veas cuánto tráfico se usó en esa ejecución.

Sí, puedes probar un endpoint RPC privado que incluya una API key en la URL. La herramienta enmascara el endpoint en los informes y no vuelve a mostrar la URL completa en la página. Por seguridad, solo debes pegar URLs RPC, nunca claves privadas, seed phrases, secretos de wallet ni credenciales de firma. Si tu proveedor usa allowlists por dominio o IP, asegúrate de permitir el acceso desde el servidor del benchmark.

Este benchmark público está pensado solo para endpoints RPC de mainnet. Las referencias de GetBlock en esta herramienta están configuradas para comparaciones de mainnet, por lo que un endpoint de testnet o devnet puede producir resultados engañosos de latencia, freshness y compatibilidad por método. Si el endpoint pegado informa un chain ID o una identidad de red de testnet, la herramienta debe bloquear la ejecución y pedirte que uses un endpoint de mainnet para el protocolo seleccionado. Los benchmarks de testnet deberían usar una referencia separada, una metodología separada y resultados claramente etiquetados como testnet.

“Limitación de tasa detectada” significa que el endpoint devolvió una respuesta que parece limitación de tráfico, normalmente HTTP 429 o un mensaje del proveedor del tipo “too many requests”. En el informe aparece en Hallazgos porque suele ser un riesgo de producción accionable. Los endpoints públicos suelen empezar a limitar antes que los endpoints privados o de pago. En producción, esto puede provocar cargas de página fallidas, indexación retrasada o bots rotos si no añades reintentos, caché o rutas fallback.

Los endpoints RPC públicos son compartidos por muchos usuarios, por lo que su latencia y fiabilidad pueden cambiar rápidamente según la demanda total de la red. Un endpoint privado o de pago suele tener capacidad más estable, límites más altos, mejor routing e infraestructura más predecible. Un endpoint público puede servir para pruebas, pero también puede mostrar un p95 más alto, más timeouts o errores de limitación bajo solicitudes repetidas. Por eso este benchmark compara latencia y fiabilidad, no solo si el endpoint responde o no.

La actualización de bloque mide si tu endpoint RPC está al día con el último bloque o slot comparado con la referencia de GetBlock. En el informe, la comprobación del último bloque muestra la posición de cadena de ambos endpoints y la diferencia de bloques o slots entre ellos. Un endpoint puede responder rápido y aun así estar por detrás del estado real de la red. Esa diferencia también influye en la aptitud para producción porque los datos obsoletos pueden afectar wallets, indexers, bots de trading y otras aplicaciones de producción.

Una comparación RPC justa envía los mismos métodos de solo lectura, con el mismo timeout, durante la misma ventana corta de tiempo, desde el mismo servidor de benchmark, a endpoints de mainnet del mismo protocolo. Si alguna de esas condiciones cambia, la comparación se vuelve ruidosa y fácil de malinterpretar. Esta herramienta mantiene el perfil de solicitudes alineado para que rendimiento de proveedores, desglose de latencia, hallazgos y aptitud para producción se basen en la misma ejecución.