Gana el juego de los milisegundos: shreds, LaserStream y la ventaja en Solana

¿Qué son los shreds?

Los shreds son la unidad fundamental que permite la propagación de datos de alto rendimiento en Solana y ofrece acceso anticipado a los cambios de estado on-chain.

Solana está diseñada para maximizar la velocidad y el rendimiento. Para lograrlo, no puede transmitir bloques como una sola unidad de gran tamaño por toda la red. En cambio, los bloques se dividen en paquetes más pequeños llamados shreds: las unidades atómicas de propagación de datos en Solana.

Estos shreds representan partes de los datos de las transacciones antes de ensamblarse en un bloque. Cada shred tiene un tamaño aproximado de 1.2 KB y está optimizado para caber en la Unidad Máxima de Transmisión (MTU) de los paquetes de red estándar. Esto garantiza una entrega ultrarrápida sin fragmentación.

Hay dos tipos de shreds:

Shreds de datos

Los shreds de datos encapsulan los datos principales de las transacciones de un bloque, divididos en piezas de tamaño fijo. Incluyen lotes de entradas serializadas, que son grupos de transacciones precedidos por un conteo para permitir un procesamiento eficiente.

Shreds de codificación

Los shreds de codificación proporcionan redundancia mediante la codificación de borrado Reed-Solomon, una técnica de corrección de errores hacia adelante que genera datos de paridad. Esto permite reconstruir los shreds faltantes o dañados. Los shreds de codificación se organizan en conjuntos de corrección de errores hacia adelante (FEC) junto con los shreds de datos, normalmente en proporciones equilibradas (por ejemplo, 32 shreds de datos por 32 shreds de codificación) para tolerar hasta un 50 % de pérdida de paquetes. Los líderes pueden ajustar esta proporción según las condiciones de la red para mantener una alta confiabilidad.

¿Cómo se propagan los shreds en Solana?

El proceso comienza cuando el líder (es decir, el validador responsable en ese momento de producir bloques) agrupa y serializa las transacciones en entradas. Luego, estas entradas se dividen, o descomponen, en segmentos más pequeños llamados shreds. El líder firma todos los shreds mediante un sistema heredado (es decir, firma cada shred de forma individual) o un esquema basado en Merkle (es decir, firma la raíz de Merkle de todo el conjunto FEC), según lo define la especificación de shreds de Solana. Esto garantiza la autenticidad y la integridad de los datos.

Los shreds se envían a otros validadores mediante Turbine, el sistema de propagación multicapa basado en fan-out de Solana. Con Turbine, el líder transmite los shreds a un nodo raíz, que los distribuye a las capas posteriores de validadores en una estructura de árbol. Cada capa los reenvía a la siguiente con un fan-out de 200 nodos por capa. Por lo general, se recorren entre 2 y 3 saltos, según el número de validadores activos. Esta estructura de árbol minimiza el ancho de banda y distribuye las transacciones por toda la red en milisegundos.

La distribución ponderada por stake prioriza la entrega a los validadores con más stake. Turbine primero ordena los validadores según la cantidad de stake que poseen (es decir, su ponderación de stake). Los validadores con más stake aparecen antes en esta lista y, después de una mezcla determinista, suelen quedar en las primeras capas del árbol, más cerca del líder. Por lo tanto, menos saltos significan menor latencia. Así, los validadores con más stake reciben los shreds antes.

Nota: Turbine será reemplazado por Rotor en el futuro, una vez que se implemente Alpenglow. Incluso con estos cambios, el stake de un validador seguirá influyendo en los pares a los que transmitirán los validadores.

¿Cómo se vuelven a ensamblar los shreds en bloques?

Cuando un validador recibe los shreds, primero verifica sus firmas para confirmar su autenticidad y usa la codificación de borrado Reed-Solomon para reconstruir cualquier shred de datos faltante o dañado a partir de los shreds de codificación disponibles en el conjunto FEC.

Luego, los shreds de datos reconstruidos se descomponen. Es decir, sus cargas útiles se concatenan en orden mediante los índices de los shreds para volver a formar lotes de entradas serializadas.

Después, estos lotes se deserializan en transacciones y entradas individuales, que pueden ensamblarse en un bloque completo.

¿Por qué importan los shreds?

Los shreds importan porque reducen la ventana de reacción en una red donde el tiempo es fundamental.

Los shreds son cruciales para aprovechar las ventajas de alto rendimiento de Solana, en especial en aplicaciones sensibles a la latencia, como el trading de alta frecuencia, las mesas de solicitud de cotización (RFQ), los motores de liquidación y las actualizaciones de oráculos.

