Solana Alpenglow explicado: qué cambia Votor en el consenso

Puntos clave

• Está previsto que Solana sustituya su consenso TowerBFT por Votor, la primera mitad del diseño Alpenglow, en mainnet-beta el miércoles 21 de octubre de 2026. Anza, desarrolladora del cliente de validador Agave, situó la entrada en funcionamiento hacia las 14:50 UTC.
• La Solana Foundation afirma que la finalidad debería bajar de unos 12,8 segundos a un objetivo de aproximadamente 150 milisegundos. La Foundation califica esa cifra como "una expectativa, no una constante".
• Según Anza, Votor tolera a la vez un 20 % de stake malicioso y otro 20 % de stake desconectado. TowerBFT toleraba menos del 33 % de stake malicioso.
• Rotor, la segunda mitad de Alpenglow, reemplazaría la capa de propagación de bloques Turbine. No forma parte del cambio de hoy y no tiene fecha de lanzamiento.
• El traspaso se produce en una red en funcionamiento, sin reinicio. Requiere que el 82 % del stake firme un "certificado génesis", y solo los clientes basados en Agave pueden participar en la migración.

Qué es Alpenglow

Alpenglow es un nuevo protocolo de consenso para Solana, diseñado por investigadores de Anza. El consenso es el proceso que usan los validadores para acordar qué bloques son definitivos. Desde su lanzamiento, la red ha utilizado TowerBFT, un sistema de votación ligado a Proof of History, el reloj criptográfico de Solana. Con TowerBFT, los validadores envían sus votos como transacciones ordinarias en la cadena. Esos votos ocupan una gran parte del espacio de bloque, y un bloque solo se considera definitivo tras muchas rondas de confirmaciones.

Alpenglow divide el trabajo en dos componentes. Votor se encarga de la votación y la finalidad. Rotor se encarga de cómo se mueven los datos de bloque entre validadores. Anza describe el cambio del 21 de octubre como la Fase 1: Votor se activa mientras se mantiene la capa de propagación Turbine existente. Los validadores aprobaron la propuesta general de Alpenglow en una votación de gobernanza en septiembre de 2025. Decrypt informó que alrededor del 98 % de los votos emitidos fueron a favor.

Anza presenta la migración como la primera del mundo en intercambiar motores de consenso en una red en funcionamiento, según la información de Solana Compass sobre su anuncio. Es una afirmación de la propia Anza, y Bullquill no la ha verificado de forma independiente. La empresa también describió el esfuerzo como 18 meses de trabajo para una migración que ocurre en un solo slot.

Cómo cambia Votor el consenso

La página de la actualización de la Solana Foundation expone tres cambios principales.

Los votos salen de la cadena

Con Votor, los validadores se envían los votos directamente entre sí en lugar de hacerlo como transacciones. Después, esos votos se agregan en certificados compactos mediante firmas BLS. Las claves BLS de los validadores se activaron en mainnet el 8 de julio de 2026 como trabajo preparatorio. Los certificados se registran en un "pie" (footer) del bloque en lugar de como transacciones de voto individuales.

Dos vías hacia la finalidad

Votor ejecuta dos vías de votación al mismo tiempo, y prevalece la primera que finaliza un bloque. En la vía rápida, un bloque es definitivo tras una ronda si al menos el 80 % del stake vota para notarizarlo. Si no se alcanza ese umbral, una segunda ronda finaliza el bloque con el 60 % del stake. Los mismos umbrales del 60 % se aplican a los certificados de notarización y de omisión (skip). La página de Alpenglow de Anza señala que la geografía influye en qué vía gana, porque la velocidad de los votos depende de dónde se encuentran los validadores.

Proof of History deja de marcar el ritmo de los bloques

La Foundation indica que los ticks salen del ledger y que la marca de tiempo del sysvar Clock la fija el líder del bloque dentro de unos límites. Por tanto, Proof of History ya no marca el ritmo de producción de bloques. Por separado, los tiempos de slot se redujeron de 400 ms a 200 ms en cuatro etapas durante octubre de 2026. La Foundation subraya que el tiempo de bloque y la finalidad son medidas distintas.

