Cómo funcionan los streams de datos y protocolos de Solana (Shreds, gRPC, WebSocket y UDP)
Al plantearse cómo acelerar una aplicación de Solana o una estrategia de trading, lo primero que debe aclararse no es el código ni las especificaciones del servidor.
El punto de partida son dos preguntas fundamentales.
En primer lugar, ¿a qué distancia están los validadores de Solana relevantes?
¿En qué región se encuentra realmente la aplicación y cuántos milisegundos tarda en llegar desde allí a un validador? Esta distancia es la base de todo. Si no es la adecuada, ninguna optimización de software o hardware permitirá alcanzar el rendimiento que debería ser posible.
En segundo lugar, ¿dónde está el validador líder en cada momento?
Cuando el líder está en Frankfurt, los nodos cercanos a Frankfurt tienen una ventaja estructural. Cuando está en Tokio, la tienen los nodos próximos a Tokio. Los líderes de Solana rotan por todo el mundo slot a slot. Mientras exista esta característica, una configuración de una sola región siempre atravesará periodos en los que estará físicamente en desventaja.
En la práctica, una estrategia realista debe ser multirregional.
Al distribuir la infraestructura entre Frankfurt, Ámsterdam, Nueva York, Chicago, Tokio y Singapur, se puede observar la cadena desde una región próxima al líder actual o al siguiente en cada franja horaria.
Una vez establecido este contexto físico y temporal, podemos hablar de los streams de datos de Solana. Este artículo se centra en tres que los desarrolladores encuentran con frecuencia:
- WebSocket (WS)
- Geyser gRPC
- Shredstream (Shreds por UDP)
Veremos en qué momento recibe los datos cada uno, qué características tiene su transporte y para qué sirve realmente.
El objetivo no es elegir uno porque «su nombre suene rápido», sino comprender cómo funciona Solana y cómo se comportan los protocolos subyacentes para relacionarlos de forma concreta con el rendimiento de la aplicación y la UX.
Diferencias temporales en el flujo de datos de Solana
El primer paso consiste en comprender cuándo aparecen realmente los distintos tipos de datos dentro del pipeline interno de Solana.
A grandes rasgos, resulta útil pensar en tres etapas para analizar el rendimiento.
La primera etapa son los Shreds.
Los validadores intercambian Shreds por UDP para construir bloques. Durante este intercambio circulan por la red datos que todavía no se han ensamblado por completo en un bloque. Acceder a esta etapa permite observar los cambios de la cadena lo antes posible. Como contrapartida, al utilizar UDP hay que asumir pérdidas de paquetes y llegadas desordenadas, y diseñar el sistema en consecuencia.
La segunda etapa es Geyser gRPC.
Después de recibir los Shreds y formar y confirmar un bloque, un validador puede exponer los resultados de forma estructurada mediante plugins Geyser. De ahí proceden los streams Geyser gRPC, que emiten eventos como bloques, registros y actualizaciones de cuentas. Llegan una etapa después que los Shreds, pero los datos ya están organizados y resultan mucho más fáciles de consumir para las aplicaciones.
La tercera etapa comprende HTTP RPC y WebSocket.
Una vez que los datos han pasado por Geyser y otros procesos internos y se han escrito en el almacenamiento del nodo, quedan disponibles mediante JSON-RPC y notificaciones WebSocket. Métodos como getBalance y getProgramAccounts, así como las suscripciones a registros, leen ese estado almacenado. Desde el punto de vista temporal, esta etapa se sitúa detrás de las notificaciones de Geyser y constituye la capa superior de «API pública» que la mayoría de las aplicaciones ve primero.
En resumen:
- Los Shreds son datos en bruto muy próximos al momento de propagación.
- Geyser gRPC ofrece datos estructurados en el momento de confirmar los bloques.
- RPC / WebSocket exponen datos almacenados como API que se consultan a posteriori.
La etapa observada determina con cuánta antelación pueden detectarse los cambios de la cadena. Esta diferencia temporal ya crea por sí sola una brecha considerable de rendimiento.
Características de transporte: UDP, gRPC, WebSocket y TLS
El momento de recepción es un eje. El segundo es la forma en que se transportan los datos.
Los Shreds utilizan UDP.
UDP tiene cabeceras pequeñas y no exige establecer una conexión. No garantiza la retransmisión ni el orden, pero a cambio reduce la latencia al mínimo. Para los Shreds, que se propagan de forma redundante entre numerosos validadores, esa sencillez y rapidez es justamente lo que se necesita.
Geyser gRPC funciona sobre TCP con un protocolo binario.
El streaming RPC, la compresión de cabeceras y la codificación binaria permiten mover datos con más eficiencia que HTTP+JSON convencional. Es adecuado para consumir de forma continua eventos estructurados en backends, sistemas de monitorización y pipelines de análisis.
WebSocket suele funcionar sobre TCP y TLS con payloads JSON.
Su principal ventaja es que los navegadores y las pilas web habituales pueden utilizarlo directamente, de ahí su presencia generalizada en dApps y bots ligeros. Como desventaja, hay que analizar el texto JSON, y las cabeceras y el cifrado añaden sobrecarga. De los tres, suele ser el patrón más pesado.
Además, TLS añade otra capa de coste.
Al utilizar HTTPS, WSS o gRPC-TLS, cada conexión debe realizar un handshake y cifrar y descifrar los payloads. En aplicaciones web generales suele ser aceptable e imperceptible. En estrategias donde unas decenas de milisegundos importan para la UX o el PnL, la sobrecarga sí se aprecia.
Lo importante es que:
- El momento en que se ven los datos (Shreds / Geyser / RPC)
- La forma de transportarlos (UDP / gRPC / WebSocket / TLS)
son cuestiones distintas, pero ambas influyen mucho en la latencia final y la UX.
La velocidad en contexto: tiempo y transporte
Con estas piezas se puede razonar sobre la velocidad de forma más concreta.
Desde el punto de vista temporal:
- Los Shreds observan la etapa más temprana.
- Geyser gRPC llega a continuación.
- RPC / WebSocket llegan al final.
Desde el punto de vista del transporte:
- UDP es el más ligero y rápido.
- Le sigue gRPC sobre TCP, con streaming binario eficiente.
- WebSocket con JSON y TLS suele ser el más pesado.
Si se igualan la región, el hardware y la ruta de red, el orden técnico de velocidad es:
- UDP (Shreds)
- gRPC (Geyser)
- WebSocket (notificaciones JSON-RPC)
Por supuesto, esta es la velocidad de forma aislada. En sistemas reales no puede considerarse solo la latencia: también importan la fiabilidad, los requisitos de corrección, el coste de desarrollo y la complejidad que el equipo pueda asumir.
Fiabilidad y coste de desarrollo: por qué en la práctica WS > gRPC > UDP
En muchos proyectos reales, el orden de adopción de los streams de datos es casi el inverso de su clasificación técnica por velocidad:
- Primero WebSocket
- Después Geyser gRPC
- Por último Shreds / UDP
No es casualidad.
Los Shreds (UDP) son los más rápidos, pero obligan a diseñar desde el principio para datos ausentes o desordenados.
No puede suponerse que todos los paquetes lleguen ni que los datos estén perfectamente alineados. La lógica debe gestionar huecos, conciliarse con otros streams cuando sea necesario y tolerar ruido. A cambio se obtiene la mínima latencia, pero la implementación y la operación son claramente más difíciles.
Geyser gRPC entrega datos que ya se han confirmado y estructurado dentro del nodo.
Esto facilita mucho su consumo. Los backends orientados a eventos, sistemas de alertas, análisis on-chain e indexadores pueden basarse en Geyser con un buen equilibrio entre velocidad, fiabilidad y esfuerzo de implementación. Para muchos equipos es el segundo paso natural cuando una configuración basada solo en WebSocket alcanza sus límites.
La principal ventaja de WebSocket es su integración directa con los navegadores y la infraestructura web habitual.
Los frontends de dApps y los servicios ligeros pueden utilizarlo con herramientas y bibliotecas existentes, y hay numerosos ejemplos de código. Para lanzar la primera versión de un producto, WebSocket suele ser el punto de partida más práctico, sobre todo si ya se ha resuelto la «distancia a los validadores».
Por tanto, el orden teórico de velocidad es UDP > gRPC > WS.
En la práctica, el orden de adopción suele ser WS > gRPC > UDP.
Hay que tener presentes ambos ejes y elegir según la fase y los objetivos actuales, en lugar de perseguir una etiqueta abstracta de «más rápido».
Cómo se complementan Shreds y Geyser gRPC
Cuando se supera el ajuste básico de velocidad y empieza a importar cada decena de milisegundos, la cuestión esencial es cómo combinar Shreds y Geyser gRPC.
Los Shreds sirven para detectar primero.
Si se reciben cerca del líder actual, pueden revelar cambios on-chain entre decenas y cientos de milisegundos antes que Geyser o RPC por sí solos. En estrategias donde esa diferencia se traduce directamente en PnL, esto es muy importante. Como contrapartida, hay que aceptar el ruido y diseñar el sistema para gestionarlo.
Geyser gRPC sirve para confirmar y razonar correctamente.
Al confirmar el bloque, Geyser emite registros, cambios de cuentas y otros eventos estructurados. Estos pueden alimentar la lógica de estrategia, los controles de riesgo, los indexadores y los sistemas de monitorización. Es más lento que Shreds, pero los datos son coherentes y mucho más fáciles de interpretar.
Un patrón habitual consiste en:
- Utilizar Shreds para detectar oportunidades y preparar transacciones candidatas con la máxima rapidez.
- Utilizar Geyser gRPC en paralelo para verificar bloques y registros y alimentar la lógica principal y la monitorización.
Esta separación permite reducir la latencia sin dejar de fundamentar las decisiones en datos estables y verificables.
TLS, endpoints compartidos y nodos dedicados
Hasta ahora hemos supuesto que el nodo y la red subyacentes eran los mismos. En realidad existe otra gran diferencia estructural: utilizar un endpoint compartido o un nodo dedicado.
Un endpoint compartido lo utilizan muchos tenants a la vez.
Está expuesto a la internet pública y el tráfico atraviesa un perímetro de seguridad. El cifrado es obligatorio; no puede desactivarse TLS sin más. El coste del cifrado, el descifrado y los handshakes resulta perfectamente aceptable para una dApp convencional, pero se hace visible cuando se intenta recortar cada milisegundo posible en un contexto de HFT.
Un nodo dedicado se reserva para un solo tenant.
Como es posible restringir el acceso por dirección IP y aislar el entorno, se puede desactivar TLS y utilizar HTTP o gRPC sin cifrar. Tampoco se comparten la CPU, la memoria, las operaciones de E/S de disco ni el ancho de banda con otros clientes, por lo que la latencia no oscila porque otra persona ejecute una carga pesada en la misma máquina.
Si Shreds, Geyser gRPC y RPC funcionan íntegramente en nodos dedicados, todos estos streams operan en un entorno aislado de otros tenants y de la sobrecarga de TLS.
Esta combinación permite a las configuraciones dedicadas alcanzar rangos de latencia que los endpoints compartidos no pueden lograr por diseño, ni siquiera con el mismo hardware.
Los nodos compartidos existen para ofrecer un rendimiento sólido a numerosos usuarios.
Los dedicados existen para llevar el rendimiento al límite cuando realmente se necesita la ruta más rápida posible.
Shreds dedicados y multirregionales (UDP Forwarding)
Volviendo a la distancia y la posición del líder, mientras los líderes de Solana roten por todo el mundo, una configuración de una sola región nunca podrá ser la más rápida en todo momento y lugar.
Aquí entran en juego las configuraciones Shreds multirregionales.
Dedicated Shreds (Premium Shreds, Standard Shreds, Metal Shreds, Limited Editions y líneas similares) combina:
- Entrega de Shreds por UDP con la máxima rapidez
- Servidores dedicados con un jitter mínimo
Al desplegar Dedicated Shreds en varias regiones, como Frankfurt, Ámsterdam, Nueva York, Chicago, Tokio y Singapur, se pueden recibir Shreds cerca del líder con independencia de la región favorecida en cada momento.
Un patrón habitual consiste en suscribirse simultáneamente a varios feeds de Shreds de distintas regiones y actuar solo sobre el que llegue primero.
Así se reduce el efecto de la latencia de larga distancia y la congestión regional, y se logra una aproximación práctica a «estar siempre cerca del líder».
Para facilitar el acceso a Dedicated Shreds multirregional, ERPC ofrece cupones de descuento por utilizar varias regiones:
- 2 regiones: 5 % de descuento
- 3 regiones: 8 % de descuento
- 5 regiones: 10 % de descuento
- Todas las regiones: 15 % de descuento
Esto facilita diseñar configuraciones que sitúen los niveles Shreds más premium —por ejemplo, Premium o Metal— en las regiones más competitivas y utilicen opciones más rentables en las regiones de apoyo, sin renunciar a una cobertura amplia.
Shared Shredstream Bundle: una puerta de entrada más amplia a Shreds
Antes de comprometerse con Dedicated Shreds en todas las regiones, una configuración Shared Shredstream multirregional puede ser un paso intermedio muy práctico.
Shared Shredstream Bundle permite consumir Shreds compartidos de varias regiones con un único plan.
Internamente, Shared Shredstream toma los datos de la capa Shreds (UDP) y los entrega mediante gRPC. La fuente sigue siendo Shreds, por lo que la información se observa una etapa antes que con Geyser gRPC, pero con la comodidad del streaming gRPC.
En cuanto al orden de las capas:
- Dedicated Shreds mediante UDP Forwarding es la opción más rápida y próxima a la propagación.
- Shared Shredstream es un stream gRPC derivado de Shreds y se sitúa justo por encima.
- Geyser gRPC llega después, en el momento de confirmar el bloque.
Los planes Shared Shredstream Bundle incluyen allowlist de IP, 10 conexiones y enrutamiento automático al edge más cercano. Esto mantiene un coste razonable y permite utilizar simultáneamente datos derivados de Shreds en Asia, Norteamérica y Europa.
En lugar de pasar directamente a Dedicated Shreds en todas las regiones, puede:
- Empezar con Shared Shredstream Bundle para adquirir experiencia práctica con datos basados en Shreds.
- Utilizar registros y datos de rendimiento para entender dónde aporta una diferencia mayor.
- Migrar las regiones de mayor impacto a Dedicated Shreds cuando disponga de pruebas y un caso de negocio claro.
Pasos prácticos según la fase de desarrollo
Al unir todas estas piezas, resulta más sencillo pensar por fases.
En la fase 1, elija la región y la distancia adecuadas y construya la dApp o el bot con RPC y WebSocket.
Acertar con la región y la ubicación de red suele aportar grandes mejoras de UX incluso antes de incorporar Shreds o gRPC. Para lanzar un producto, WebSocket es una opción muy sensata, sobre todo en el frontend.
En la fase 2, añada Geyser gRPC para reforzar los backends, la monitorización y el análisis.
Geyser gRPC permite consumir con eficiencia eventos de bloques, registros y cuentas y construir sobre ellos indexadores sólidos, sistemas de alertas y API externas. Ofrece un buen equilibrio entre velocidad, fiabilidad y coste de desarrollo, y constituye un «segundo paso» natural para muchos equipos.
En la fase 3, incorpore Shreds y UDP Forwarding cuando las diferencias de latencia afecten directamente al PnL o la UX.
Al desplegar Dedicated Shreds en varias regiones y utilizar descuentos multirregionales, se puede entrar en el rango de latencia que exigen HFT, MEV y las estrategias de 0-slot sin tener que diseñarlo todo de una vez desde cero.
La idea no es «UDP es teóricamente más rápido, así que utilice solo UDP en todas partes».
Lo importante es evaluar la fase y la economía del proyecto y decidir dónde y cuándo invertir en Shreds e infraestructura dedicada produce un efecto real.
ERPC Bundles y VPS como base
Los planes ERPC Bundle están diseñados para ofrecer una base completa:
- RPC (HTTP / WebSocket)
- Geyser gRPC
- Shared Shredstream gRPC
todo ello bajo una sola estructura.
Se puede seguir utilizando RPC y WebSocket como interfaz principal de producción mientras se experimenta con Geyser gRPC y Shredstream en la misma red.
Como todo funciona sobre una infraestructura unificada, es posible comparar directamente el comportamiento y el rendimiento y decidir a partir de mediciones reales, no de suposiciones.
Además, puede combinarse con gamas VPS alojadas dentro de la misma red de ERPC, como EPYC VPS y Premium Ryzen VPS.
Esto permite ajustar en un solo lugar:
- La distancia a los validadores de Solana
- La elección de streams de datos (WS, gRPC, Shreds)
- El rendimiento del hardware
Un enfoque práctico consiste en asegurar primero las regiones adecuadas y una base ERPC Bundle + VPS, y después activar capas más rápidas —Geyser, Shared Shreds y Dedicated Shreds— a medida que evolucionen las necesidades y la economía del proyecto.
Conclusión: diseñar el rendimiento de Solana desde el tiempo, el transporte y la distancia
El rendimiento y la UX de una aplicación de Solana dependen de una combinación de factores:
- La ubicación de los servidores
- La proximidad al líder en cada franja horaria
- El momento en que se reciben los datos on-chain
- El transporte y el protocolo utilizados
- La reacción de la lógica de la aplicación
La distancia y la posición del líder forman la base. A partir de ahí están:
- Shreds para la etapa más temprana
- Geyser gRPC para datos confirmados y estructurados
- RPC / WebSocket para acceder mediante API al estado almacenado
En cuanto al transporte:
- UDP
- gRPC sobre TCP
- WebSocket sobre TCP con JSON y TLS
No basta con elegir un stream o protocolo por su nombre o su marketing.
Hay que seleccionar una estructura adaptada al caso de uso según estos tres ejes: momento de recepción, características de transporte y distancia a los validadores pertinentes.
ERPC y Validators DAO proporcionan una red centrada en Solana, servicios RPC / gRPC / Shredstream, gamas VPS y descuentos multirregionales para Dedicated Shreds, de modo que estas estructuras puedan crearse a un coste realista y evolucionar a medida que crezcan las necesidades.
Si desea consultar sobre el diseño de streams de datos, la optimización de la distancia de red o combinaciones de Dedicated Shreds, Shared Shredstream Bundles, Bundles y VPS, contacte con nosotros a través del Discord de Validators DAO.
- ERPC: https://erpc.global/es
- SLV: https://slv.dev/es
- Epics DAO: https://epics.dev/es
- Discord de Validators DAO: https://discord.gg/C7ZQSrCkYR
