Solana Alpenglow: cómo Votor y Rotor buscan recortar la finalidad a 150 ms

La promesa de Alpenglow no es que Solana parezca un poco más rápida. Es más ambiciosa: cambiar la forma en que la red llega a consenso. Formalizada como SIMD-0326, la propuesta plantea sustituir los mecanismos actuales de Proof of History y Tower BFT por una arquitectura centrada en dos piezas: Votor, para votación y finalidad, y Rotor, para diseminar los datos de los bloques. El objetivo más llamativo es bajar la finalidad desde 12,8 segundos bajo Tower BFT hasta un rango de 100–150 milisegundos .

La propuesta ya superó la gobernanza de Solana, pero eso no equivale a una activación inmediata en la red principal, o mainnet. La fecha exacta sigue dependiendo de pruebas, implementación y preparación de clientes y validadores .

Por qué Solana quiere cambiar su capa de consenso

Solana ya es conocida por su baja latencia, pero Alpenglow apunta a una parte más profunda del sistema. Hoy, la arquitectura de la red usa Proof of History como mecanismo criptográfico de orden temporal: los nodos líderes marcan bloques con pruebas verificables por los validadores . Después, Tower BFT construye consenso acumulando votos de validadores con bloqueos, donde cada voto confirma una bifurcación y aumenta el bloqueo de votos anteriores .

Ese diseño ha permitido confirmaciones optimistas rápidas. Sin embargo, Alpenglow no se enfoca solo en que una transacción se sienta rápida para el usuario, sino en la finalidad: el punto más fuerte en el que el consenso considera que una transacción está asentada. La hoja de ruta de Anza describe la finalidad optimista actual de Solana en torno a un segundo, mientras que SIMD-0326 compara los 12,8 segundos de finalidad de Tower BFT con el rango propuesto de 100–150 ms bajo Alpenglow .

En términos sencillos: una confirmación optimista puede bastar para muchas experiencias de usuario, pero la finalidad determinística es la señal más robusta para intercambios, aplicaciones financieras, puentes y sistemas que necesitan liquidación rápida con menor incertidumbre.

Votor: menos vueltas para votar y finalizar

Votor es el componente de Alpenglow que tomaría el relevo de la lógica de votación y finalización de bloques . En SIMD-0326 se describe como un protocolo ligero, basado en voto directo, capaz de finalizar bloques mediante un proceso de una o dos rondas según las condiciones de la red .

El cambio es relevante porque se aleja de la torre de votos con bloqueos de Tower BFT. En lugar de depender de una secuencia más larga de votos que van reforzando bloqueos previos, Votor busca alcanzar finalidad en una o dos rondas cuando participa suficiente stake. Algunos resúmenes técnicos externos hablan de umbrales de stake en el rango del 60 % al 80 %, aunque la lectura más prudente desde la fuente primaria es el modelo de finalización en una o dos rondas descrito por SIMD-0326 .

Anza también ha señalado que Alpenglow aprovecha primitivas criptográficas BLS para reducir la latencia de finalización sin renunciar a la seguridad . La idea, por tanto, no es solo emitir un mensaje de confirmación más rápido, sino acortar el camino hasta una finalidad más determinística.

Rotor: si el bloque no llega rápido, el voto tampoco

Rotor es el protocolo de diseminación de datos de Alpenglow. Anza lo presenta como una evolución que adopta y refina el enfoque de Turbine, el sistema actual de entrega de bloques de Solana . Su función es práctica: Votor solo puede finalizar con rapidez si los validadores reciben los datos del bloque a tiempo para evaluarlos y votar.

Algunos análisis externos describen Rotor como un esquema con rutas de retransmisión más estructuradas y ponderadas por stake. Esos resúmenes citan objetivos de propagación por debajo de 100 ms, e incluso una estimación de 18 ms bajo condiciones típicas de red . Conviene leer esas cifras como metas o estimaciones, no como resultados ya demostrados en mainnet. Aun así, explican por qué Rotor y Votor van juntos: una votación más rápida necesita una distribución de bloques igualmente rápida y predecible.

Qué mejoras promete, y dónde están las cautelas