Los shreds ofrecen la primera visibilidad de los eventos on-chain emergentes. Esto contrasta con la mayoría de las demás blockchains, donde las aplicaciones deben esperar a que se complete la producción y confirmación del bloque, lo que puede añadir demoras de cientos de milisegundos a varios segundos.

Puede ser complicado trabajar con shreds sin procesar, ya que el receptor debe verificar su autenticidad, reconstruir los shreds de datos faltantes, descomponerlos y deserializarlos en transacciones y entradas y, por último, analizarlos para detectar eventos que requieran una acción, como swaps o cambios de cuentas.

Si quieres la ventaja de latencia de los shreds sin crear ese pipeline, Preprocessed Transactions los descompone por ti y transmite las transacciones firmadas por WebSocket hasta 8 ms antes del nivel de compromiso processed.

Sin embargo, este “vistazo anticipado” a las transacciones y actualizaciones de cuentas pendientes ofrece una ventaja incomparable que se traduce directamente en mayores tasas de éxito en escenarios competitivos.

Por ejemplo, un bot de liquidación que monitorea proporciones de garantía podría detectar una posición vulnerable mediante shreds y actuar mucho antes que sus competidores, que usan métodos más lentos como WebSockets. Así podría ganar la liquidación.

Del mismo modo, los traders de arbitraje que identifican ineficiencias del mercado y los agregadores DEX de baja latencia que cotizan precios pueden beneficiarse de esta ventaja de latencia, ya que los milisegundos determinan la rentabilidad.

La jerarquía de latencia de los shreds

Es importante señalar que la latencia de los shreds no es uniforme en todas las fuentes.

Validadores con mucho stake

Los validadores con una cantidad significativa de stake reciben la máxima prioridad en el árbol de propagación de Turbine. A menudo reciben shreds directamente del líder o en las primeras capas de fan-out, y se benefician de la calidad de servicio ponderada por stake (SWQoS).

Validadores con stake

Los validadores con una cantidad moderada de stake experimentan demoras moderadas debido a su menor prioridad en la cola de propagación, ya que los shreds deben recorrer saltos adicionales. Su participación en el consenso garantiza un acceso confiable, aunque la latencia puede variar ligeramente según la posición en la red y la distribución actual del stake. En comparación con los validadores con mucho stake, los validadores con poco stake no son ideales para operaciones muy competitivas y sensibles al tiempo.

Validadores sin stake

Los validadores sin stake no tienen las ventajas de calidad de servicio de los nodos con stake y no son adecuados para transmitir datos de Solana en tiempo real en operaciones críticas para la latencia. Son los últimos en recibir los shreds dentro del fan-out de Turbine.

Cuanto antes estés en el árbol, más tiempo tendrás para reaccionar antes de que el resto de la red se ponga al día.

Variabilidad global

Es importante destacar que Turbine no depende de la ubicación. La propagación global puede aumentar la variabilidad de la latencia, ya que la distancia física y las condiciones de la red introducen demoras adicionales a los saltos de Turbine.

Por ejemplo, los shreds que viajan entre regiones (como desde un líder ubicado en Estados Unidos hasta validadores de Asia-Pacífico) pueden experimentar demoras debido al enrutamiento entre continentes, las retransmisiones de paquetes o incluso problemas de peering, aun en el caso de validadores con mucho stake en las primeras capas de Turbine.

Esta distribución geográfica crea oportunidades de optimización. Aunque un solo validador con mucho stake puede sobresalir a nivel local, podría quedar rezagado globalmente si no está en una ubicación óptima. Una red distribuida de shreds podría mitigar este problema al reunir los shreds más rápidos posibles de distintas fuentes, reducir la variación y lograr velocidades de recepción constantes. Un sistema de este tipo podría superar de forma consistente a un validador con el máximo stake en escenarios globales.

Acceder de forma confiable a shreds desde fuentes optimizadas es esencial para que los desarrolladores de sistemas críticos para la latencia mantengan una ventaja competitiva. Sin embargo, esto requiere una infraestructura sólida que gestione de forma eficaz la recuperación, la verificación y la distribución global. Además, la mayoría de las herramientas populares de streaming de datos en tiempo real de Solana todavía no aprovechan los shreds.

Streaming de datos en Solana

En Solana, los desarrolladores que quieren transmitir datos en tiempo real tienen varias opciones, cada una con sus propias ventajas y desventajas en cuanto a latencia, confiabilidad y complejidad:

