Solana, ahora mismo

¿Cómo ser más rápido en Solana?

Si construyes en Solana, seguro has dicho alguna de estas.

  1. Misma estrategia que la mesa de al lado — solo a mí el bot me entra tarde.

  2. Aparece el precio. Disparo la orden. Mi transacción se queda fuera.

  3. He probado todos los proveedores de RPC, y nada cambia.

Lo que ni el mejor ajuste

Has afinado el código. Has mejorado el hardware. Ninguno es el cuello de botella: persigues a un leader que no para de moverse, y desde demasiado lejos.

El hardware y el código, por sí solos, no ganan el slot. El slot se gana por timing y por ubicación.

La velocidad se compra. Entenderlo es la ventaja.

Mira cómo llegar primero

El blanco móvil

El lugar más rápido nunca se queda quieto.

En cada slot —los ~400 ms que Solana dedica a formar un bloque— un validator distinto se convierte en leader, y gana quien esté más cerca de él.

A diferencia de un punto fijo junto al que acampas una vez, en Solana el mejor asiento nunca es el mismo dos veces.

~400 ms · un leader nuevo en cada slot

El asiento más rápido, slot a slot

El leader rota por el mundo, slot a slot. Ganas uno y el siguiente ya está en otra parte.

Míralo moverse

Solana RPC, Geyser gRPC y Shredstream mejorados

Epoch —

0.00%— validators
SOL

— countries

Leader

Productor de bloques en vivo

Slot

La distancia es latencia

Cruza un continente y te quedas 100–300 ms atrás.

La luz por la fibra y una hilera de routers fijan un mínimo que ningún hardware puede rebajar. En el mismo rack, unos 0,1 ms. Al otro lado de un océano, 100–300 ms, y un slot apenas dura 400 ms.

Si el leader te queda en la puerta, estás dentro de la ventana; si está en el otro hemisferio, ya lo has perdido. Ser rápido en cada slot es estar cerca caiga donde caiga el leader.

Mínimo de ida y vuelta según la distancia · es física, no un benchmark

Lo que la distancia le cuesta a un paquete

Misma red
0.1 ms
Mismo datacenter
0.3 ms
Misma ciudad
1 ms
País vecino
5–10 ms
Entre continentes
100–300 ms

Cruzar un continente es cientos de veces más lento que un salto dentro del mismo rack, y más que un slot entero. La cercanía no es un retoque: es el presupuesto.

Cobertura — por qué una sola ciudad no basta

Ni la ciudad más saturada llega a una cuarta parte de la red.

Frankfurt es donde se amontonan los operadores, y aun así la ciudad más concurrida reúne apenas una cuarta parte de la red, tanto en validators como en stake. En la mayoría de los slots, el leader de turno está en otro lado.

Cubrirlo todo es lo ideal; el presupuesto te obliga a elegir. La pregunta no es solo quién es el más grande, sino quién tiene menos máquinas amontonadas: el menos disputado. Ámsterdam reúne un stake comparable al de Frankfurt con muchos menos validators encima: suele ser el asiento más tranquilo, y el mejor.

Dónde se ubican los validators de Solana

validatorsstake

Cobertura — un nodo ya pegado a cada leader

Caiga donde caiga el leader, ya hay ahí un nodo potente y conectado directo a Solana.

El rol de leader recorre el mundo slot a slot, así que el nodo que gana es el que ya está más cerca. Un nodo en la misma región se ahorra el salto de larga distancia que mete el retraso.

Por eso no apostamos por un solo lugar. La velocidad sostenida se consigue estando cerca en cada slot, y como el leader salta de región en región, eso exige cobertura por regiones. Operamos nodos de grado validator donde se concentra el stake de Solana, sobre una misma red de baja latencia, y no paramos de sumar regiones: cada región nueva son más slots en los que ya estás pegado al leader.

Salt Lake CityChicagoNueva YorkDublínLondresÁmsterdamFráncfortEstocolmoSingapurTokioSídney

Global Data Center Partner

La velocidad está determinada por la distancia a Solana.

La región importa. Pero el nombre de una ciudad por sí solo no es una ruta de red. Incluso en la misma ciudad, el tránsito externo y los saltos adicionales pueden aumentar la latencia. ERPC selecciona centros de datos cercanos a los servidores Solana y luego mantiene las rutas cortas sin tránsito externo y con un turbo boost sostenido.

Ruta premium ERPC

sin tránsito externo

RTT mínimo

0,1ms

Elección solo por el nombre de la ciudad

tránsito externo / 7 saltos

70 veces más lento

7ms
  • 01Mismo centro de datosElige primero la región, luego el centro de datos más cercano a Solana.
  • 02Sin tránsito externoEvita rutas AS externas para mantener bajos el RTT y la variación.
  • 03Acelerador a fondoERPC excluye los perfiles de ahorro de energía y mantiene los recursos en un turbo boost sostenido.

Prioridad ponderada por stake (SWQoS)

Si tus transacciones fallan una y otra vez, estás atascado en el carril del spam.

Los leaders de Solana dividen en dos el ancho de banda prioritario. Las conexiones con stake detrás —SOL comprometido con un validator— se quedan el 80%. El resto se pelea por el otro 20%, el carril atascado de spam.

Disparar directo al leader parece la jugada rápida, pero sin stake ese es el carril saturado del 20%, y bajo carga tu transacción nunca entra en el bloque.

Así que la respuesta de verdad es un validator con stake. Operamos uno de primer nivel conectado a líneas RPC de alta calidad —hardware puesto justo al lado de Solana— para que tus transacciones pasen por el carril ancho.

Un validator de primer nivel en nuestro Shinobi Performance Pool

Cómo reparten los leaders de Solana el ancho de banda prioritario

Con stake · 80% · libre ✓
txel leader
el bloque
Sin stake · 20% · saturado ✕

El stake entra al validator por el carril ancho del 80%, antes de cualquier fee. Sin stake, te aprietas en el carril del spam del 20%.

El reparto 80 / 20 lo fijan los leaders de Solana, no nosotros

Benchmark medido

Máquina de la misma clase. No la misma velocidad.

AMD Turin, 4 vCPU, Ámsterdam, Ubuntu 24.04: lo mismo en ambas máquinas, una de una gran nube y la nuestra. La ficha técnica dice que son iguales. El benchmark dice otra cosa.

El mismo silicio. La diferencia es nuestro ajuste: la máquina afinada y colocada justo al lado de Solana.

node_bench · misma ejecución, misma región

ERPC frente a una gran nube · mismas specs

Cómputo de CPUsysbench · 4 hilos · más es mejor
1.9×
ERPC
7,850
Cloud
4,062

events/s

Ancho de banda de memoriaSTREAM Triad · 4 GiB · más es mejor
3.2×
ERPC
151,986
Cloud
47,943

MB/s

IOPS de discofio · 4K randread · QD32 · más es mejor
16.6×
ERPC
50,675
Cloud
3,061

IOPS

Latencia de disco · p99fio · 4K randread · QD32 · menos es mejor
25.7×
ERPC
668
Cloud
17,170

µs

Todo el entorno, al máximo nivel.

ERPC afina cada capa entre tú y el slot —RPC, streaming, validators, el bare metal de debajo— y lo coloca todo junto a Solana. Antes, integrar todo eso era cosa tuya. Ahora basta con combinar nuestros productos: la línea más rápida hacia Solana.