Alpenglow en Solana: cómo cambiará el consenso de la red
Cuando se habla de Alpenglow, la próxima evolución del consenso de Solana, es fácil quedarse con una cifra: una finalidad objetivo cercana a los 150 milisegundos.
Es una cifra llamativa, pero no explica por sí sola el alcance del cambio.
Alpenglow rediseña cómo Solana alcanza consenso, cómo se coordinan los votos y cómo se propagan los bloques por la red. También introduce nuevos componentes, como Votor, las BLS pubkeys y el Validator Admission Ticket (VAT), que forman parte de una transición progresiva y no de una única actualización.
Más que una mejora aislada de velocidad, Alpenglow prepara una nueva arquitectura para una red que ya opera a gran escala.
Qué es Alpenglow
Alpenglow es el nuevo protocolo de consenso que Solana está preparando para sustituir los mecanismos actuales de Proof of History y TowerBFT.
Su primera fase se centra en Votor, un algoritmo de votación diseñado para reducir la latencia de finalidad y simplificar la coordinación entre validadores. En el modelo actual, los votos se envían como transacciones on-chain. Con Votor, los validadores intercambiarán mensajes de voto directamente y utilizarán certificados criptográficos agregados para demostrar que se ha alcanzado consenso.
El diseño contempla dos rutas para finalizar bloques:
- una ruta rápida, en la que un bloque puede finalizarse tras una sola ronda cuando alcanza el umbral de participación necesario;
- una segunda ronda para los casos en los que no se alcanza ese umbral inicialmente.
Solana plantea una finalidad objetivo de alrededor de 150 ms, frente a una preconfirmación actual cercana a 400 ms y una finalidad de TowerBFT de unos 12,8 segundos.
A día de hoy no está disponible en mainnet; en cambio, es el objetivo de un cambio de consenso que todavía está en proceso de despliegue y validación.
Votor: votos off-chain y certificados agregados
La principal novedad de Alpenglow es Votor.
En lugar de convertir cada voto de un validador en una transacción on-chain, Votor permite que los votos se transmitan directamente entre participantes. Después, esos votos se agregan en certificados que reflejan el estado del consenso: notarización, finalización o descarte de un bloque.
Este cambio busca reducir parte de la carga de red asociada a las transacciones de voto y permitir una finalidad más ágil.
El protocolo también incorpora un modelo de resiliencia conocido como 20+20: está diseñado para mantener liveness incluso si hasta un 20% del stake se comporta de forma adversarial y otro 20% permanece offline.
No se trata solo de procesar más rápido. Se trata de revisar la forma en la que una red de validadores se coordina cuando opera a escala.
Rotor llegará después
Alpenglow no se limita a la votación.
Una fase posterior, denominada Rotor, está prevista para reemplazar progresivamente Turbine, el sistema actual de propagación de bloques de Solana. Rotor mantendrá el uso de erasure coding, pero cambiará el modelo de retransmisión desde una estructura en árbol hacia una única capa de relays.
El objetivo es reducir latencia en la distribución de datos entre nodos.
La distinción importa: Votor y Rotor forman parte de la misma dirección técnica, pero no se despliegan a la vez. La transición inicial se centra en la lógica de votación y finalidad; Rotor llegará en una fase posterior.
BLS pubkeys: la preparación criptográfica para Alpenglow
Para que Votor pueda agregar múltiples firmas en un único certificado, Solana necesita un tipo de firma distinto al utilizado actualmente en los vote accounts.
Aquí entran las BLS pubkeys.
Las firmas BLS permiten combinar muchas firmas sobre un mismo mensaje en una única prueba verificable. Esto hace posible que los certificados de consenso representen la participación de numerosos validadores sin tener que verificar cada firma individualmente.
La gestión de BLS pubkeys ya está activa en mainnet. Cada validador necesita una BLS pubkey adicional para prepararse para el nuevo modelo. No sustituye la identidad ed25519 actual del vote account, sino que añade una capa criptográfica específica para Alpenglow.
Es un prerrequisito técnico importante, pero registrar una BLS pubkey no activa Alpenglow por sí mismo.
Qué es el Validator Admission Ticket o VAT
El Validator Admission Ticket, conocido como VAT, es un feature gate independiente que define quién puede formar parte del set de validadores admitido para participar en consenso.
Cuando se active en mainnet, el VAT exigirá dos condiciones principales:
- tener una BLS pubkey registrada;
- encontrarse entre los 2.000 validadores con mayor stake en cada epoch.
Un validador que no cumpla esos requisitos queda fuera del set admitido, deja de votar y deja de percibir recompensas de inflación mientras permanezca en esa situación.
El VAT no debe confundirse con slashing. No es una penalización por comportamiento malicioso ni por una incidencia operativa. Es un mecanismo de admisión que prepara la red para el modelo de consenso de Alpenglow.
También es importante separar el VAT de la activación completa de Votor:
BLS prepara las claves. VAT controla la admisión. Alpenglow cambia el consenso.
Una nueva estructura para los costes de voto
El cambio de consenso también modifica cómo se estructuran algunos costes operativos de la red.
Con TowerBFT, los validadores envían transacciones de voto on-chain. Solana estima que esos costes se sitúan alrededor de 2 SOL por epoch para un validador que participa activamente.
Con Alpenglow, esos votos dejarán de publicarse como transacciones on-chain. En su lugar, los validadores admitidos asumirán una tarifa fija de 1,6 SOL por epoch a través del VAT.
Esta tarifa se quemará, en lugar de redistribuirse como una comisión para block producers.
La intención inicial es mantener una barrera económica comparable a los costes actuales de voto, pero dentro de una arquitectura distinta. No significa que los rewards vayan a cambiar automáticamente en una dirección concreta: la economía final de cada operación seguirá dependiendo del stake, las recompensas de la red, las comisiones, los costes de infraestructura y el rendimiento efectivo.
Cómo cambia la observabilidad de la red
Un cambio de consenso también modifica qué métricas conviene observar y cómo interpretarlas.
Hasta ahora, una parte importante de la visibilidad sobre el rendimiento de los validadores de Solana procede de sus transacciones de voto, sus créditos y su actividad on-chain. Con Votor, los votos dejarán de seguir exactamente ese mismo flujo.
Los certificados y agregados seguirán reflejando la actividad de consenso, pero las herramientas de monitorización tendrán que incorporar el nuevo contexto para que las métricas sigan siendo útiles y comparables.
En Stakely ya trabajamos en hacer más visible la operación de Solana con el Solana TVC Live Tracker, una herramienta open source que permite seguir el estado de voto, los créditos y la actividad de los validadores bajo el modelo actual.
La llegada de Alpenglow refuerza la importancia de esa observabilidad: no basta con que una red sea rápida; también debe poder entenderse cómo está funcionando.
Qué queda por delante
Alpenglow se desplegará por fases. Las BLS pubkeys ya preparan a los validadores para el nuevo modelo, el VAT establecerá las condiciones de admisión y Votor cambiará la manera en la que Solana alcanza finalidad. Rotor ampliará más adelante esta evolución a la propagación de bloques.
El punto relevante no es anticipar una fecha cerrada ni dar por hecho un resultado de rendimiento antes de que el despliegue esté completo.
Alpenglow representa un cambio profundo en la forma de coordinar el consenso de Solana: menos dependencia de transacciones de voto on-chain, certificados criptográficos agregados, una finalidad objetivo mucho más rápida y una nueva estructura de admisión y costes para la red.
En Stakely seguiremos esta transición desde nuestra experiencia operando infraestructura en Solana. Si quieres participar directamente en la red, puedes hacer staking de SOL con Stakely desde tu propia wallet y mantener el control sobre tus activos.