Webhooks

Los webhooks permiten actualizaciones basadas en eventos y envían datos a tu aplicación cuando ocurren cambios en una cuenta o un programa específicos. Son fáciles de integrar mediante programación e incluso puedes configurarlos sin escribir código directamente en el panel de Helius. Los desarrolladores pueden transmitir datos analizados y legibles para humanos de tipos específicos de transacciones, cargas útiles de transacciones sin procesar e incluso enviar estas actualizaciones directamente a un canal específico de Discord como un mensaje con formato.

Aunque los webhooks son muy confiables y muchas empresas reconocidas de Solana los usan, envían notificaciones después de que se confirma una transacción. Esto significa que los webhooks pueden estar cientos de milisegundos por detrás de los datos a nivel de shred, por lo que son demasiado lentos para operaciones críticas para la latencia, como el trading de alta frecuencia o las liquidaciones.

WebSockets estándar

La API JSON RPC de Solana admite suscripciones de WebSocket, como accountSubscribe para cambios en cuentas, logSubscribe para registros de transacciones y programSubscribe para eventos de programas. Los WebSockets mantienen una conexión persistente entre un cliente y un proveedor de RPC, y transmiten actualizaciones en cuanto se procesan las transacciones y los cambios en cuentas. Los WebSockets son bidireccionales y adecuados para monitorear cuentas o eventos específicos en tiempo real, a la vez que reducen la sobrecarga del sondeo.

Sin embargo, al igual que los webhooks, los WebSockets entregan los datos después de volver a ensamblar los shreds (es decir, en los niveles de compromiso processed, confirmed o finalized), lo que añade entre 400 ms y 30 s de latencia, según el nivel de compromiso.

Los WebSockets también se consideran un tipo de conexión frágil. Esto significa que las conexiones pueden interrumpirse por una gran variedad de problemas que requieren una lógica personalizada de reintentos. Las desconexiones pueden provocar una pérdida permanente de datos, a menos que se complementen con sondeo, lo cual perjudica la confiabilidad en tiempo real.

Enhanced WebSockets

Enhanced WebSockets supone una mejora importante frente a los WebSockets estándar, ya que ofrece varias optimizaciones de rendimiento y capacidades de filtrado mejoradas. En concreto, un mejor análisis de eventos y menos ruido hacen que sea más fácil de usar para desarrolladores en producción.

Enhanced WebSockets puede reducir la latencia frente a los WebSockets estándar y es excelente para aplicaciones generales de streaming. Por ejemplo, existe una diferencia de rendimiento notable al transmitir datos de Pump AMM con Enhanced WebSockets, en comparación con los WebSockets estándar y los webhooks.

Sin embargo, Enhanced WebSockets sigue entregando los datos después de volver a ensamblar los shreds. Esto limita su utilidad para aplicaciones donde cada milisegundo cuenta. Además, aunque ofrece mejoras, carece de reproducción o conmutación por error automáticas, por lo que debes gestionar manualmente las interrupciones.

Yellowstone gRPC

Yellowstone gRPC es un protocolo de streaming de baja latencia entre validadores y clientes que puede proporcionar acceso a datos a nivel de shred. Esto lo hace mucho más rápido que los WebSockets y los webhooks, ya que puede entregar actualizaciones con mayor rapidez para el nivel de compromiso correspondiente.

Yellowstone ofrece streaming bidireccional con creación y cancelación inmediatas de suscripciones, además de capacidades avanzadas de filtrado para controlar con precisión qué datos recibes en respuesta a actualizaciones específicas de transacciones, cuentas o programas.

Yellowstone es ideal para quienes no quieren límites de velocidad ni créditos y necesitan hardware aislado garantizado para configuraciones de nodos personalizadas. Sin embargo, tiene varias desventajas importantes:

1. Carga de infraestructura

Necesitas tu propio nodo dedicado para aprovechar todo el potencial de Yellowstone gRPC. Esto requiere acceso a hardware, una configuración adecuada, la administración continua de ese hardware y conocimientos especializados para depurar cualquier problema relacionado con él.

2. Variabilidad de la latencia

El hecho de que Yellowstone gRPC pueda entregar datos a nivel de shred no significa que lo haga de la forma más óptima. La latencia puede variar según tu proveedor y según si tu nodo dedicado está emparejado con fuentes optimizadas para shreds (es decir, validadores con mucho stake). Si se empareja con validadores con un stake moderado o bajo, estos no llegarán de forma constante a la primera capa de Turbine, por lo que seguirás recibiendo muchos shreds más tarde.

