Jito ShredStream: Construcción y medición de un pipeline de shreds de Solana de baja latencia

Respuesta directa y alcance

Jito ShredStream es un servicio que transmite shreds de Solana —los fragmentos que los validadores utilizan para propagar bloques— desde los líderes de bloque a los suscriptores con menor latencia que la ruta de red predeterminada. Los suscriptores normalmente ejecutan el cliente de código abierto shredstream-proxy, que se autentica con un par de claves, se conecta a endpoints regionales y expone los shreds entrantes localmente para su decodificación o reenvío.

Esta guía se centra en el flujo de trabajo de ingeniería: requisitos previos, configuración del proxy, decodificación, verificación, metodología de medición de latencia y planificación de migración. No recomienda un endpoint o proveedor específico; para elecciones concretas de endpoint y proveedor, utilice los recursos del Asistente de RPC enlazados a continuación. El comportamiento documentado se separa de las recomendaciones y de las mediciones que usted debe ejecutar en su propio entorno.

• Documentado: la documentación de Jito describe ShredStream como entrega de shreds de baja latencia e incluye un aviso de descontinuación con fecha de cierre el 5 de septiembre de 2026.
• Documentado: el repositorio jito-labs/shredstream-proxy es el cliente para recibir shreds de la red Jito.
• Recomendado: trate cualquier afirmación de latencia como específica del entorno hasta que la mida en sus propios hosts y regiones.

Requisitos previos y suposiciones

Antes de construir un pipeline de shreds, confirme que tiene un par de claves de Solana para autenticación, un host con acceso de red estable en o cerca de una región compatible, y la capacidad de abrir los puertos UDP y TCP que requiere su configuración de proxy. También debe tener un plan para decodificar shreds, porque los shreds sin procesar no son datos de transacción directamente utilizables.

Los ejemplos a continuación asumen un host Linux, Docker o una cadena de herramientas Rust, y un par de claves almacenado en una ruta que usted controle. Utilizan marcadores de posición como RPC_URL y KEYPAIR_PATH en lugar de credenciales reales. Si todavía está eligiendo dónde ejecutar cargas de trabajo RPC de soporte, revise la guía de proveedores RPC de Solana y las opciones de nodo dedicado antes de comprometerse con una arquitectura.

Cómo encajan los shreds y ShredStream

Los validadores de Solana dividen los bloques en shreds, que son unidades más pequeñas que se pueden transmitir y reensamblar de manera eficiente. Los shreds proporcionan redundancia y tolerancia a fallos: si algunos fragmentos se retrasan o se pierden, la red aún puede reconstruir el bloque a partir de otros. La propagación estándar se basa en la diseminación estilo turbina a través del conjunto de validadores, que es robusta pero no está optimizada para la vista más temprana posible de un solo suscriptor.

ShredStream cambia la ruta de entrega enviando shreds desde los líderes a los suscriptores a través de la infraestructura de Jito. El proxy recibe esos shreds y los pone a disposición localmente. A partir de ahí, su aplicación puede deshacer los shreds, decodificar transacciones o reenviar datos a otros sistemas. El modelo mental importante es que ShredStream es una señal temprana, no un reemplazo para datos históricos indexados o una vista RPC completa del estado finalizado. Combinarlo con una fuente RPC confiable mantiene disponibles tanto las primeras ejecuciones como el historial confiable.

Ejecución de shredstream-proxy con Docker

El proxy se distribuye como un proyecto Rust con soporte para Docker. Generalmente se recomienda el networking de host porque evita la sobrecarga de la red de puente y simplifica la exposición de puertos para el tráfico UDP. La siguiente configuración utiliza variables de entorno y un par de claves montado; reemplace los marcadores de posición con sus propios valores.

Ejecute el contenedor con networking de host y pase la ruta del par de claves y el puerto de destino. Los indicadores exactos y los nombres de las variables de entorno pueden cambiar entre versiones, así que verifíquelos con el README y las notas de la versión del repositorio antes de usarlos en producción.

docker run --rm \
  --network host \
  -v "$KEYPAIR_PATH:/keys/id.json:ro" \
  -e KEYPAIR_PATH=/keys/id.json \
  -e DEST_IP=127.0.0.1 \
  -e DEST_PORT=8001 \
  ghcr.io/jito-labs/shredstream-proxy:latest

Verificación de que los shreds están llegando

Antes de escribir la lógica de decodificación, confirme que el proxy está recibiendo datos. Un simple receptor UDP puede contar paquetes e imprimir los primeros bytes de cada carga útil. Este es un paso de diagnóstico, no un decodificador de producción. Si no llegan paquetes, revise las reglas del firewall, la selección de región, los permisos del par de claves y si los registros del proxy muestran una suscripción exitosa.

El siguiente fragmento de Python se enlaza al puerto de destino local e imprime los tamaños de paquete y un prefijo hexadecimal corto. Ejecútelo en el mismo host que el proxy o en un host que reciba el tráfico reenviado.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 8001))

count = 0
while count < 20:
    data, addr = sock.recvfrom(65535)
    print(f"packet={count} size={len(data)} from={addr} prefix={data[:16].hex()}")
    count += 1

Decodificación de shreds en transacciones utilizables

