Principio fundamental de internet: cuanto más cerca, más rápido. Siempre, también en Solana
Muchos traders y proyectos que buscan el «entorno más rápido» se fijan primero en la latencia media.
Puede servir como referencia para comparar, pero si el objetivo es el trading zero-slot —es decir, el intervalo de 200–400 ms—, nunca lo conseguirás guiándote por la media.
Solana está distribuida por todo el mundo y la comunicación entre continentes añade inevitablemente cientos de milisegundos de retraso.
Mientras te centres en un promedio que incluya esos retrasos, la velocidad que realmente necesitas seguirá fuera de tu alcance.
En la práctica, el resultado se decide reduciendo apenas unos milisegundos dentro de tu propia región, donde la comunicación se produce a corta distancia.
Recuperar la intuición sobre la velocidad
Para entender una red, imagina que conduces un coche. El punto de partida es tu casa y el destino, la oficina. Un trayecto corto es sencillo y rápido, con poco riesgo de accidentes o atascos.
Un viaje largo, en cambio, incluye cruces, autopistas y túneles; es probable que aparezca congestión en algún punto del recorrido de ida y vuelta.
Internet funciona del mismo modo. Cuanto más lejos está el servidor, más saltos se necesitan y más variable se vuelve el tiempo de ida y vuelta. Acercar el destino es la ruta más corta para lograr al mismo tiempo la máxima velocidad y estabilidad.
Por qué las medias no permiten ganar
Datos de la red Solana: Validators Solutions
En Solana, los líderes rotan para producir bloques, por lo que el resultado depende de la distancia física al líder actual. Los líderes están distribuidos por todo el mundo y no es extraño que se encuentren en continentes distintos.
La comunicación intercontinental supera los 100 ms de ping y alcanza varios cientos de milisegundos en los streams.
Por mucho que se optimice un promedio que incluya esos retrasos, no se convertirá en rendimiento real. En los slots intercontinentales simplemente no es posible recuperar la diferencia.
La clave no es perseguir promedios, sino concentrarse en la propia región y reducir al mínimo los recorridos de ida y vuelta dentro de ella. Competir por unos pocos milisegundos a corta distancia es el único enfoque práctico que ofrece una ventaja real.
Como referencia, estos son los valores base de ida y vuelta según la distancia:
| Distancia | Ping de ida y vuelta (aprox.) |
|---|---|
| Misma red | ~0,1 ms |
| Conexión privada | ~0,2 ms |
| Mismo centro de datos | ~0,3 ms |
| Misma ciudad | ~1 ms |
| País vecino | ~5–10 ms |
| Intercontinental | ~100–300 ms |
La latencia efectiva real aumenta aún más según el método de comunicación, debido a la sobrecarga del protocolo y al coste de mantener la conexión:
| Método | Multiplicador de latencia | Notas |
|---|---|---|
| Ping (ideal) | 1× | Solo sirve como límite inferior de referencia |
| POST (envío único) | ~2–3× | Control de ida y vuelta, reintentos y TLS |
| Stream | ~5× | Conexión persistente, control de congestión y buffers |
Cómo medir la «cercanía»
La cercanía debe medirse con datos, no por intuición. Empieza comprobando la posición de la época actual. Mediante el método RPC getEpochInfo, obtén los datos más recientes de la época, los slots transcurridos y los slots restantes.
A continuación utiliza getRecentPerformanceSamples para estimar la duración media reciente de un slot. Multiplicar esa duración por los slots restantes proporciona una estimación de los segundos que faltan para la transición, útil para preparar y planificar los cambios.
A medida que se acerque la transición, prepara la consulta de los líderes del intervalo objetivo mediante getSlotLeaders.
Puedes obtener la lista de nodos del clúster con getClusterNodes, cruzar los datos del líder con la información de los nodos y utilizar las IP públicas o las direcciones de gossip para inferir la programación geográfica.
Una advertencia: la geolocalización de IP contiene errores y retrasos, por lo que las estimaciones pueden fallar. Después de cartografiar las ubicaciones, haz siempre ping desde cada punto para medir directamente la latencia base de ida y vuelta.
Una red se parece a un viaje por carretera: no solo importa la distancia, sino que la ruta elegida también cambia la hora de llegada. El ping muestra de forma sencilla cuánto tráfico tienen las «carreteras» de hoy.
No dependas de una sola medición. Toma varias muestras a intervalos breves y utiliza la mediana para reducir el ruido.
No descartes los resultados después de utilizarlos. Acumula en tu propia base de datos los tiempos de ida y vuelta y las correspondencias de cada ubicación, y actualízalos de forma incremental mediante workers ligeros en cada transición de época. Así se estabiliza la operación y se agiliza la toma de decisiones.
La ubicación de la aplicación define la latencia
La velocidad no depende únicamente de las especificaciones del servidor. La ubicación de la aplicación es igual de importante.
Como ejemplo extremo, supervisar desde Tokio lo que ocurre en Frankfurt supone una desventaja. La latencia de ida y vuelta acumula retrasos y te mantiene siempre por detrás.
Despliega recursos en cada ubicación y completa allí la recepción y el procesamiento, o transfiere los datos a la siguiente ubicación por la ruta más corta. Esta estructura mejora tanto la cobertura como la capacidad de respuesta.
VPS desplegado dentro de la misma red
Nuestras instancias VPS se despliegan por región dentro de la misma red que los endpoints dedicados a Solana. Así reducen la comunicación externa y logran los recorridos de ida y vuelta más cortos.
Pueden desplegarse rápidamente y a pequeña escala en cada región. Incluso distribuir workers de uno o dos núcleos reduce la latencia efectiva y el riesgo de perder oportunidades.
Próximo lanzamiento en septiembre de 2025: SUPER EPYC VPS
Este mes tenemos previsto lanzar «SUPER EPYC VPS», comenzando por Frankfurt, nuestra región más popular. Utiliza CPU para centros de datos con una frecuencia de 5,7 GHz, líder del mercado.
No es habitual adoptar CPU de última generación en productos VPS, por lo que la disponibilidad será limitada. Para quienes busquen el VPS más rápido, será una opción muy potente.
Para obtener la máxima calidad y velocidad: bare metal
Un VPS divide un servidor físico en partes virtualizadas; un servidor bare metal dedica en exclusiva toda la CPU, la memoria, los discos y el ancho de banda de red a un solo cliente.
Así resulta más fácil mantener un rendimiento alto y estable incluso en las horas punta, algo ideal para aplicaciones de Solana que exigen una latencia baja y constante.
Para los casos de uso de Solana, las CPU Ryzen son especialmente populares y alcanzan una frecuencia máxima de 5,7 GHz dentro del segmento de consumo. EPYC está diseñado para reducir la sobrecarga de la virtualización, mientras que Ryzen busca maximizar el rendimiento de una sola máquina sin virtualización. Elige según tu caso de uso.
Problemas que resuelve ERPC
- Fallos de transacciones y variaciones de latencia habituales en entornos RPC típicos
- Limitaciones de rendimiento impuestas por numerosos proveedores de infraestructura
- Gran impacto de la distancia de red en la calidad de la comunicación
- Acceso limitado de los proyectos pequeños a infraestructura de alta calidad
Los detalles de los productos, las pruebas gratuitas, el proceso de incorporación, las configuraciones dedicadas, las consultas de inventario y la lista de espera están disponibles mediante el panel web de ERPC:
- Sitio web oficial de ERPC: https://erpc.global/es
- Panel web de ERPC: https://dashboard.erpc.global/es
Seguiremos investigando y desarrollando para estabilizar el suministro, ampliar nuestra gama y aportar valor a más proyectos de todo el mundo.
Gracias por tu apoyo constante.
