¿Ya está activo Alpenglow en Solana? Cómo distinguir un calendario de versiones de una activación

Durante el fin de semana empezó a circular una fecha en los canales de noticias cripto: la actualización de consenso Alpenglow de Solana se activaría en mainnet el domingo 28 de septiembre de 2026. No ocurrió. La pregunta que se hacen los lectores es práctica: ¿ya está activo Alpenglow en Solana y cómo saber cuándo una actualización de blockchain se ha activado de verdad y no solo está programada?

La respuesta corta

No. Al 29 de septiembre de 2026, Alpenglow funciona en la testnet de Solana, no en mainnet, y no se ha anunciado ninguna fecha de activación en mainnet. La fecha del 28 de septiembre salió de un calendario general de versiones de software que nunca mencionó Alpenglow, lo que ilustra bien la diferencia entre publicar un cliente, habilitar un feature gate y activar realmente un cambio.

De dónde salió la fecha del 28 de septiembre

El principal cliente de validadores de Solana, Agave, lo mantiene Anza y se despliega según un calendario público. El calendario de la versión Agave v4.3 en GitHub enumera una serie de hitos: adopción en testnet, actualización de devnet, voluntarios con stake en mainnet, recomendación de adopción general el 21 de septiembre y, por último, "Mainnet-beta: Resume feature activation" el 28 de septiembre. La página se describe como meramente informativa, con todas las fechas sujetas a cambios, y pide a los operadores esperar los anuncios en Discord antes de actuar.

Como la v4.3 es la versión que incluye el código de consenso de Alpenglow, algunos unieron los puntos y leyeron "reanudar la activación de funciones" como "Alpenglow entra en funcionamiento". Esa línea nunca lo dijo. Una corrección del 23 de septiembre, añadida a un artículo de Solana Compass, aclaró que la entrada del 28 de septiembre no era una fecha de Alpenglow, sino el momento en que Anza retoma, en general, el procesamiento de los feature gates en cola.

Aun así, el rumor llegó lejos. El calendario Crypto Week Ahead de CoinDesk, publicado la mañana del 28 de septiembre, señalaba ese día como el lanzamiento de Alpenglow. Es un recordatorio de que incluso medios consolidados pueden resumir un calendario lleno de matices en una sola fecha de titular.

Qué dijeron los desarrolladores

El 28 de septiembre, dos de las personas más cercanas al protocolo salieron a desmentirlo. Según DiarioBitcoin y CryptoTicker, el jefe de investigación de Anza, Roger Wattenhofer, escribió "No Alpenrush", y el cofundador de Solana, Anatoly Yakovenko, respondió con una sola palabra: "decel". DiarioBitcoin y KuCoin News indican además que Wattenhofer recordó que el protocolo llevaba apenas unos días en pruebas públicas. Nos basamos en esas informaciones, sin haber consultado directamente las publicaciones originales.

Qué cambia realmente Alpenglow

El contenido del cambio explica por qué los desarrolladores no tienen prisa. Alpenglow no es un parche rutinario: sustituye el núcleo del mecanismo con el que Solana se pone de acuerdo sobre los bloques.

Votación y finalidad

Según la documentación de Alpenglow de Anza, la actualización reemplaza la lógica de votación y finalidad de Tower BFT por un nuevo componente llamado Votor y apunta a una finalidad de unos 150 milisegundos en condiciones normales de red. El anuncio original de mayo de 2025 hablaba de una mediana de unos 150 ms, a veces 100 ms, a partir de simulaciones con la distribución de stake de mainnet. Blockworks situó la finalidad actual de Solana en unos 12,8 segundos. Son objetivos de diseño y simulaciones, no rendimiento medido en mainnet.

Menos transacciones de voto on-chain

Hoy los validadores publican transacciones de voto on-chain y pagan comisiones por ellas. Blockworks informó en 2025 que esos votos suponían cerca del 70% de las transacciones on-chain de Solana; una estimación posterior de Solana Compass la situó más cerca del 59%. Las cifras varían, pero la dirección es la misma: Alpenglow saca la votación de la cadena, con mensajes directos entre validadores, y registra los resultados agregados en certificados compactos.

Una nueva economía para los validadores