Los shreds sin procesar deben reensamblarse y decodificarse antes de convertirse en transacciones. El repositorio del proxy incluye utilidades de deshred y decodificación, y la documentación de Jito describe enfoques de decodificación. Un patrón común es utilizar el servicio de deshred integrado del proxy o alimentar los shreds a un decodificador que comprenda el formato de shred de Solana y la bandera DATA_COMPLETE.

No asuma que cada paquete es una transacción completa. Los shreds pueden ser parciales, duplicados o estar fuera de orden. Su decodificador debe manejar la deduplicación y la reconstrucción. Si está construyendo un pipeline personalizado, pruebe con slots conocidos y compare las firmas decodificadas con una fuente RPC confiable usando RPC_URL.

curl -s "$RPC_URL" -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'

Medición de latencia de extremo a extremo sin inventar cifras

Las afirmaciones de latencia solo son significativas cuando están vinculadas a un método. Un enfoque reproducible es marcar con tiempo la llegada de un paquete de shred, decodificarlo a una firma de transacción y comparar esa marca de tiempo con la primera vez que la misma firma es visible a través de un endpoint RPC de referencia. Registre ambas marcas de tiempo en el mismo dominio de reloj, preferiblemente usando hosts sincronizados con NTP.

Ejecute el procedimiento en múltiples slots y regiones, e informe percentiles en lugar de un único mejor caso. La siguiente tabla es una plantilla; complétela con sus propias mediciones. No publique cifras que no haya recopilado.

• Captura: registre t_shred cuando la firma decodificada aparezca por primera vez en su pipeline de ShredStream.
• Referencia: consulte getSignatureStatuses o getTransaction en RPC_URL y registre t_rpc cuando la firma se observe por primera vez.
• Cálculo: delta = t_rpc - t_shred para cada firma coincidente.
• Informe: recuento, p50, p95, p99 y el par de regiones utilizado para cada fila.

| Region pair | Matched signatures | p50 delta (ms) | p95 delta (ms) | p99 delta (ms) |
|-------------|--------------------|----------------|----------------|----------------|
| your-region-A to reference-A | (fill) | (fill) | (fill) | (fill) |
| your-region-B to reference-B | (fill) | (fill) | (fill) | (fill) |

Solución de problemas comunes del pipeline

La mayoría de los problemas de ShredStream se dividen en unas pocas categorías: autenticación, red, decodificación y ciclo de vida del servicio. Los fallos de autenticación generalmente significan que la ruta del par de claves es incorrecta o que la clave no está autorizada. Los fallos de red a menudo involucran puertos UDP, firewalls del host o redes de puente que descartan paquetes. Los fallos de decodificación suelen deberse a shreds incompletos o suposiciones de formato incorrectas.

Revise primero los registros del proxy. Si el proxy informa una suscripción exitosa pero su receptor no ve nada, verifique la IP y el puerto de destino y confirme que el receptor está enlazado a la interfaz correcta. Si llegan paquetes pero la decodificación falla, inspeccione la bandera DATA_COMPLETE y compárela con los ejemplos de decodificación del repositorio. Para problemas más amplios de confiabilidad de RPC, la guía de endpoints RPC y la guía de endpoints RPC multicadena cubren patrones de respaldo y consistencia.

• Sin paquetes: revise el firewall, el networking de host y el puerto de destino.
• Errores de autenticación: verifique el montaje y los permisos del par de claves.
• Datos corruptos: confirme el formato de shred y el paso de deshred.
• Brechas intermitentes: revise la selección de región y las rutas redundantes.

Limitaciones, compensaciones y la ruta de descontinuación

ShredStream está optimizado para la visibilidad más temprana, no para la completitud o la finalidad. Puede entregar shreds que luego se abandonan, y no reemplaza un nodo RPC completo para consultas de estado. Ejecutar un proxy agrega superficie operativa: gestión de claves, exposición de puertos, selección de región y mantenimiento del decodificador. Los equipos deben sopesar estos costos frente al valor de las señales más tempranas para su estrategia.

La documentación de Jito incluye un aviso de descontinuación que indica que ShredStream se cerrará el 5 de septiembre de 2026 y recomienda migrar a una alternativa antes de esa fecha. Trate esto como una restricción de planificación estricta. Inventaríe cada sistema que dependa del proxy, documente sus suposiciones de decodificación y construya una prueba de migración que compare los feeds antiguo y nuevo en los mismos slots. Para equipos que consolidan infraestructura, la guía de alojamiento de nodos blockchain y la descripción general de precios de RPC proporcionan contexto para la presupuestación y las operaciones.

Próximos pasos para un pipeline listo para producción

Comience ejecutando el proxy en un entorno de staging y verificando la llegada de paquetes con el receptor de diagnóstico. Luego agregue decodificación, deduplicación y un arnés de medición de latencia que registre percentiles entre regiones. Solo después de esos pasos debe enrutar el tráfico de producción a través del feed.

Para la selección de endpoints y proveedores, utilice el Asistente de RPC en lugar de incrustar una lista de proveedores aquí. La mejor guía de proveedores RPC de Solana y la guía de Solana devnet son puntos de partida útiles para entornos de prueba, mientras que el servicio API de OnFinality y la cobertura de redes le ayudan a planificar la infraestructura de soporte. Mantenga las pruebas de migración en ejecución hasta que el feed antiguo se retire por completo.