Alpenglow cambia el consenso de Solana, no su ejecución
Para entender Alpenglow conviene separar dos cosas que suelen mezclarse: ejecutar una transacción y tener certeza de que esa transacción ya es final.
Solana puede procesar una operación rápidamente, pero bajo TowerBFT la finalidad fuerte tarda alrededor de 12,8 segundos. Hasta entonces existen niveles de compromiso anteriores, como processed y confirmed. Alpenglow intenta comprimir esa espera hasta llevar la finalidad al terreno de las décimas de segundo.
Si quieres situarlo dentro de la arquitectura general, nuestra explicación de cómo funciona una blockchain ayuda a distinguir producción de bloques, ejecución y consenso.
| Aspecto | Con TowerBFT | Con Alpenglow |
|---|---|---|
| Finalidad | Aproximadamente 12,8 segundos | Objetivo de alrededor de 150 ms; no es una latencia garantizada. |
| Votos de validadores | Se incluyen como transacciones en la cadena | Se envían directamente entre validadores y se resumen mediante certificados criptográficos. |
| Camino rápido | Basado en los lockouts de TowerBFT | Un bloque puede finalizar en una ronda si participa el 80% del stake. |
| Proof of History | Marca el ritmo mediante ticks | Deja de marcar la producción de bloques y desaparecen los tick entries. |
| Propagación de bloques | Turbine | Turbine continúa inicialmente; Rotor llegará en una fase posterior. |
| SVM, programas y formato de transacciones | Sistema actual | No cambian por Alpenglow. |
| Comisiones de usuario | Sistema actual | Alpenglow no modifica por sí mismo su mecánica. |
La diferencia más fácil de pasar por alto está en la primera fila: 150 ms es un objetivo de finalidad, no el tiempo de bloque, ni una cifra de TPS.
Votor: la pieza que hace posible una finalidad mucho más rápida
El corazón de la primera fase de Alpenglow se llama Votor. Sustituye la lógica de votación y finalización de TowerBFT.
Actualmente los votos de los validadores son transacciones que terminan formando parte del ledger. Con Votor, los validadores se envían los votos directamente entre sí. Esos votos llevan firmas criptográficas y pueden agregarse en certificados compactos mediante BLS.
Dicho de otra forma: que los votos dejen de aparecer como transacciones no significa que haya que «confiar» en que los validadores votaron. El certificado permite demostrar criptográficamente que se alcanzó el umbral requerido.
El proceso simplificado queda así:
- Un líder propone un bloque.
- Los validadores comprueban ese bloque y votan directamente.
- Si el 80% del stake lo notariza suficientemente rápido, se crea un certificado de finalización rápida y el bloque puede quedar final en una sola ronda.
- Si no se alcanza ese camino rápido, Votor dispone de una segunda ronda con umbrales del 60% para decidir de forma segura si finaliza un bloque o se salta ese slot.
La ventaja no sale de «hacer cálculos 100 veces más rápido», sino de necesitar muchas menos rondas y eliminar parte de la maquinaria que TowerBFT utilizaba para acumular votos y lockouts durante múltiples slots.
Qué significa la resistencia «20+20»
Alpenglow también introduce una propiedad que Anza denomina 20+20 resilience: puede seguir funcionando con hasta un 20% del stake actuando de forma adversarial y otro 20% adicional sin responder.
Hay un matiz importante. No significa que Alpenglow tolere un 40% de stake malicioso. Ese 40% está dividido entre dos tipos de fallo diferentes: hasta un 20% adversarial y un 20% adicional simplemente offline o no responsivo.
La idea encaja con el camino alternativo del protocolo: incluso si solo queda un 60% de stake útil y disponible, Votor conserva una vía para avanzar en dos rondas.
¿Desaparecen Proof of History y TowerBFT?
TowerBFT sí es sustituido como protocolo de consenso. Con Proof of History hay que ser algo más preciso.
Proof of History ha servido como una secuencia verificable para ordenar el paso del tiempo dentro de Solana. Con Alpenglow PoH deja de marcar el ritmo de la producción de bloques: desaparecen los ticks del flujo de datos y los timeouts y certificados de Votor pasan a cumplir parte de esa función de coordinación.
Eso no significa que Solana se quede «sin tiempo», ni que desaparezcan los slots. Cambia la forma en que el protocolo coordina y observa el avance dentro de ellos.
Y tampoco desaparece el Proof of Stake. El stake continúa siendo fundamental: los umbrales del 60% y 80% se calculan precisamente sobre stake, no contando un voto idéntico por cada máquina.
Esta distinción importa porque es fácil leer que «Alpenglow sustituye Proof of History» y concluir que Solana abandona su modelo Proof of Stake. No es así.
Rotor llegará después: Alpenglow no se activa entero de una vez
El diseño original de Alpenglow incluye otro componente llamado Rotor, encargado de cómo se distribuyen los datos de los bloques por la red.
Hoy esa función depende de Turbine, que divide los bloques en fragmentos y los distribuye mediante una estructura de múltiples saltos. Rotor conserva la idea de aprovechar el ancho de banda conjunto de los nodos, pero plantea una capa de relays mucho más plana para reducir el número de saltos y, con ello, la latencia de red.
Pero aquí aparece otro matiz que buena parte de las explicaciones sobre Alpenglow se saltan: Rotor no forma parte de la primera activación.
La primera fase es Votor. Turbine seguirá utilizándose inicialmente para distribuir los bloques y Rotor llegará en una versión posterior todavía sin calendario fijado.
Así que describir la próxima actualización como «Votor y Rotor sustituyen ya a todo el sistema anterior» se adelanta a lo que realmente se está desplegando.
Qué notarás tú como usuario de Solana
Para alguien que simplemente utiliza una wallet, intercambia tokens o interactúa con aplicaciones, la migración debería ser bastante aburrida en el buen sentido: no necesitas convertir SOL, cambiar de dirección ni migrar tus tokens.
La firma de transacciones y la SVM siguen funcionando igual. La mejora está detrás: una aplicación podrá recibir una garantía de finalidad mucho antes. La propia documentación de Solana indica que, para los usuarios, no hay ninguna migración que realizar.
Eso puede tener consecuencias bastante más interesantes de lo que parece.
Pagos
Si una operación puede ser final en una fracción de segundo, un comercio no tiene que elegir tanto entre esperar una garantía fuerte o aceptar una confirmación anterior con menor certeza.
Es especialmente relevante para pagos en puntos de venta y otros casos donde diez segundos se sienten eternos aunque, técnicamente, sigan siendo «rápidos» para una blockchain.
Exchanges y depósitos
Una plataforma que hoy espera finalidad completa podría acreditar depósitos más rápido cuando adapte su infraestructura. Eso no significa que todos los exchanges vayan a reducir automáticamente sus tiempos: las políticas de confirmación siguen siendo decisión de cada plataforma.
DeFi y trading
En DeFi, 150 ms frente a varios segundos puede importar bastante más que en una simple transferencia entre dos wallets.
Liquidaciones, mercados on-chain, agregadores y aplicaciones que reaccionan al estado de la red pueden beneficiarse de una certeza más temprana. Proyectos del ecosistema como Jupiter no cambian su lógica únicamente porque exista Alpenglow, pero sí trabajan sobre una infraestructura capaz de cerrar antes la diferencia entre «la operación parece confirmada» y «la operación es final».
Si tu interés principal es el activo en lugar del consenso, aquí explicamos por separado qué hay que saber sobre Solana y SOL.
Lo que Alpenglow no hace: más TPS, bloques de 150 ms y comisiones más baratas
Esta es probablemente la confusión más importante alrededor de la actualización.
Alpenglow no promete bloques cada 150 milisegundos. La reducción del tiempo de los slots de Solana es otra actualización distinta. La red está trabajando por separado en reducirlos desde los 400 ms históricos hacia los 200 ms.
Tampoco es correcto transformar la cifra de finalidad en un aumento equivalente de TPS. Alpenglow modifica cómo se alcanza el consenso; no multiplica automáticamente la capacidad computacional de la SVM.
De hecho, después de la migración puede ocurrir algo que parezca paradójico: algunos gráficos de TPS mostrarán cifras más bajas.
La explicación no sería necesariamente una caída de actividad. Los votos de los validadores dejarán de contar como transacciones dentro de los bloques. Solana advierte expresamente de que herramientas que mezclen operaciones de usuario y votos tendrán que recalibrar sus comparaciones históricas.
Y las comisiones de las transacciones de usuario tampoco bajan automáticamente. Alpenglow deja intacta la mecánica de ejecución y fees. Si otra actualización aumenta capacidad o modifica el mercado de comisiones, será otro cambio del protocolo, no una consecuencia automática de Votor.
Para desarrolladores, el cambio sí puede ser bastante más serio
Una dApp que simplemente envía transacciones y consulta cuentas probablemente tenga poco que hacer. Para indexadores, exploradores, proveedores RPC y sistemas que consumen los bloques en tiempo real, la historia es distinta.
Uno de los cambios más visibles será la relación entre confirmed y finalized. Bajo TowerBFT puede existir una diferencia temporal significativa entre ambos niveles. Con Votor, la finalidad llega tan pronto que ambos convergen; Solana prevé deprecar posteriormente confirmed en favor de finalized.
También aparecen varios cambios de infraestructura:
- Los votos de consenso dejan de estar dentro de los bloques como transacciones.
- Las herramientas que dependen de los ticks de Proof of History tienen que cambiar su forma de medir el avance dentro del slot.
- Geyser y gRPC incorporan
bank_id, porque un mismo slot puede tener más de un banco candidato y el consumidor debe distinguirlos. - Las métricas basadas en contar todas las transacciones del bloque necesitan una nueva línea base.
Para el usuario medio nada de esto debería ser visible. Para quien mantiene un indexador de alta frecuencia, un explorador o infraestructura de trading, sí es una migración que conviene tomarse en serio.
Los validadores también cambian su forma de votar y sus costes
Votor necesita que los validadores dispongan de claves BLS, porque las firmas de muchos participantes deben poder agregarse de forma eficiente en certificados.
Solana ya ha activado en mainnet los prerrequisitos correspondientes a las claves BLS y al Validator Admission Ticket (VAT). El VAT establece además un conjunto admitido de hasta 2.000 validadores por época. Estas medidas preparan a la red para Alpenglow, pero su activación no significa que Alpenglow ya esté funcionando en mainnet.
La economía del voto también cambia. Con TowerBFT los validadores pagan comisiones para publicar continuamente sus votos como transacciones. Al salir esos votos del ledger, ese coste desaparece como tal y el VAT mantiene un coste de admisión que se quema.
Es un cambio operativo relevante, pero no conviene confundirlo con la rentabilidad que recibe alguien simplemente por delegar SOL. Si utilizas staking, siguen importando cuestiones independientes como la comisión del validador, el rendimiento real y los riesgos asociados al staking.
¿Alpenglow ya está activo en Solana?
Todavía no en mainnet. Esta distinción es especialmente importante porque la actualización ha pasado por varias etapas y se han publicado fechas que después se han interpretado como si fueran el lanzamiento definitivo.
La propuesta SIMD-0326 recibió el apoyo de la gobernanza en septiembre de 2025: el 98,27% de los votos emitidos fue favorable y participó aproximadamente el 52% del stake. Aquella votación daba apoyo al cambio de dirección del consenso, pero no activaba automáticamente el protocolo.
Desde entonces se han desplegado prerrequisitos y Agave 4.3 ya incorpora el software necesario para Alpenglow. La versión estable de Agave 4.3 fue publicada en septiembre de 2026 para testnet, devnet y mainnet-beta.
Aun así, tener Agave 4.3 instalado no equivale a haber cambiado el consenso. La página oficial de Alpenglow muestra el feature gate activo en testnet y devnet, pero no en mainnet. Además, la propia documentación recomienda comprobar el certificado de génesis de Alpenglow en cada cluster en vez de deducir la activación por una fecha o por la versión del cliente.
Esto también aclara el ruido alrededor del 28 de septiembre de 2026. Esa fecha aparecía en el calendario de Agave como momento para reanudar la activación general de feature gates en mainnet, no como una fecha confirmada para Alpenglow. Los propios desarrolladores rechazaron públicamente esa interpretación.
Por tanto, el mapa real es este:
- Votor: ya dispone de implementación y está activo en redes de prueba, pero la transición de consenso de mainnet todavía no se ha producido.
- Rotor: llegará después de Votor y sigue sin una fecha de despliegue fijada.
- Usuarios normales: no tienen que migrar fondos ni cambiar sus wallets.
- Validadores e infraestructura: sí tienen trabajo técnico que hacer antes y durante la transición.
Qué puede significar Alpenglow para SOL
Alpenglow es relevante para SOL porque mejora una característica básica de la red sobre la que existe el activo: cuánto tarda el sistema en llegar a una certeza fuerte sobre una transacción.
Una finalidad mucho más rápida puede hacer que Solana resulte más práctica para pagos, mercados on-chain y servicios donde la latencia importa. Si esas mejoras terminan traduciéndose en más uso, más aplicaciones o mayor actividad económica, pueden reforzar la utilidad de la red.
Pero hay un salto que no conviene hacer: una mejora técnica no determina por sí sola el precio de SOL.
Alpenglow no convierte 150 ms de finalidad en un porcentaje de rentabilidad, ni garantiza más demanda del token. El precio sigue dependiendo de adopción, liquidez, expectativas, emisión, staking, actividad económica y del mercado cripto en general.
Por eso, si estás valorando SOL como inversión, resulta más útil analizar la criptomoneda con varios factores que construir la tesis alrededor de una sola actualización. Y una red técnicamente mejor tampoco elimina los riesgos propios de invertir en criptoactivos.
Lo realmente importante de Alpenglow
La mejor forma de entender Alpenglow no es decir que «Solana será 100 veces más rápida». Esa frase mezcla demasiadas métricas.
Lo que Solana está intentando acelerar de forma radical es la finalidad: pasar de esperar unos 12,8 segundos por la garantía fuerte de TowerBFT a obtener una certeza equivalente alrededor de los 150 ms en condiciones favorables. Para lograrlo, sustituye la votación on-chain por Votor, utiliza certificados agregados, deja atrás el papel de Proof of History como reloj del protocolo y, en una fase posterior, quiere mejorar también la propagación con Rotor.
Si funciona como está diseñado, el cambio importante no será ver una cifra más grande de TPS en una web. Será que una aplicación pueda tratar una operación como definitiva prácticamente al mismo ritmo al que una persona percibe que una interfaz responde.
Aviso de riesgo: SOL y el resto de criptoactivos son volátiles y puedes perder parte o la totalidad del capital invertido. Este contenido tiene fines informativos y no constituye asesoramiento financiero.
