Alpenglow, la reforma de consenso más ambiciosa de Solana desde su lanzamiento, ya se está probando en testnet pública con un objetivo declarado de 150 milisegundos.
El salto a la testnet pública se activó el 24 de septiembre, con una réplica en devnet al día siguiente, según el calendario de desarrollo del cliente Agave, el software que ejecutan la mayoría de los validadores de la red. Hasta entonces, el upgrade se había validado durante meses en un clúster comunitario cerrado.
Alpenglow sustituye a Tower BFT, el mecanismo de consenso que Solana utiliza desde su lanzamiento para que los validadores acuerden qué bloques son definitivos. La propuesta se discutió primero en los Solana Improvement Documents (SIMD), el repositorio público donde se debaten los cambios de protocolo, y puede seguirse en el repositorio oficial de SIMD.
De Tower BFT a Votor: qué cambia por dentro
La primera pieza que entra en juego se llama Votor. Hoy los validadores emiten sus votos como transacciones on-chain, que compiten por espacio en el mismo carril que el resto del tráfico de la red. Votor elimina ese cuello de botella: los votos viajan directamente entre validadores y se agregan en certificados, sin pasar por la cola de transacciones.
El segundo cambio es conceptual. La finalidad —el instante en que una transacción deja de ser reversible porque el consenso la da por liquidada— pasa a depender de cuánto stake participe en cada ronda de votación. Con el 80% del stake votando en una sola ronda se activa la vía rápida; con el 60% repartido en dos rondas, la vía lenta pero igualmente válida.
Ahí está la letra pequeña. Ese margen de 100 a 150 milisegundos es un objetivo de las pruebas públicas, no una medición sobre la red principal. La cifra todavía no está validada en mainnet y puede moverse cuando lleguen los primeros resultados medidos, tal y como adelantó Crypto.News.
Solana no cambia de motor por capricho: intenta que su ventaja de velocidad deje de depender de la lotería de cada ronda de votos.
Para el usuario, la diferencia se traduce en cosas concretas. Un operador de arbitraje deja de perder operaciones por llegar tarde, un protocolo de derivados, puede liquidar posiciones sin ventanas de ambigüedad y una pasarela de pago confirma un cobro casi al instante. Los 12,8 segundos actuales no rompen nada, pero obligan a asumir un riesgo que desaparece cuando la finalidad es casi inmediata.
Rotor llega después: Turbine no se toca todavía
Conviene no leer esta fase como un reemplazo simultáneo de todo el sistema. El despliegue es escalonado y arranca por la parte de consenso, la que gestiona los votos y su agregación. Rotor, el sustituto previsto de Turbine —el mecanismo que reparte los bloques entre validadores—, llegará más adelante dentro del mismo plan. La reforma completa de la capa de red todavía queda por delante.
Para los operadores de nodo, el aviso es sencillo: hay que actualizar el cliente y seguir el calendario de cerca. Si la participación de stake se queda por debajo de los umbrales previstos, la vía rápida no se activa y la red vuelve al camino lento. El staking —delegar SOL a un validador a cambio de recompensas— concentra además una parte muy relevante del poder de voto en pocos operadores, y ese factor no lo corrige ninguna actualización por sí sola.
El 28 de septiembre del calendario Agave y lo que aún no está cerrado
El calendario de Agave v4.3 fija el 19 de agosto como la fecha en la que se completó la activación de la función en testnet y añade un reinicio de esa red a lo largo de septiembre. El documento señala el 28 de septiembre, mañana, como hito tentativo para la activación en mainnet. El propio calendario advierte de que las fechas pueden cambiar, así que la activación no está confirmada.
Solana ya ha vivido antes reformas de este calibre, y no todas salieron según lo previsto. Las paradas de red de septiembre de 2021 y febrero de 2022, cuando la red dejó de producir bloques por la saturación provocada por bots de acuñación de NFT, dejaron una lección incómoda: la velocidad sin redundancia es un riesgo operativo. De ahí que durante años se reclamara un segundo cliente validador, Firedancer, desarrollado por Jump Crypto, para que la red no dependiera de un único software. Cambiar el consenso es un paso más delicado que cambiar el cliente, porque toca la votación misma: si una parte relevante del stake se queda atrás, la mejora se convierte en teoría.
La pregunta que importa no es si Votor funciona en un clúster de pruebas, sino cuántos validadores actualizan a tiempo y con qué grado de participación se alcanza el umbral del 80%. Con el calendario de Agave en la mano, septiembre y octubre deberían dejar la primera señal clara: la activación en mainnet, su retraso o un nuevo reinicio de testnet. Ahí se sabrá si los 150 milisegundos son un titular o una realidad medible.
