ERPC publica Solana Stream SDK v4.0.0 con un procesamiento de Shreds UDP y una reconexión gRPC más rápidos

ELSOUL LABO B.V. y Validators DAO publicaron oficialmente Solana Stream SDK v4.0.0 el 6 de noviembre de 2026. Este SDK de código abierto permite trabajar con los datos de streaming de Solana. Los benchmarks locales midieron un procesamiento interno de Shreds UDP en Rust aproximadamente 108 veces más rápido y un rendimiento de la cola de eventos de TypeScript aproximadamente 4 veces mayor. Geyser gRPC también reanuda antes la recepción de actualizaciones tras una desconexión. El SDK es gratuito y ofrece ejemplos en Rust y TypeScript para facilitar el inicio del desarrollo.

Aprovechar la entrega de datos de baja latencia en una aplicación también depende de la rapidez con la que se procesan los datos entrantes. La versión 4.0.0 hace más eficiente el procesamiento interno tras la llegada de los datos y mejora la recuperación de la conexión después de las desconexiones. Utilizarla junto con ERPC Shreds UDP Forwarding Premium permite a los desarrolladores mejorar tanto la ruta de entrega como la implementación de la recepción en sus aplicaciones Solana.

En la ruta de recepción UDP de Rust, la v4 acelera la decodificación de datagramas, la inserción en un búfer interno y el deshredding, que reconstruye los datos a partir de los Shreds. Reduce la sobrecarga de procesamiento al revisar la limpieza del estado interno y las lecturas del reloj que se repetían para cada paquete, manteniendo los períodos de retención de los datos. En la comparación, el tiempo de procesamiento interno por datagrama pasó de 94.236 ns a 855–881 ns, una aceleración de aproximadamente 108 veces.

El benchmark se ejecutó en un Mac con un chip de la serie M de Apple y procesó 403.200 datagramas de 300 slots en cada ejecución. Los resultados comparan las medianas de cinco ejecuciones. La medición abarca la ruta interna decode→insert→deshred. No incluye el tiempo de entrega por la red ni el procesamiento posterior en la aplicación del usuario. Reducir el trabajo necesario para reconstruir los Shreds entrantes ayuda a los desarrolladores a dedicar más recursos de cómputo a la lógica de la aplicación.

Los ejemplos y proyectos de inicio de Geyser gRPC en TypeScript reducen la espera mientras quedan eventos en la cola, lo que permite extraer los datos recibidos de forma más eficiente. En una prueba limitada a la cola que procesó dos millones de eventos con Node.js 24, el rendimiento pasó de 5,7–7,4 millones a 24,8–29,4 millones de eventos por segundo, una mejora de aproximadamente 4 veces.

En Geyser gRPC se han actualizado el cliente que gestiona la reconexión y el intervalo previo al primer reintento. En una prueba que provocó 20 desconexiones en un servidor tonic local, la mediana del intervalo entre las actualizaciones recibidas antes y después de cada desconexión bajó de 552 ms con el runner 3.0 a 103 ms con el runner 4.0. Esta medición refleja el intervalo hasta que se reanudan las actualizaciones en el entorno de pruebas local.

Estos tres resultados proceden de pruebas distintas, con alcances y condiciones diferentes. Muestran, respectivamente, las mejoras del procesamiento interno de Rust, la cola de eventos de TypeScript y la reconexión gRPC. Los detalles de implementación y las condiciones de las pruebas están disponibles en la PR #129, incluida en los enlaces relacionados.

La compatibilidad con Alpenglow se introdujo en la v3.0.0. La versión 4.0.0 mantiene la distinción entre los marcadores de bloque, que representan las actualizaciones de cabecera, pie y bloque padre, y las entradas, que contienen las transacciones. Las aplicaciones pueden gestionar la información sobre la estructura de los bloques por separado de las entradas que necesitan procesar.

La versión 4.0.0 actualiza los clientes a Agave 4.4.1 y Yellowstone gRPC 17.x. Durante la reconexión, un evento Disconnected puede notificar información que identifica los datos recibidos parcialmente, junto con la posición de reanudación. Esto proporciona a las aplicaciones la información necesaria para implementar su propio tratamiento de los datos retransmitidos duplicados y de los datos recibidos solo en parte.

La migración de v3 a v4 conserva las definiciones protobuf de Geyser, al tiempo que actualiza los eventos de reconexión y los tipos de mensajes y transacciones de Solana utilizados en Rust. La guía de migración publicada describe los cambios en los manejadores de eventos y en las versiones de las dependencias.

El paquete publicado de Rust solana-stream-sdk y el paquete de TypeScript @validators-dao/solana-stream-sdk están disponibles en la v4.0.0. Los lenguajes compatibles con cada tipo de conexión se indican a continuación.

Utilice el cliente Rust para recibir Shreds mediante UDP. El ejemplo y el proyecto de inicio de UDP en Rust utilizan el SDK v4.0.0 publicado y permiten probar la recepción de datos, su reconstrucción a partir de los Shreds y la detección de instrucciones de un programa que quiera supervisar. Modifique el programa supervisado y el procesamiento posterior a la detección para utilizarlos como punto de partida de su propia aplicación.

Para desarrollar en TypeScript, puede utilizar Geyser gRPC o Shreds gRPC. Las mejoras de la cola de eventos de esta versión están incluidas en los ejemplos y proyectos de inicio de Geyser gRPC. Elija la implementación publicada que se ajuste a su lenguaje y al método de entrega que utiliza.

ERPC Shreds UDP Forwarding Premium conecta varios nodos en una malla dentro de cada región y reenvía la primera copia de cada Shred que recibe esa malla. Tanto el momento de llegada por la ruta de entrega como el tiempo de reconstrucción dentro del SDK tras la llegada influyen en la rapidez con la que los datos recibidos pueden utilizarse. Las mejoras de la recepción UDP en Rust se pueden aplicar en el lado receptor a los datos entregados por Premium.

En la comparación realizada en Fráncfort el 30 de octubre de 2026, Standard y Premium se capturaron simultáneamente durante 120 segundos en una misma máquina y con el mismo reloj. A partir de la captura pcap se emparejaron las cargas útiles UDP con contenido idéntico. Premium llegó primero en el 98 % de ese conjunto coincidente y la mediana de la diferencia de llegada fue de 1,78 ms. De las cargas útiles observadas en Standard, el 93,9 % también se observó en Premium.

El gráfico de Premium muestra las diferencias en el tiempo de llegada entre las rutas de entrega, mientras que el gráfico del SDK muestra el procesamiento interno del receptor y la recuperación de la conexión. En una aplicación real, registrar tanto la llegada de los paquetes como el momento en que se detecta una instrucción relevante permite comprobar cuánto de la ventaja en la entrega se mantiene en el resultado del procesamiento.

Shreds UDP Forwarding Premium está disponible con facturación por horas a 1,39 € por hora. Empiece a utilizar el servicio desde el panel de control y verifique la recepción con el proyecto de inicio de UDP en Rust. Mantener la misma región, el mismo servidor receptor y la misma carga de trabajo de la aplicación permite evaluar las diferencias en los tiempos de llegada por separado del tiempo de procesamiento posterior a la recepción.

Primero, registre su dirección IPv4 pública y su puerto UDP en el panel de control, y permita el tráfico entrante desde los orígenes indicados. Una vez comprobadas la recepción de paquetes y la reconstrucción de datos con el proyecto de inicio de UDP en Rust, incluya en la evaluación los programas que desee supervisar y el procesamiento real de su aplicación. Combine los ejemplos con el servicio de entrega para medir el tiempo desde la recepción hasta la detección en su propio entorno.