La actualización Alpenglow de Solana activará un nuevo protocolo de consenso en la Mainnet Beta de la blockchain el 21 de octubre, y se espera que la finalidad pase de aproximadamente 12.8 segundos a unos 150 milisegundos. Sin embargo, la red principal todavía tiene que demostrar ese objetivo en la práctica.

Solana es una blockchain de capa 1 en la que los validadores producen bloques y los confirman mediante votos. El protocolo de consenso determina cuándo una transacción se considera irreversible, una tarea que hasta ahora ha manejado un mecanismo llamado TowerBFT. Alpenglow debutó en mayo de 2025 en la conferencia Solana Accelerate. El concepto fue desarrollado bajo el liderazgo de Roger Wattenhofer de ETH Zurich, junto con sus antiguos estudiantes doctorales Kobi Sliwinski y Quentin Kniep, quienes ahora trabajan en Anza, desarrollador de Solana. En septiembre de 2025, los validadores aprobaron la propuesta SIMD-0326 con el 98.27% de los votos emitidos. Su componente principal, Votor, reemplaza al actual TowerBFT.

Medido frente a la cifra actual, el objetivo de 150 ms equivale a una finalidad aproximadamente 85 veces más rápida. Los 150 milisegundos se refieren al tiempo hasta la finalidad, no al tiempo de bloque: la ejecución de transacciones, la Solana Virtual Machine (SVM) y las tarifas permanecen sin cambios.

Votor reemplaza a TowerBFT en la votación de los validadores

Bajo TowerBFT, los votos de los validadores circulan por la blockchain como transacciones ordinarias. Votor cambia precisamente esto. De aquí en adelante, los validadores intercambiarán sus votos directamente entre sí y los agruparán en certificados BLS, de modo que un solo certificado combina la aprobación de muchos validadores en un único registro. En consecuencia, los votos ya no aparecerán como transacciones en cadena dentro de los bloques. Por lo tanto, la aceleración proviene del nuevo proceso de votación, no de bloques más rápidos.

Votor tiene dos rutas hacia la finalidad. Si al menos el 80% del stake certifica un bloque en la primera ronda, el bloque queda finalizado después de esa ronda, una ruta rápida que debería tomar alrededor de 100 milisegundos. Hasta un quinto del stake puede estar ausente sin bloquear esta ruta. Por el contrario, si la aprobación de la ronda 1 se sitúa entre el 60% y el 80%, la ruta más lenta toma el relevo con unos 150 milisegundos.

La propia Solana describe los 150 milisegundos en su página oficial de la actualización como una expectativa, no como una constante. Además, reducir a la mitad el tiempo de slot de 400 a 200 milisegundos no forma parte de Alpenglow; la red completó este cambio independiente anteriormente, en cuatro etapas hasta octubre de 2026. Para los exchanges, los creadores de mercado y los proveedores de pagos, la finalidad es la métrica clave, ya que determina cuándo una transacción se considera liquidada. Por lo tanto, los buenos resultados en entornos de prueba no reemplazan la comprobación bajo la carga real de la mainnet.

La migración de Alpenglow en el epoch 1064 requiere una coordinación estricta

El cambio comienza con el inicio del epoch 1064 el 21 de octubre, cuando un feature gate activa la nueva lógica. TowerBFT producirá primero otros 5,000 slots, unos 18 minutos, de que Alpenglow tome el control en el slot 459,653,000. Durante esta transición, la red deja brevemente de incluir transacciones de usuarios en los bloques. Votor solo inicia una vez que los validadores que concentran al menos el 82% del stake han firmado un certificado de génesis, lo que convierte esto en una intervención única y coordinada en una red en vivo.

