ERPC publica "How to be faster on Solana?" (¿Cómo ser más rápido en Solana?) — un informe que visualiza, con datos en vivo, qué determina la velocidad en Solana como la física de la distancia de red
ERPC publica "How to be faster on Solana?" (¿Cómo ser más rápido en Solana?) — un informe que visualiza, con datos en vivo, qué determina la velocidad en Solana como la física de la distancia de red
ELSOUL LABO B.V. (sede: Amsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO, que operan ERPC, se complacen en anunciar la publicación de "How to be faster on Solana?" (¿Cómo ser más rápido en Solana?), una página de informe que expone —en un único recorrido de arriba abajo que incluso un desarrollador no especialista puede captar de un vistazo— cómo ganar velocidad en Solana.
En los últimos años, un número creciente de desarrolladores y equipos se ha adentrado en el trading de alta frecuencia (HFT) y en la infraestructura financiera en tiempo real sobre blockchains, y en Solana en particular. Sin embargo, el conocimiento que hay detrás de las preguntas más básicas —por qué unos son más rápidos y cómo serlo— ha permanecido disperso entre artículos técnicos de blog individuales y explicaciones fragmentarias, con pocos recursos que permitan captar el panorama completo con rapidez. Este informe reorganiza el núcleo de los artículos técnicos que ERPC ha ido publicando a lo largo del tiempo en una sola "línea de física" continua.
Este informe comparte una comprensión práctica para usar la red de forma más eficiente y a mayor velocidad, incluso en una red descentralizada cuyos participantes están repartidos por todo el mundo. Creemos que compartir de manera sistemática dónde, y por qué, surgen las diferencias de velocidad contribuye a la eficiencia y al crecimiento sano del ecosistema blockchain en su conjunto, incluido Solana, más allá del interés de cualquier proveedor concreto.
How to be faster on Solana? (el informe): https://erpc.global/es/how-to-be-faster/
Sitio oficial de ERPC: https://erpc.global/es
Panel de ERPC: https://dashboard.erpc.global/es
Lo que determina la velocidad no es tu código ni tu máquina, sino la tercera capa invisible
"Ejecuto la misma estrategia y, aun así, solo mi bot se queda atrás en la ejecución." "Los precios se actualizan bien, pero solo mis transacciones no llegan." "Cambié de proveedor de RPC y no cambió nada." — las quejas que expresan los desarrolladores que compiten en velocidad sobre Solana son llamativamente parecidas.
El primer sospechoso siempre es "quizá mi código sea lento" o "quizá mis especificaciones no sean lo bastante buenas". Optimizar tu código y tu máquina ayuda, por supuesto. Pero en muchos casos en los que ya has afinado ambos a fondo, lo que permanece hasta el final —y es lo más ignorado— es una tercera capa invisible: tu distancia de red hasta Solana.
Una vez que tu ruta de ejecución está bien optimizada, lo que el ajuste de CPU a nivel de instrucción todavía puede recortar vive en el mundo de los nanosegundos, a lo sumo unos pocos microsegundos. La distancia de red, en cambio, gobierna cientos de milisegundos: una palanca del orden de unas 1000× duerme en la capa que la gente más pasa por alto. Una vez superado el punto en que ya has pulido tu código y tu máquina, el mayor margen restante está en esa tercera capa.
En Solana, el "lugar más rápido" se desplaza por el mundo en cada slot
En Solana, un slot avanza aproximadamente cada 400 milisegundos, y cada slot tiene un validador asignado como su "leader" para construir esa porción del bloque. Los leaders cambian con rapidez (el mismo validador puede ocupar varios slots consecutivos), y el servidor más cercano a ese leader obtiene una gran ventaja para ese slot.
Esto es lo que lo hace fundamentalmente distinto del trading de alta frecuencia tradicional. En renta variable o en divisas, colocar tus servidores junto al único motor de emparejamiento de la bolsa —un punto fijo que no se mueve— te mantenía por delante de forma permanente. En Solana, el leader se desplaza por el mundo slot a slot. El asiento más rápido está en un lugar distinto cada vez. Acampar junto a un único punto una vez y darlo por hecho sencillamente no funciona aquí.
En el informe, un globo terráqueo impulsado por datos en vivo de la Leader Slot Information API de ERPC (getLeaderSlots) muestra el leader actual, y su vertiginoso relevo, exactamente tal como ocurre. "El lugar más rápido no deja de moverse" — esto no es una metáfora, sino un hecho que puedes observar en vivo.
La distancia es latencia — desde ~0.1ms en la misma red hasta 100–300ms entre continentes
La velocidad de la luz a través de la fibra, y el número de saltos de router a lo largo de la ruta, fijan un suelo que ningún hardware puede superar. La distancia surte efecto aproximadamente en los siguientes órdenes de magnitud:
- Misma red: ~0.1ms
- Mismo centro de datos: ~0.3ms
- Misma ciudad: ~1ms
- País vecino: ~5–10ms
- Entre continentes: ~100–300ms
Un único slot dura solo unos 400 milisegundos. Los 100–300 milisegundos de cruzar un continente se comen por sí solos la ventana de un slot entero. Cuando el leader está a tu puerta, llegas dentro de la ventana; cuando está al otro lado del planeta, ya lo has perdido antes de enviar. Ser rápido en cada slot significa estar siempre "cerca" allí donde caiga el leader.
Ten en cuenta que los contrastes del informe —"~0.1ms en la misma red" frente a "en un camino con rodeos el número de saltos de relé (hops = los routers por los que pasa una señal) sube a unos 7, y la latencia se ensancha hasta unas 70×"— son cifras redondeadas pensadas para transmitir, de forma intuitiva, la brecha entre una ruta cercana y una lejana. Las grandes variaciones medidas aparecen en los datos en vivo de la Leader Slot Information API de ERPC: la latencia medida desde un nodo dado hasta el leader cambia mucho según dónde esté el leader (en qué slot), y se han observado variaciones del orden de decenas de veces entre slots cercanos y lejanos. Un único número de "latencia media" a menudo no es más que un slot rápido y un slot lento turnándose; la media con frecuencia oculta la realidad.
Y un "nombre de ciudad" no es la ruta de red en sí. Incluso dentro de la misma ciudad, si se insertan tránsitos externos o saltos adicionales, la latencia se acumula precisamente en esa medida. Justo por eso eliges el nodo más cercano por el tiempo de llegada medido (ping), y no por la distancia en un mapa.
Una sola ciudad no basta — multirregión, siempre cerca del leader
La ciudad donde los validadores de Solana se agrupan con mayor densidad es Frankfurt. Aun así, en una instantánea medida en el momento de la publicación, los validadores reunidos en Frankfurt representan solo en torno a una cuarta parte de la red en su conjunto, tanto por número de validadores como por stake. Los aproximadamente tres cuartos de slots restantes se lideran desde algún lugar distinto de Frankfurt.
Dicho de otro modo, aunque coloques tu única mejor máquina en la ciudad más concurrida, eso por sí solo nunca puede hacerte "siempre el más rápido". Estar a la espera en varias regiones (por ejemplo Frankfurt / Amsterdam / New York / Tokyo / Singapore), recibir cerca de cualquiera que sea el leader activo, y traspasar a medida que el leader se mueve — esta es la forma de ser rápido en cada slot.
Cuando tus transacciones no llegan, estás atascado en el carril del spam
La velocidad no es solo cuestión de dónde se sitúa tu servidor. El carril por el que entregas tu transacción también decide el éxito o el fracaso.
De la capacidad del TPU (Transaction Processing Unit) que recibe las transacciones, el leader asigna hasta alrededor del 80% a la prioridad ponderada por stake — es decir, a las conexiones respaldadas por SOL comprometido con un validador (stake) (SWQoS / Stake-Weighted Quality of Service). El aproximadamente 20% restante lo comparten todas las demás conexiones. Este último es un carril congestionado, repleto de spam. Ten en cuenta que esta asignación del ~80% la decide el lado del leader como cuestión del protocolo de Solana, no es algo que fije ERPC.
Lanzar las transacciones directamente al leader parece el movimiento más rápido. Pero sin el respaldo del stake, eso significa hacer cola en el congestionado carril del ~20%, y bajo carga tu transacción acaba sin entrar nunca en el bloque. La respuesta esencial es enviar por una ruta respaldada por stake — desde un RPC conectado a un staked validator a través de una relación de trusted peer. ERPC opera un staked validator de primer nivel, conectado a líneas RPC de alta calidad, como respaldo de esto (Shinobi Performance Pool).
El hardware solo importa cuando funciona a plena potencia
Incluso un servidor situado en el lugar adecuado no puede aprovechar la cercanía que ganó si la propia máquina no rinde a tope. Un VPS virtualizado comparte un hipervisor, así que es propenso al jitter y a los bloqueos por "vecinos ruidosos" justo cuando las cosas se congestionan más. El bare metal dedicado no tiene eso. El suelo de velocidad de reloj que un validador de Solana debe cumplir es 2.8GHz; el bare metal de ERPC funciona muy por encima, con un reloj de clase 5.7GHz, manteniendo a la vez la utilización en el 30–40% — porque una CPU clavada al 95% genera jitter como una carretera atascada.
Esta diferencia no se limita al bare metal de primer nivel. En el informe, ponemos el VPS de ERPC (VPS++) lado a lado con una máquina virtual de una major cloud de especificaciones comparables (ambas AMD Turin / 4 vCPU) usando un benchmark real (node_bench). Esto no es una producción; es una "medición" que cualquiera puede reproducir con el mismo método. ERPC insiste de forma constante en demostrar la calidad de entrega y la velocidad mediante medición, no mediante afirmaciones subjetivas ni copy de marketing.
La respuesta final: misma red = distancia cero
Adonde llega toda esta línea de razonamiento es a un único punto: estar "en la misma red" que la infraestructura de Solana — RPC, validadores, y las rutas en tiempo real implicadas en el trading, como Jito y Shredstream. En la misma red son ~0.1ms, y los paquetes nunca cruzan la internet pública en absoluto. "A través de la internet pública", lo predeterminado para la mayoría de la gente, es exactamente la razón por la que la mayoría es lenta. La distancia cero es la conclusión que enlaza ubicación, máquina y stake.
ERPC — cada optimización que la física exigía, en una sola plataforma
Para cada respuesta que el informe deriva como física, ERPC tiene un medio correspondiente ya dispuesto: VPS y bare metal en la misma red (distancia cero), estar a la espera en varias regiones (FRA / AMS / NY / TYO / SGP) (siempre el más rápido), enrutamiento basado en el ping medido (al nodo verdaderamente más cercano por ruta, no por mapa), la API getLeaderSlots (conocer la posición del leader slot a slot), y bare metal de clase 5.7GHz ajustado con el SLV de código abierto (plena potencia).
ERPC nació porque, antes que nada, lo necesitábamos nosotros mismos. Operando el Epics DAO de código abierto (un juego de cartas sobre Solana), no podíamos comprar esta clase de infraestructura ni aunque lo intentáramos, así que no nos quedó más remedio que construirla nosotros mismos. Ahora tú puedes apoyarte en ese mismo cimiento.
En ERPC puedes combinar Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, servidores bare metal, RPC dedicado, SWQoS, una Price API con Pyth, y Jet Analytics & Indexed RPC en una sola plataforma.
Usar las redes descentralizadas de forma más rápida y eficiente
Hay una parte de la velocidad que puede mejorarse mediante la inversión adecuada en infraestructura. Pero lo que este informe intenta transmitir de forma constante es que comprender "dónde, y por qué, surge la diferencia" es la verdadera ventaja. Una vez que entiendes dónde estás perdiendo tiempo —ubicación, ruta, máquina o stake— puedes entonces elegir los recursos adecuados y centrarte en tu trabajo esencial: estrategia, programación y desarrollo.
Incluso en una red descentralizada, la red puede usarse de forma eficiente. Compartir esa realidad de manera sistemática debería contribuir a la eficiencia y al crecimiento del ecosistema blockchain en su conjunto, incluido Solana, más allá del interés de cualquier proveedor concreto.
I+D y mejora continua de infraestructura específica para Solana
Detrás de ERPC está la investigación y el desarrollo de infraestructura específica para Solana que ELSOUL LABO sigue persiguiendo. ELSOUL LABO ha sido aprobada durante cinco años consecutivos desde 2022 bajo WBSO, el programa gubernamental de apoyo a la I+D de los Países Bajos. Continúa la I+D en infraestructura de Solana RPC, operación de validadores, entrega de datos en tiempo real, y operación y desarrollo asistidos por agentes de IA, y esos resultados se reflejan en servicios como ERPC, SLV, SLV AI y el centro de datos específico para Solana AS200261. La publicación de este informe es, también, un esfuerzo que se desprende directamente de esta investigación y desarrollo continuos. ERPC seguirá publicando sus resultados de manera sistemática.
Uso y consultas
Para preguntas sobre el contenido de este informe, asesoramiento para mejorar la velocidad de tu propia configuración, ayuda en la selección de recursos o la planificación de una migración, o preguntas sobre benchmarks, por favor crea un ticket de soporte en el Discord oficial de Validators DAO.
How to be faster on Solana? (el informe): https://erpc.global/es/how-to-be-faster/
Panel de ERPC: https://dashboard.erpc.global/es
Sitio oficial de ERPC: https://erpc.global/es
Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
Agradecemos sinceramente a todos nuestros usuarios su uso continuado de ERPC.
Enlaces
- How to be faster on Solana? (el informe): https://erpc.global/es/how-to-be-faster/
- Sitio oficial de ERPC: https://erpc.global/es
- Panel de ERPC: https://dashboard.erpc.global/es
- Precios de ERPC: https://erpc.global/es/price/
- Sitio oficial de SLV: https://slv.dev/es
- SLV GitHub: https://github.com/validatorsDAO/slv
- Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
Noticias
