Puntos Clave de la Noticia:
- Jito publicó una guía operativa que exige a los operadores actualizar a clientes compatibles como Jito-Solana v4.3.0-jito.0 y Firedancer v26.09.5.
- La infraestructura de Block Assembly Marketplace (BAM) concentró 164 millones de SOL delegados entre 385 validadores en la Época 1050, equivalente al 37% del stake de Solana.
- Los nodos BAM entrarán en modo de mantenimiento previo a la activación, suspendiendo temporalmente el procesamiento de múltiples paquetes (MPP) y los incentivos dinámicos de bloque (DBI).
Jito hizo pública este viernes las directrices operativas y requisitos de validadores antes de la actualización Alpenglow de Solana, alertando sobre cambios temporales en sus servicios de ensamblaje de bloques.
— Jito (@jito) October 9, 2026
La actualización técnica abarca ajustes de compatibilidad de software, variaciones en la cadencia de subastas y la desactivación momentánea de funciones avanzadas dentro de su mercado Block Assembly Marketplace (BAM).
El equipo de Jito informó que, la transición hacia la red principal de Alpenglow se encuentra próxima en el calendario de desarrollo. Sin embargo, la documentación oficial aclara que aún no se ha fijado una época definitiva de activación ni el cronograma exacto para el mantenimiento previo.
Para preservar la sincronización con la red y evitar bifurcaciones accidentales, la organización listó las versiones de cliente admitidas. Los operadores deberán emplear Jito-Solana v4.3.0-jito.0, Agave v4.3.0-jito, Firedancer (FireBAM) v26.09.5 o Frankendancer v0.1204.40300. Jito advirtió de manera explícita que los validadores en producción que ejecuten utilidades de contexto de desarrollo corren el riesgo técnico de quedar aislados del consenso de la red.
Los nodos BAM pasarán a un modo de mantenimiento varios días antes de la activación definitiva. Durante este intervalo, la infraestructura retrocederá de forma temporal al Block Engine estándar de Jito-Agave.
Las transacciones agrupadas continuarán operando con normalidad bajo este esquema de contingencia. No obstante, las herramientas específicas de BAM, como el procesamiento de paquetes múltiples (MPP) y los incentivos dinámicos por bloque (DBI), quedarán desactivadas mientras dure el mantenimiento. Los usuarios que dependen de actualizaciones de oráculos deberán redirigir su flujo hacia la Unidad de Procesamiento de Transacciones (TPU) o a la ruta tradicional del Block Engine.
Ajustes de latencia y métricas de participación en BAM
La reducción programada del tiempo de ranura a 200 milisegundos en Solana, prevista para la Época 1053, motivó modificaciones operativas en el sistema de subastas. La cadencia interna de las subastas en BAM se redujo de 25 a 20 milisegundos para sincronizarse con la mayor velocidad de generación de bloques.
Los reportes técnicos de la firma detallaron además la mitigación de fallas de latencia detectadas en pruebas previas. Un error en el kernel de Linux generaba retrasos de entre 90 y 330 milisegundos en la primera ranura de ciertas ventanas de líderes, anomalía que ya cuenta con un parche desplegado. Asimismo, la compactación de memoria en entornos de ejecución confiable (TEE) redujo la velocidad entre un 7% y un 17%, mientras que la corrección de problemas de compartición falsa de datos disminuyó la latencia de repetición en aproximadamente un 20%.
Al cierre de la Época 1050, los registros de Jito reflejaron 164 millones de SOL delegados en BAM a través de 385 validadores, cifra que representa cerca del 37% de la participación total de la red Solana. A esto se sumaron 7,3 millones de SOL operados mediante 12 validadores en FireBAM, lo que añade un 4,6% adicional de stake en dicha infraestructura.
La distribución de ingresos por preconfirmaciones ya se encuentra activa, y los primeros pagos a validadores bajo este esquema están previstos para finales de octubre de 2026, fecha en la que también se proyecta la inscripción de validadores en la red principal del registro BAM.
