¿Con qué proveedor de RPC deberías construir en Tokio?

Comparamos cinco de los proveedores de RPC que sirven Tokio en cinco cadenas. Así se comparan, y dónde importan las diferencias para los equipos sensibles a la latencia.

Node RPC y WebSockets de Alchemy ya están disponibles en Tokio, hasta 8 veces más rápidos que antes. Los equipos que construyen en Japón tienen una opción real de proveedores, así que los comparamos de frente desde Tokio, en Ethereum, Arbitrum, BNB Chain, Polygon y Robinhood Chain, para ayudarte a decidir con cuál construir.

Ningún proveedor lidera en todo. Lo que importa en flujos sensibles a la latencia es encontrar el proveedor que encaja con tu caso de uso, tanto en las respuestas típicas como en las más lentas de la cola. Para un trader, una lectura que vuelve tarde significa un precio viejo y slippage cuando el mercado se mueve.

¿Cómo se compara la latencia de cola entre cadenas?

Somos el único proveedor en el top dos en las cinco cadenas, y el primero en Polygon, BNB Chain y Arbitrum.

Este es el p95, el extremo lento de las respuestas de cada proveedor, por cadena.

La brecha más amplia está en Polygon. Ahí, una de cada veinte solicitudes tarda más de 215 ms en QuickNode, frente a 44 ms en el nuestro. La mayor parte de esa brecha viene de las lecturas de estado. eth_call y eth_getBalance de QuickNode superan los 215 ms en p95, frente a 13 ms y 11 ms en los nuestros, y esas son las llamadas que los sistemas de trading usan para actualizar cotizaciones y precios.

Frente al resto, las brechas son más amplias. Nuestro p95 es menor que el de dRPC, Infura y Goldsky en cada cadena donde los medimos, 1.5x en Robinhood Chain y hasta 19x en Arbitrum.

En esta corrida, Alchemy y QuickNode mantuvieron una tasa de éxito del 100% en cada cadena, excepto QuickNode con 99.96% en Polygon.

¿Cómo se comparan los proveedores a nivel global?

En nuestro benchmark global en vivo entre cadenas EVM, Alchemy tiene la latencia promedio más baja de cualquier proveedor, con 15.54 ms.

Instantánea en vivo de alchemy.com/benchmarks, 29 de septiembre de 2026, 19:22 UTC. Los números se actualizan cada cinco minutos y pronto sumaremos Tokio para ver el rendimiento en vivo; datos crudos en alchemy.com/benchmarks/data.md. Consulta la metodología aquí.

Cómo lo medimos

Una sola configuración, aplicada a cada proveedor. Enviamos las mismas lecturas EVM JSON-RPC desde instancias controladas de AWS ECS en Tokio, en cuentas de pago estándar, con el mismo calentamiento para cada uno. Los proveedores corrieron de a uno, a un ritmo constante de 20 solicitudes por segundo.

Las solicitudes cubrieron siete lecturas comunes: eth_blockNumber, eth_getBalance, un eth_call liviano (un balanceOf() de ERC-20), eth_getBlockByNumber, eth_getLogs en un rango de 10 bloques, eth_getBlockReceipts y eth_getTransactionReceipt.

Cada solicitud tuvo un intento, sin reintentos. Un reintento puede ocultar una respuesta lenta o fallida, así que cada respuesta lenta cuenta en contra del proveedor que la dio. El p95 sale de la latencia p95 de las respuestas exitosas únicamente, y las fallas se reportan aparte.

Cómo probar el RPC que encaja con tu aplicación

Nuestros resultados son un punto de partida. El proveedor que encaja con tu aplicación es el que se sostiene en tus cadenas, tus métodos y las regiones donde están tus usuarios o sistemas. Puedes probarlo tú mismo con un script y unos endpoints de pago.

1. Prueba las llamadas que tus usuarios sienten. Por ejemplo, si construyes una aplicación de trading en una cadena EVM, prueba llamadas como eth_call para cotizaciones y estado del pool, y eth_getBlockByNumber para obtener la información más reciente.

2. Mantén todo igual. Envía el mismo payload a cada proveedor, desde la misma máquina, en la región donde corre tu app. Usa las mismas cuentas de pago, el mismo calentamiento, conexiones reutilizadas, el mismo timeout y un intento por solicitud, sin reintentos. Haz el benchmark de cada cadena por separado, porque un resultado en una cadena no se traslada a otra.

3. Corre lo suficiente para ver la cola. Para confiar en el p95, junta varios miles de solicitudes por proveedor en cada cadena, a distintas horas del día. Prueba a los proveedores con el RPS típico de producción para ver cómo se comportan bajo carga real.

4. Lee cuatro números juntos.

• Promedio y p50 de la solicitud típica
• p95 del extremo lento, de donde salen la mayoría de los precios viejos y el slippage
• Tasa de éxito, contando timeouts, límites de tasa y errores como fallas, y dejando las solicitudes fallidas fuera de los números de latencia
• Resultados por método, porque un proveedor puede liderar en una llamada y quedar atrás en otra

En cargas de trading, mide también qué tan rápido entrega cada proveedor los bloques nuevos.

Empieza a construir en Tokio

Habla con nuestro equipo sobre tus cadenas y métodos, o empieza en el dashboard.

Preguntas frecuentes

¿Alchemy es más rápido que QuickNode en Tokio?

Depende de tu carga. En Polygon, en el p95, Alchemy es unas 17 veces más rápido que QuickNode en una lectura de contrato o de saldo (eth_call y eth_getBalance). En el p95, el extremo lento, Alchemy es casi 5 veces más rápido en Polygon y 1.6 veces más rápido en BNB Chain. En Ethereum, Arbitrum y Robinhood Chain, los dos están a unos 5 ms entre sí en p95, así que prueba las cadenas y las llamadas de las que depende tu carga.

¿Cómo uso la infraestructura de Alchemy en Tokio? ¿Tengo que cambiar mi endpoint?

Usa tu endpoint de Alchemy. No hace falta configurar nada. Enrutamos las solicitudes automáticamente a la región disponible más cercana.

¿Qué redes se sirven desde Tokio?

La infraestructura de Alchemy en Tokio arranca con Base, BNB Chain, Robinhood Chain, Ethereum, Polygon, Arbitrum, HyperEVM, Arc y más. Alchemy ha construido relaciones con más de 100 cadenas en casi 10 años, y seguimos sumando redes a Tokio de forma continua.