Alpenglow: la revolución del consenso en Solana que promete finalidad en milisegundos

Solana está a punto de experimentar su cambio de protocolo más relevante desde su lanzamiento. La actualización Alpenglow (propuesta formal SIMD-0326) reescribe por completo la arquitectura de consenso de la red, reemplazando dos de sus componentes fundamentales — Proof of History (PoH) y Tower BFT — por un nuevo algoritmo de votación llamado Votor y firmas agregadas basadas en BLS . La promesa principal: la finalidad de las transacciones se reduce de los ~12,8 segundos actuales a solo 100–150 milisegundos, una mejora de aproximadamente 100 veces .

Aquí tienes todo lo que necesitas saber sobre esta actualización: sus mecanismos técnicos, el despliegue escalonado a través del cliente validador Agave, las medidas de seguridad y el contexto general de la hoja de ruta de Solana en 2026.

Cómo Alpenglow transforma el consenso y la finalidad

Los cambios son profundos. La siguiente tabla resume las diferencias clave entre el consenso actual de Solana y lo que traerá Alpenglow:

Aspecto	Solana actual	Después de Alpenglow
Mecanismo de consenso	Proof of History (PoH) + Tower BFT	Algoritmo de votación Votor + firmas BLS
Finalidad de transacciones	~12,8 segundos (finalidad determinista de TowerBFT)	100–150 ms
Tolerancia a fallos	33%	40% en escenarios de fallo mixto
Votación de validadores	En cadena, escalada de votos en múltiples pasos	Fuera de cadena mediante Validator Admission Ticket (VAT); votos agregados con BLS

Votor es la pieza central. En lugar de la escalada de votos en múltiples capas que Tower BFT requería —32 rondas de votación con períodos de bloqueo acumulativos—, Votor permite a los validadores finalizar bloques en una o dos rondas . En la ruta rápida, un bloque se finaliza inmediatamente después de una ronda si al menos el 80% del stake total lo respalda, logrando la finalidad en unos 100 ms. Si el respaldo está entre el 60% y el 80%, se activa una segunda ronda, logrando la finalidad en aproximadamente 150 ms .

Mover los datos de votación fuera de la cadena mediante firmas agregadas BLS tiene otro beneficio importante: libera aproximadamente un tercio del espacio de bloque actual de Solana —que antes se usaba para registrar los votos individuales de los validadores como transacciones en cadena— para transacciones reales de usuarios .

Desarrollo y cronograma de despliegue: Agave 4.2 vs. 4.3

El despliegue se ha planificado deliberadamente en dos versiones del cliente validador Agave, la implementación principal mantenida por Anza. Este enfoque en dos fases permite que el código completo de Alpenglow se publique con anticipación para pruebas comunitarias, auditorías de seguridad y validación en clústeres de prueba antes de la activación en mainnet.

Agave 4.2 (agosto de 2026) — El campo de pruebas

• Recomendado para adopción en mainnet: agosto de 2026, con activaciones de funciones a partir de la semana del 17 de agosto .
• Qué activa en mainnet: tres actualizaciones no relacionadas con Alpenglow: una reducción de ~90% en las tarifas de alquiler en cadena, soporte para transacciones más grandes (nuevo formato Transaction v1) y el primer paso de una reducción del tiempo de slot en cinco etapas, de 400 ms a un objetivo de 200 ms . El primer decremento reduce los slots de 400 ms a 350 ms .
• Estado de Alpenglow en 4.2: El código completo de Alpenglow se incluye con todas las funciones, pero NO se activa en mainnet. Está empaquetado para su uso en clústeres de prueba comunitarios y revisión de seguridad .

Agave 4.3 (septiembre – octubre de 2026) — Activación en mainnet