Área	Cambio esperado	Matiz importante
Finalidad	La meta principal es bajar de 12,8 segundos bajo Tower BFT a unos 100–150 ms con Alpenglow .	Solana ya cuenta con confirmación optimista más rápida, descrita por Anza en torno a un segundo; el salto clave está en la finalidad de consenso más fuerte .
Propagación de bloques	Rotor busca hacer la distribución de bloques más veloz y predecible; análisis externos citan metas por debajo de 100 ms y una estimación de 18 ms en condiciones típicas .	Todavía no son mediciones consolidadas de mainnet.
Throughput y espacio de bloque	Alchemy afirma que los votos de validadores consumen hoy alrededor del 75 % del espacio de bloque de Solana, y que mover la votación fuera de la cadena podría liberar buena parte de ese espacio para transacciones de usuarios .	Alpenglow es ante todo una mejora de consenso y finalidad; cualquier ganancia de throughput sería indirecta, no una subida garantizada de TPS brutos .
Costes de validadores	Si se publican menos votos de consenso como transacciones on-chain, los validadores deberían enfrentar menos presión recurrente por comisiones de voto; un resumen también menciona un modelo Validator Admission Ticket como cambio relacionado con costes .	El ahorro real dependerá de la implementación final, las comisiones y la economía de la red.
Sobrecarga de red	Algunos resúmenes técnicos estiman menor comunicación entre validadores, incluida una reducción aproximada del 40 % .	Sigue siendo una proyección hasta que pueda medirse tras el despliegue.

La forma más clara de resumirlo es esta: la promesa directa de Alpenglow es una finalidad de menor latencia. Sus posibles mejoras en capacidad y costes vienen de reducir tráfico de consenso, sobre todo el peso de los votos, no de rehacer toda la ejecución de Solana.

Calendario: de la propuesta a una posible mainnet

Anza presentó Alpenglow como un nuevo protocolo de consenso y lo describió como el mayor cambio en el protocolo base de Solana hasta la fecha . La propuesta formal SIMD-0326 se publicó en agosto de 2025 y la definió como una gran revisión del consenso central de Solana . La votación comenzó más tarde ese mes: SolanaFloor informó de una ventana desde la epoch 840 hasta la epoch 842 .

La gobernanza aprobó la propuesta a comienzos de septiembre de 2025. Los reportes publicados difieren ligeramente en el porcentaje exacto: Alchemy cita un 98,27 % de aprobación, mientras Blockworks informa de un 98,94 % de participantes a favor; ambos hablan de una participación cercana al 52 % del stake . El punto común es claro: la propuesta superó la gobernanza con apoyo abrumador de los validadores.

El paso de pruebas a mainnet es menos definitivo. La hoja de ruta de Anza hablaba de una llegada a mainnet a comienzos de 2026, mientras que un resumen posterior de Alchemy, publicado en abril de 2026, indicó que Alpenglow estaba en pruebas en clúster privado y que se esperaba en mainnet a finales de 2026 . Anza también señaló que su foco en 2026 era sacar Alpenglow de clústeres de desarrollo y llevarlo hacia un despliegue más amplio .

Con las fuentes disponibles, el calendario más prudente queda así: propuesta y gobernanza en el tercer trimestre de 2025; desarrollo y pruebas en clústeres privados durante 2026; y posible despliegue en mainnet en 2026, con finales de 2026 como expectativa más conservadora si las pruebas siguen siendo el factor decisivo .

La lectura de fondo

Si se implementa como está planteado, Alpenglow sería uno de los cambios más importantes en la historia técnica de Solana. Votor busca comprimir la votación y la finalidad en una o dos rondas rápidas; Rotor busca mover los datos de bloque por la red de validadores con la velocidad suficiente para sostener ese consenso de baja latencia .

El titular de los 100–150 ms es potente, pero aún debe leerse como una meta de ingeniería hasta que se pruebe en mainnet. La actualización ya tiene impulso de gobernanza; la activación real dependerá de las pruebas, de la preparación de los clientes y de que las reducciones proyectadas en sobrecarga de votos y costes de validadores se sostengan bajo condiciones reales de red .