Las cifras: parámetros de diseño confirmados frente a objetivos

La tabla siguiente recoge las cifras principales e indica qué tipo de afirmación es cada una. "Parámetro de diseño" significa una regla escrita en la especificación del protocolo. "Objetivo" significa una meta de rendimiento que aún no se ha medido en mainnet.

Datos a la fecha de investigación de este artículo, el 21 de octubre de 2026, según las fuentes indicadas más abajo.

Si se alcanza el objetivo, pasar de 12,8 segundos a 150 milisegundos haría la finalidad unas 85 veces más rápida. En mayo de 2026, el economista jefe de Anza, Max Resnick, dijo a Decrypt que el tiempo hasta la finalidad "bajó ~100 veces" cuando los clústeres de prueba pasaron de TowerBFT a Alpenglow. Ninguna de las dos cifras se ha medido todavía con la carga completa de mainnet.

Cómo debe producirse el cambio

El procedimiento de migración está definido en SIMD-0384, escrito por Kobi Sliwinski, Ashwin Sekar y Carl Lin, de Anza. La página de la Solana Foundation y la especificación describen la siguiente secuencia:

1. Feature gate. La función Alpenglow se activa al inicio de la época 1064. Anza afirma que "nada migra de inmediato". TowerBFT sigue funcionando durante los primeros 5.000 slots de la época.
2. Bloques solo de votos. Tras esos 5.000 slots, los bloques solo pueden contener votos de validadores. Las transacciones de los usuarios se pausan durante este intervalo. La Foundation sitúa la toma del consenso en el slot 459.653.000.
3. Certificado génesis. Los validadores eligen un bloque reciente como punto de partida, o "bloque génesis", de Alpenglow y firman votos BLS por él. Cuando al menos el 82 % del stake ha firmado, se forma un certificado génesis.
4. Reversión y traspaso. Los validadores descartan los bloques solo de votos posteriores al bloque génesis, ceden el consenso a Votor y reanudan las transacciones de los usuarios. SIMD-0384 indica que el efecto sobre las transacciones de los usuarios es "en el mejor de los casos, solo un slot más allá del slot límite de la migración". Anza prevé que el traspaso dure cientos de milisegundos.

El horario es una estimación

Los horarios publicados no coinciden. La Solana Foundation estima que la época 1064 comienza hacia las 13:20 UTC. El anuncio de Anza, según Solana Compass, sitúa la entrada en funcionamiento hacia las 14:50 UTC. Solana Compass señaló que Anza no precisó si las 14:50 UTC se refieren a la activación del feature gate o al traspaso. Los límites de época dependen de la velocidad con que se producen los slots, por lo que el momento exacto puede variar. La página de Alpenglow de Anza también indica que la migración de mainnet "se anunciará" después de que su periodo de observación confirme las pruebas anteriores. Al redactar este artículo, Bullquill no había encontrado una confirmación pública de que se hubiera formado el certificado génesis de mainnet.

La propia fecha también cambió. A finales de septiembre, algunos informes apuntaban a que la activación podría producirse el 28 de septiembre. El cofundador de Solana Anatoly Yakovenko y el director de investigación de Anza Roger Wattenhofer desmintieron esos informes en X, según KuCoin News. Después, testnet migró el 24 de septiembre y devnet el 25 de septiembre, antes de que se fijara la fecha del 21 de octubre.

Qué deben tener listo los validadores