• Activación prevista en mainnet: hay dos fechas públicas de fuentes oficiales. Anza publicó un cronograma el 12 de agosto que apunta al 28 de septiembre de 2026 para la activación de funciones en mainnet-beta . La Solana Foundation ha descrito el objetivo como octubre de 2026 .
• Qué activa: el consenso Alpenglow se activa en mainnet. Los validadores deben haber creado un Validator Admission Ticket (VAT) y actualizado la gestión de claves públicas BLS para participar .
• Incertidumbre clave: algunos informes y debates han apuntado a un lanzamiento en septiembre, pero la guía oficial de la Solana Foundation vincula la activación a Agave 4.3 con un objetivo en octubre . Las fechas siguen siendo objetivos, no garantías. El andamiaje técnico —aprobación de gobernanza, meses de pruebas en clúster, un bug bounty de seguridad, y el registro de claves BLS ya activo en mainnet— está en gran parte listo, pero no se ha publicado un bloque o época de activación exacta .

Medidas de seguridad: Bug bounty, pruebas y seguridad económica

Dada la magnitud del cambio, Anza y la Solana Foundation han implementado un enfoque de seguridad en múltiples capas:

• Bug bounty: Anza abrió un bug bounty dedicado a Alpenglow en GitHub, con presentaciones abiertas del 5 de agosto al 19 de agosto de 2026 . Las recompensas ascienden hasta 50.000 SOL (aproximadamente 3,8 millones de dólares) para investigadores que encuentren vulnerabilidades en los componentes centrales de Votor y BLS . El concurso se centra en cuatro módulos del repositorio anza-xyz/agave: votor (el motor de votación), votor-messages (serialización de votos y certificados), bls-sigverify y bls-cert-verify .
• Pruebas en múltiples fases: el código de Alpenglow está activo en un clúster de prueba comunitario de Anza desde el 11 de mayo de 2026, la primera vez que validadores externos pudieron ejecutarlo . Luego se incluyó en Agave 4.2 para pruebas comunitarias más amplias y revisión de seguridad antes de la activación en mainnet . Durante las primeras pruebas en clúster, se descubrieron y corrigieron al menos dos errores: uno en el código de migración de TowerBFT/PoH y otro en el que los validadores bloqueaban accidentalmente conexiones entre pares .
• Validator Admission Ticket (VAT): una tarifa fija de 1,6 SOL por época para que los validadores participen en el conjunto de consenso activo, diseñada para prevenir el spam y asegurar económicamente el conjunto de votación .
• Mayor tolerancia a fallos: el nuevo consenso eleva la tolerancia a fallos bizantinos en escenarios mixtos del 33% al 40%, mejorando la resiliencia ante situaciones donde hasta el 20% de los validadores se comportan maliciosamente y otro 20% está simultáneamente desconectado .

Contexto general: Alpenglow en la hoja de ruta de Solana para 2026

Alpenglow es una pieza del plan de infraestructura más amplio de Solana para 2026, cuyo objetivo es evolucionar la red hacia lo que el equipo denomina "Internet Capital Markets" — una plataforma financiera de alto rendimiento y grado institucional .

• Firedancer: un cliente validador independiente de Jump Crypto que ha superado el 20% del stake en mainnet después de aproximadamente 100 días . Firedancer y Alpenglow son complementarios: Firedancer mejora la diversidad de clientes y el rendimiento de ejecución (alcanzando 1 millón de TPS en pruebas), mientras que Alpenglow redefine la finalidad del consenso .
• ACE (Asynchronous Concurrent Execution): un nuevo modelo de ejecución diseñado para un ordenamiento de transacciones más justo y un mayor rendimiento bajo carga .
• DoubleZero / IBRL: mejoras en la capa de red y ancho de banda para reducir aún más la latencia de los validadores .
• Mandato de gobernanza: SIMD-0326 se aprobó con un 98,27% de aprobación de los validadores en septiembre de 2025, lo que refleja un consenso comunitario excepcionalmente sólido a favor del cambio .

En conjunto, estas actualizaciones posicionan a Solana para ofrecer una finalidad inferior a 150 ms, una capacidad máxima de un millón de TPS y redundancia de múltiples clientes, características que hacen que la red sea creíble como infraestructura para trading de alta frecuencia, cargas de trabajo financieras tradicionales y aplicaciones orientadas al consumidor que requieren liquidación casi instantánea .