Solana establece la actualización Alpenglow para el 21 de octubre con un objetivo de finalización de 150 ms

Los desarrolladores de Solana han programado la actualización de consenso Alpenglow para el 21 de octubre, con un objetivo de finalización de aproximadamente 150 milisegundos, mientras piden a los validadores y operadores de aplicaciones que se preparen para los cambios durante la transferencia de la red principal.

Resumen

• La actualización Alpenglow de Solana está programada para el 21 de octubre, con un objetivo de finalización de transacciones de aproximadamente 150 milisegundos.
• Quicknode advierte sobre una breve pausa en las transacciones y posibles interrupciones en el flujo de datos durante la transferencia.
• Los validadores deben usar software compatible y financiar cuentas de voto para la tarifa de admisión de 0.8 SOL.
• Algunos nodos RPC pueden recibir información de finalización más tarde que los validadores que participan directamente en el consenso.

El aviso de mantenimiento de Quicknode identifica el miércoles como el día de activación planificado, pero su última actualización advierte que la estimación original de las 14:50 UTC podría adelantarse a las 13:20 UTC a medida que avanza la producción de bloques. El proveedor pide a los operadores que estén listos desde las 13:00 UTC, con la transferencia de consenso que sigue a la activación aproximadamente 20 minutos después.

La página de actualización actual de la Fundación Solana coloca el cambio en la época 1064 y lista la red principal como no activada aún. Su estimación actualizada sitúa el inicio de la época cerca de las 13:20 UTC, haciendo que el límite de la época sea el desencadenante relevante en lugar de una cita fija en el reloj.

Solana Alpenglow apunta a la finalización, no a una ejecución más rápida

Bajo el diseño de Anza, Votor reemplaza la lógica de votación y finalización de TowerBFT. El objetivo es de aproximadamente 150 milisegundos en condiciones normales de red, no una garantía de que cada billetera, intercambio o aplicación de trading mostrará una transacción completada dentro de ese período.

La Fundación dice que la ejecución de transacciones, el comportamiento del programa y la mecánica de tarifas permanecen sin cambios. Los usuarios ordinarios no necesitan alterar la forma en que firman o aprueban transacciones, mientras que la actualización separada de distribución de datos Rotor se reserva para una versión posterior. Su documentación separa el despliegue del consenso de las reducciones anteriores en la duración de los slots, que rigen con qué frecuencia la red produce bloques.

El resumen técnico de Quicknode describe dos caminos de votación que operan simultáneamente. Uno puede finalizar un bloque en una sola ronda cuando participa el 80% de los validadores, mientras que el otro utiliza una segunda ronda cuando la participación alcanza el 60%.

El proveedor distingue ese proceso de las confirmaciones tempranas que los usuarios ya ven. Su resumen dice que las aplicaciones comúnmente muestran confirmaciones dentro de dos a tres segundos bajo configuraciones optimistas, antes de que el antiguo sistema alcance la finalización total en alrededor de 13 segundos.

El despliegue de octubre sigue una hoja de ruta anterior que vinculaba Alpenglow a Agave 4.3. Un informe del 14 de agosto documentó que el código de Alpenglow estaba presente en Agave 4.2 para pruebas, sin autorizar la activación de la red principal en esa versión.

Para el 26 de septiembre, la actualización había alcanzado devnet después de la transición de testnet el día anterior, como se cubrió anteriormente en crypto.news. Los equipos de aplicaciones pudieron entonces verificar el nuevo comportamiento de consenso antes de desplegarse contra la red que maneja los fondos de los usuarios.

Los traders enfrentan una breve interrupción durante la transferencia

Quicknode advierte que las nuevas transacciones dejarán de entrar brevemente en los bloques mientras la red cambia los sistemas de consenso. Su aviso describe una pausa que dura unos segundos, con una interrupción más larga posible si la transición toma más tiempo.

Las presentaciones de transacciones pueden devolver temporalmente un error de pre-vuelo "nodo no saludable", dice el proveedor. Los flujos de datos de Yellowstone pueden desconectarse una vez, mientras que las suscripciones que utilizan el compromiso procesado más temprano pueden mostrar slots que nunca alcanzan la confirmación.

El aviso de mantenimiento recomienda un compromiso confirmado o finalizado para los datos que no deben revertirse. Quicknode dice que sus puntos finales existentes de Solana permanecerán en su lugar y que su equipo monitoreará la red durante todo el cambio.

En la visión técnica del proveedor, un asentamiento irreversible más rápido es relevante para aplicaciones financieras, transferencias de tesorería corporativa y servicios en tiempo real. El documento presenta esos usos como capacidades de la arquitectura de consenso propuesta, sin establecer que las plataformas de negociación individuales adoptarán nuevas políticas de asentamiento el día de la activación.

La preparación de los validadores incluye software y financiación de cuentas

La lista de verificación actual de la Fundación Solana instruye a los validadores a ejecutar la versión 4.3.2 de Agave, Jito-Solana o Harmonic Salsa antes de la época 1064. Firedancer y Frankendancer no son compatibles durante la migración, según la misma guía.

Los operadores deben mantener al menos 0.8 SOL por encima del mínimo exento de alquiler en sus cuentas de voto para cubrir el Ticket de Admisión del Validador. El primer cargo paga por la participación en la época 1065, y una tarifa no pagada impide que un validador vote o produzca bloques en esa próxima época.

La aprobación de gobernanza precede a esos requisitos operativos. La propuesta fue aprobada en septiembre de 2025 con un 98.27% de votos a favor, según la cobertura de la boleta completada. La participación representó el 52% de la participación, por lo que el porcentaje de aprobación describe los votos emitidos en lugar de toda la población de validadores.

Ese voto anterior aprobó SIMD-0326, la propuesta detrás de la revisión del consenso. El informe contemporáneo registró un 1.05% en contra y un 0.69% de abstenciones, con la pequeña diferencia de redondeo preservada en las cifras publicadas.

La entrega de RPC puede retrasarse respecto al objetivo de 150 ms

La documentación del operador de Anza explica que los mensajes de consenso normalmente circulan entre los validadores admitidos. Un nodo no apostado que utiliza la ruta de entrega predeterminada aprende la finalización a partir de certificados llevados en bloques posteriores, sumando típicamente un intervalo de bloque producido.

Los bloques omitidos o retrasados pueden alargar esa espera. Un nodo asociado con un validador admitido puede recibir mensajes directamente, aunque la latencia de la red entre los dos sigue siendo parte del tiempo de entrega.

La cobertura del devnet de septiembre documentó cambios separados para indexadores y exploradores. Los bloques candidatos deben permanecer separados hasta la confirmación, y los datos de participación de los validadores se alejan de las transacciones de voto ordinarias hacia certificados adjuntos a los datos del bloque.

Según ese informe, la eliminación de las transacciones de voto cambia los totales del panel incluso cuando el número de pagos y transacciones de usuarios se mantiene constante. Los servicios que cuentan ambas categorías deben restablecer sus comparaciones, mientras que los sistemas que rastrean los votos de los validadores necesitan leer los datos del certificado de reemplazo.