3. Riesgos de fallas

Depender de un solo nodo dedicado crea un único punto de falla, problema que se agrava porque Yellowstone gRPC no cuenta con funciones nativas de reproducción.

4. Demanda de recursos

Sobrecargar un nodo dedicado con llamadas RPC intensivas mientras transmites datos mediante Yellowstone puede degradar el rendimiento.

Durante mucho tiempo y para muchos equipos, Yellowstone gRPC ha sido el servicio de streaming preferido para obtener datos en tiempo real en Solana. Es rápido y adecuado para usuarios avanzados, pero es difícil operarlo para lograr una cobertura global, uniforme y de baja latencia sin acceso a una flota de nodos dedicados en todo el mundo.

LaserStream

LaserStream combina la velocidad de la recepción a nivel de shred con la confiabilidad y el alcance de un servicio distribuido globalmente, sin el costo ni la carga operativa de ejecutar varios nodos dedicados.

LaserStream lo consigue mediante:

• Recepción desde múltiples fuentes: LaserStream recibe los shreds con menor latencia y supera de forma constante a sus competidores en todo el mundo.
• Cobertura global: LaserStream está disponible en varias regiones del mundo, lo que permite a los desarrolladores usar el endpoint más cercano a su infraestructura. Cada región ejecuta varios servidores para ofrecer redundancia, con conmutación por error automática.
• Sin interrupciones: La reproducción histórica de LaserStream permite a los desarrolladores reproducir datos recientes de la blockchain de hasta 48 horas atrás. Esto resulta útil para gestionar desconexiones y garantizar la continuidad de los datos.
• Una experiencia fácil para desarrolladores: LaserStream sustituye directamente a Yellowstone gRPC, sin migraciones, sintaxis nueva ni complicaciones.

En pocas palabras, LaserStream es una mejora escalable, de baja latencia y tolerante a fallas frente a Yellowstone gRPC y WebSockets. Proporciona eventos on-chain de forma constante en cuanto ocurren en la red, sin que necesites millones en stake ni operar por tu cuenta infraestructura de alto rendimiento.

LaserStream es la forma más fácil de aprovechar el poder de los shreds para transmitir datos con latencia ultrabaja en Solana.

Clientes y rendimiento

LaserStream tiene clientes disponibles en Go, Rust y JavaScript/TypeScript. Estos clientes gestionan la reproducción automática después de las desconexiones, ya que registran de forma continua qué slot se transmitió. Si ocurre una desconexión por cualquier motivo, el cliente vuelve a conectarse automáticamente y reanuda el streaming desde el último slot procesado.

El cliente JavaScript de LaserStream es especialmente interesante porque usa enlaces nativos de Rust. Gracias a esto, el cliente alcanza un rendimiento de 1.3 GB/s. Esto supone una mejora de 40 veces frente al cliente JavaScript actual de Yellowstone gRPC, cuyo máximo es de 30 MB/s.

A medida que Solana siga escalando, el cliente JavaScript de Yellowstone gRPC tendrá dificultades para mantener el ritmo. El margen de rendimiento del cliente JavaScript de LaserStream garantiza que tu aplicación pueda escalar de forma segura junto con la red a medida que aumenta la demanda.

Resultados reales

DFlow, un agregador DEX de baja latencia, integró recientemente LaserStream para alimentar su motor de precios. Decidió integrarlo por la capacidad de escalar globalmente sin preocuparse por nodos dedicados y por el ahorro de recursos de ingeniería, que puede dedicar al enrutamiento y al código de negocio.

Desde la integración, DFlow ha ahorrado más de ocho horas de trabajo recurrente de ingeniería, ha mantenido un 100 % de disponibilidad con streaming de datos ininterrumpido y ha mejorado la velocidad de las cotizaciones gracias a confirmaciones de transacciones más rápidas.

Streaming más rápido, hoy.

Los milisegundos no son solo latencia: son oportunidades. Con LaserStream, no solo sigues el ritmo de la red. Te mantienes por delante.

¿Quieres datos en menos de un segundo para trading, liquidaciones u oráculos? Usa LaserStream y accede a los datos de Solana más rápidos disponibles.

Como alternativa, si eres un usuario avanzado y te interesa la entrega de shreds sin procesar, comunícate con nosotros completando el siguiente formulario.

Recursos adicionales

• LaserStream
• Módulo de shreds de Agave
• Especificación de shreds de Solana