La cuestión de los clientes de validadores es delicada. La migración excluye por ahora a los clientes alternativos Firedancer y Frankendancer, por lo que sus operadores deberán cambiar temporalmente a software basado en Agave 4.3 antes del epoch 1064. Las opciones incluyen el propio Agave, Jito-Solana y Harmonic Salsa, y Solana especifica la versión 4.3.2. Cualquier validador que no cambie a tiempo no aparecerá en el certificado de génesis, y cuánto más stake se pierda el cambio, más delgado será el margen sobre el umbral del 82%. Cuánto stake termine en ese primer certificado será, por lo tanto, uno de los primeros resultados visibles de la transición.

No obstante, el camino hacia la activación avanzó en etapas ordenadas. Desde julio de 2026, dos pasos preliminares se ejecutan en la mainnet: la gestión de claves BLS en la cuenta de voto (SIMD-0387) y el Validator Admission Ticket (SIMD-0357). Anza lanzó un clúster de pruebas comunitario en mayo de 2026, seguido de una testnet pública en septiembre y una devnet un día después. A mediados de octubre, el equipo de desarrollo anunció la fecha de mainnet.

Los validadores pagan 0.8 SOL por epoch en lugar de tarifas de voto

Al desaparecer las transacciones de voto, sus tarifas también desaparecen. Su lugar lo ocupa el Validator Admission Ticket (VAT), cuya base técnica está activa en la mainnet desde julio de 2026. Cuesta 0.8 SOL por epoch, que la red quema, retirando los tokens de la circulación. Además, el saldo de la cuenta de voto debe mantenerse al menos 0.8 SOL por encima del mínimo libre de renta. La tarifa vence por primera vez al inicio del epoch 1064, cubriendo el epoch 1065; los validadores que no paguen no podrán votar ni producir bloques en el epoch siguiente. El primer ciclo de cobro mostrará, en la práctica, cuántos operadores financian sus cuentas de voto a tiempo.

Para los operadores, esto modifica la estructura de costos. Hasta ahora, cada voto requería una transacción en cadena y, con ella, tarifas continuas, costos que surgían por validador, en gran medida independientes del stake. Si la nueva tarifa fija es menor que las tarifas de voto anteriores, los validadores más pequeños son los más beneficiados, ya que este tipo de costos fijos pesa comparativamente más en relación con su stake.

También se pierde un efecto estadístico secundario. Las transacciones de voto contaban previamente en la cifra reportada de transacciones por segundo (TPS), por lo que esta cifra de TPS podría caer después de la actualización. Se trata de un efecto de conteo, no de un problema de la red.

Menor tolerancia bizantina, preguntas abiertas sobre latencia y MEV

El modelo de seguridad también cambia. TowerBFT puede resistir hasta un 33% de stake bizantino, es decir, stake que actúa de forma maliciosa. Votor reduce esta tolerancia bizantina pura al 20%, mientras que adicionalmente tolera que un 20% del stake esté fuera de línea, el llamado modelo 20+20. En consecuencia, la tolerancia general a las interrupciones aumenta, mientras que la tolerancia a los ataques activos disminuye.

La industria también ha planteado objeciones concretas. El proyecto de blockchain Sei ve presión hacia la centralización, argumentando que una señal necesita entre 80 y 100 milisegundos para un viaje de ida y vuelta a través del Atlántico, un tramo que por sí solo supera la mitad del valor objetivo. El proveedor de infraestructura Helius señala preguntas abiertas sobre Multiple Concurrent Leaders y el MEV en la votación fuera de cadena, y las penalizaciones por equivocación, es decir, enviar bloques o votos contradictorios para el mismo slot, también siguen sin resolverse. Dado que estos puntos se refieren al diseño del protocolo y no a la mecánica de la migración, permanecen abiertos incluso después de que Alpenglow esté activo.

Esta activación deja fuera algunos componentes. Rotor, el reemplazo previsto de la capa de distribución de datos Turbine, pertenece solo a la segunda fase y aún no tiene fecha. Más adelante, se espera que Agave 4.4 incorpore un Fast Leader Handoff, que Anza anticipa en menos del 1% de los slots. En última, solo los datos de medición posteriores al epoch 1064 mostrarán si Votor alcanza los 150 milisegundos en la operación diaria.