Los desarrolladores de Solana han programado la actualización de consenso Alpenglow para el 21 de octubre, con el objetivo de alcanzar una finalidad de aproximadamente 150 milisegundos, mientras solicitan a los validadores y operadores de aplicaciones que se preparen para los cambios durante la transición en la mainnet.
Resumen
- La actualización Alpenglow de Solana está programada para el 21 de octubre, con el objetivo de alcanzar una finalidad de transacción de aproximadamente 150 milisegundos.
- Quicknode advierte de una breve pausa en las transacciones y posibles interrupciones en los flujos de datos durante la transición.
- Los validadores deben usar software compatible y fondear las cuentas de voto para la tarifa de admisión de 0.8 SOL.
- Algunos nodos RPC pueden recibir información de finalidad 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 previsto, 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 a partir de las 13:00 UTC, con la transición de consenso produciéndose aproximadamente 20 minutos después de la activación.
La página de actualización actual de la Fundación Solana sitúa el cambio en la época 1064 y enumera la mainnet como aún no activada. Su estimación actualizada sitúa el inicio de la época cerca de las 13:20 UTC, haciendo del límite de la época el desencadenante relevante en lugar de una cita fija en el reloj.
Solana Alpenglow apunta a la finalidad, no a una ejecución más rápida
Según el diseño de Anza, Votor reemplaza la lógica de votación y finalidad de TowerBFT. El objetivo es de aproximadamente 150 milisegundos en condiciones normales de red, no una garantía de que cada billetera, exchange o aplicación de trading muestre una transacción completada dentro de ese período.
La Fundación afirma que la ejecución de transacciones, el comportamiento de los programas y la mecánica de tarifas permanecen sin cambios. Los usuarios ordinarios no necesitan alterar cómo firman o aprueban transacciones, mientras que la actualización separada de distribución de datos Rotor está reservada 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.
La descripción técnica de Quicknode describe dos rutas de votación que operan simultáneamente. Una puede finalizar un bloque en una sola ronda cuando el 80% de los validadores participan, mientras que la otra 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 descripción general indica que las aplicaciones comúnmente muestran confirmaciones dentro de dos a tres segundos bajo configuraciones optimistas, antes de que el antiguo sistema alcance la finalidad completa en alrededor de 13 segundos.
El despliegue de octubre sigue una hoja de ruta anterior que vinculaba Alpenglow con 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 en mainnet en esa versión.
Para el 26 de septiembre, la actualización había llegado a devnet tras la transición de testnet el día anterior, como fue cubierto previamente por crypto.news. Los equipos de aplicaciones pudieron entonces verificar el nuevo comportamiento del consenso antes de desplegar contra la red que maneja los fondos de los usuarios.
Los traders enfrentan una breve interrupción durante la transición
Quicknode advierte que las nuevas transacciones dejarán brevemente de entrar en los bloques mientras la red cambia los sistemas de consenso. Su aviso describe una pausa que dura unos pocos segundos, con una interrupción más prolongada posible si la transición toma más tiempo.
Los envíos de transacciones pueden devolver temporalmente un error de preflight de "nodo no saludable", según 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 el compromiso confirmado o finalizado para datos que no deben revertirse. Quicknode afirma que sus endpoints de Solana existentes permanecerán en su lugar y que su equipo monitoreará la red durante todo el cambio.
En la descripción técnica del proveedor, la liquidación irreversible más rápida 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 trading individuales adoptarán nuevas políticas de liquidación el día de la activación.
La preparación del validador incluye el software y la financiación de la cuenta
La lista de verificación actual de la Fundación Solana indica a los validadores que ejecuten 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 renta en sus cuentas de voto para cubrir el Ticket de Admisión del Validador. El primer cargo paga la participación en la época 1065, y una tarifa impaga impide que un validador vote o produzca bloques en esa siguiente época.
La aprobación de la gobernanza es anterior a esos requisitos operativos. La propuesta se aprobó en septiembre de 2025 con 98.27% de los votos a favor, según la cobertura de la votación completada. La participación representó el 52% del stake, por lo que el porcentaje de aprobación describe los votos emitidos en lugar de toda la población de validadores.
Esa votación anterior aprobó SIMD-0326, la propuesta detrás de la revisión del consenso. El informe contemporáneo registró 1.05% en contra y 0.69% de abstención, 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 para operadores de Anza explica que los mensajes de consenso normalmente circulan entre los validadores admitidos. Un nodo sin stake que utiliza la ruta de entrega predeterminada conoce la finalidad a partir de los certificados incluidos en bloques posteriores, lo que normalmente añade hasta 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 red entre ambos sigue formando parte del tiempo de entrega.
La cobertura de la 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 de los bloques.
Según ese informe, eliminar las transacciones de voto cambia los totales del panel de control incluso cuando el número de pagos y operaciones de usuarios se mantiene constante. Los servicios que contabilizan 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.