La documentación de Anza describe un mecanismo de admisión que acepta como máximo 2.000 validadores elegibles, priorizados por stake, con un "ticket de admisión" que se descuenta de las cuentas de voto en cada época. Los operadores también deben registrar claves BLS. El protocolo promete una resiliencia "20+20": está diseñado para seguir siendo seguro con hasta un 20% de stake adversario y otro 20% de stake desconectado. Cuando la propuesta de gobernanza SIMD-0326 se aprobó en septiembre de 2025, Blockworks registró un 98,94% de los votos emitidos a favor, con participación del 52% del stake de la red, y recogió la preocupación de que el ticket de admisión pudiera levantar barreras para los validadores pequeños.

Por qué la prudencia tiene sentido

Tres detalles del propio despliegue explican el ritmo más lento.

• La diversidad de clientes es una limitación. Solana Compass informó de que Anza advirtió que Firedancer y Frankendancer, los clientes alternativos desarrollados por Jump Crypto, no admiten la migración a Alpenglow, y que los nodos de testnet que los usaban tuvieron que pasarse a Agave. En mainnet, cualquier stake que siga en un cliente no compatible en el momento de la activación sería un riesgo.
• La adopción partió de una base baja. El mismo medio informó de que, a principios de septiembre, solo alrededor del 0,39% del stake activo ejecutaba la v4.3.
• El tiempo en testnet es corto. Alpenglow se activó en testnet la semana del 22 de septiembre, según Solana Compass y CryptoTicker. Un cambio de consenso suele requerir un periodo más largo de observación, incluidos escenarios de fallo y recuperación, antes de manejar valor real.

Cómo saber si una actualización está realmente activa

El episodio de Alpenglow deja una lista de comprobación válida para cualquier actualización de red, no solo la de Solana:

1. Separa la versión de la activación. Que se publique un cliente, o que se recomiende adoptarlo, no significa que las nuevas reglas estén vigentes. En Solana, muchos cambios dependen de feature gates que se activan por separado.
2. Busca el nombre de la función, no solo una fecha. Una línea de calendario que dice "reanudar la activación de funciones" sin nombrar ninguna no es un anuncio de esa función.
3. Prioriza los canales de los propios mantenedores. Las notas de versión, la documentación del proyecto y los anuncios oficiales pesan más que los calendarios agregados y las redes sociales.
4. Toma "provisional" al pie de la letra. Los calendarios de la v4.3 y la v4.4 advierten que las fechas pueden cambiar.
5. Interpreta el precio con cuidado. CryptoTicker registró SOL en 118,75 dólares el 28 de septiembre, un 3,29% menos en el día, mientras que DiarioBitcoin citó 119,85 dólares al momento de escribir. Un movimiento pequeño dice poco sobre la actualización; el mercado en general estaba débil ese día, y CoinDesk informó de que bitcoin caía más de un 2% en 24 horas.

Lo que sabemos frente a lo que inferimos

Lo que sabemos

• El calendario de Agave v4.3 fija el 28 de septiembre como "Mainnet-beta: Resume feature activation" y no menciona Alpenglow.
• Alpenglow está activo en testnet y no en mainnet al 29 de septiembre de 2026, según varias informaciones.
• Anza documenta un objetivo de finalidad de unos 150 ms, un límite de 2.000 validadores admitidos y tickets de admisión por época.
• El calendario de Agave v4.4 fija el 9 de noviembre de 2026 para "Mainnet-beta: Resume feature activation", también como fecha provisional.

Lo que inferimos

• Que los desarrolladores quieren un periodo más largo en testnet es nuestra lectura de sus comentarios públicos, no un calendario declarado.
• El 9 de noviembre es una ventana de activación de funciones. Nada de lo que encontramos indica que Alpenglow vaya a activarse entonces, y las informaciones señalan que no figura en esa ventana.
• La finalidad real en mainnet puede diferir de los resultados de las simulaciones; eso no se sabrá hasta la activación.

Qué vigilar a continuación

• 5 de octubre de 2026: el calendario de la v4.4 prevé reanudar la activación de funciones en testnet y actualizar devnet.
• 19 y 26 de octubre de 2026: convocatorias de voluntarios para llevar el 10% y luego el 25% del stake de mainnet a la v4.4.
• 2 y 9 de noviembre de 2026: adopción general de la v4.4 en mainnet, seguida de la siguiente ventana de activación de funciones.
• Un anuncio explícito de Alpenglow por parte de Anza o de la Solana Foundation, con el nombre del feature gate y una fecha. Hasta entonces, cualquier fecha de lanzamiento es especulación.
• Compatibilidad de clientes: si los clientes basados en Firedancer incorporan Alpenglow antes de la activación en mainnet.

Información educativa — no constituye asesoramiento financiero.