• Cliente. La Solana Foundation indica que los validadores deben ejecutar la v4.3.2 de Agave, Jito-Solana o Harmonic Salsa antes de la época 1064. Firedancer y Frankendancer no son compatibles durante la migración.
• Saldo de la vote account. Los validadores deben mantener al menos 0,8 SOL por encima del mínimo exento de renta (rent-exempt) en la vote account (no en la identity account) para pagar el Validator Admission Ticket. El primer ticket se cobra al inicio de la época 1064 y cubre la época 1065. Un validador que no pueda pagar no vota ni produce bloques en la época siguiente.
• Stake fuera de los clientes compatibles. El 13 de octubre, Solana Compass contabilizó alrededor del 15,8 % del stake de los 500 principales validadores en clientes de la familia Firedancer. Según sus cálculos, eso deja cerca del 84 % en clientes compatibles, apenas por encima del umbral génesis del 82 %. Esa instantánea tiene una semana y los operadores pueden haber cambiado de cliente desde entonces.
• Jito BAM. Según la lectura que hace Solana Compass del registro de cambios de Jito, Jito indicó que los nodos BAM de mainnet entrarían en modo de mantenimiento antes de la activación y desaconsejó ejecutar FireBAM o FrankenBAM durante la transición.

Qué notarán los desarrolladores y los usuarios

• Menos transacciones contabilizadas sin que haya menos actividad. Los votos salen de los bloques, por lo que los paneles que cuentan todas las transacciones mostrarán una fuerte caída. En los datos del 10 al 12 de octubre citados por Solana Compass, los votos promediaron unos 3.060 por segundo, frente a unas 1.780 transacciones de usuarios por segundo. La Foundation lo califica como "un cambio contable".
• Niveles de commitment. processed, confirmed y finalized se mantienen, y no se requiere ningún cambio de código el día de la activación. Tras la activación, confirmed y finalized describen el mismo estado, y confirmed se eliminará en una versión posterior. La Foundation aconseja cambiar el código a finalized solo cuando Alpenglow esté activo.
• Comprobar si el cambio ya se produjo. El método RPC getAgGenesisCert devuelve null mientras el clúster funciona con TowerBFT y devuelve un certificado tras la migración. Los nodos RPC anteriores a la v4.3 devuelven un error "Method not found". La Foundation aconseja condicionar la lógica específica de Alpenglow a esta llamada y no a una fecha.
• Canalizaciones de datos. Un slot puede contener ahora más de un bloque candidato. La Foundation aconseja a los consumidores de Geyser y gRPC almacenar los datos en búfer por slot y por bank_id.

Para los usuarios comunes, el principal cambio esperado es que las transacciones alcancen una finalidad plena e irreversible mucho más rápido. La Foundation no promete ningún cambio concreto en comisiones ni en rendimiento derivado únicamente de Votor.

Qué está confirmado, qué está programado y qué no está verificado

Qué significa

Alpenglow es el mayor cambio hasta la fecha en el protocolo central de Solana. Sustituye el sistema de votación que la red ha usado desde su lanzamiento. Si Votor cumple sus objetivos, las aplicaciones que necesitan certeza de liquidación, como pagos, exchanges y puentes entre cadenas, podrían considerar definitivas las transacciones en una fracción de segundo en lugar de esperar más de diez segundos. Sacar los votos de los bloques también cambia la forma de medir la actividad de la red, por lo que las comparaciones de transacciones por segundo antes y después del 21 de octubre no serán equivalentes.

También hay riesgos de ejecución reales. El traspaso depende de que el 82 % del stake ejecute software compatible en el momento adecuado, lo que deja un margen estrecho dada la proporción de stake en clientes de la familia Firedancer. La diversidad de clientes se reduce mientras dura la migración. El modelo de tolerancia a fallos es nuevo y solo se ha probado en redes de prueba. La cifra de 150 ms dependerá de la distribución del stake y de la geografía. Lo que conviene vigilar es si el certificado génesis se forma según lo previsto, cuánto dura la pausa de las transacciones de los usuarios, cómo son los tiempos de finalidad en los primeros días y cuándo reciben fecha Firedancer y Rotor.

Fuentes

• Solana Foundation: Alpenglow upgrade page
• Anza: Alpenglow
• SIMD-0384: Alpenglow migration (Solana Improvement Documents)
• Solana Compass: Anza sets Alpenglow mainnet date
• Decrypt: Solana Alpenglow upgrade begins testing ahead of full rollout
• KuCoin News: Solana developers deny Alpenglow mainnet activation on September 28
• Jito BAM changelog, September 23 to October 9

Este artículo es solo informativo y no constituye asesoramiento de inversión.