Solana Alpenglow: la mayor renovación de consenso en la historia de Solana
Autor: Uttam Singh

Hoy, las transacciones de Solana tardan 12.8 segundos en finalizar. A partir del 21 de octubre de 2026, eso baja a 150 milisegundos, en toda la mainnet.
El cambio es Alpenglow, la mayor actualización de consenso de Solana desde su lanzamiento. Elimina Proof of History y Tower BFT, los dos sistemas que han definido cómo la red llega a un acuerdo desde el primer día, y los reemplaza con un diseño más simple y mucho más rápido. Pasó la gobernanza con 98.27% de aprobación y está programado para activarse en mainnet en el epoch 1064, que comienza alrededor de las 13:20 UTC del 21 de octubre, y Votor tomará el control en el slot 459,653,000, unos 18 minutos después del inicio.
Aquí está lo que puedes esperar cuando ocurra el cambio, cómo se está preparando Alchemy y qué es lo que realmente cambia por dentro. Como fuente de verdad a nivel de protocolo, consulta la página de la actualización Alpenglow de la Solana Foundation y SIMD-0326, la propuesta de gobernanza que lo especifica.
Qué esperar cuando ocurra el cambio en mainnet
Un nuevo epoch (la ventana de programación de Solana, de aproximadamente dos días) comienza alrededor de las 13:20 UTC del 21 de octubre. Como los epochs siempre duran lo mismo, ya conocemos el slot exacto en el que ocurre el cambio: 459,653,000. Pero la red no cambiará en el instante en que empieza el epoch. Durante los primeros 18 minutos aproximadamente, sigue usando el método de consenso anterior, Tower BFT, antes de pasar a Votor, el reemplazo de Alpenglow, justo en ese slot. Esto solo cambia cómo la red se pone de acuerdo internamente sobre las transacciones, no cómo te comunicas con ella, por lo que se espera que los endpoints de RPC, WebSocket y gRPC sigan funcionando con normalidad todo el tiempo.
Se espera que el cambio en sí tome unos dos bloques, aproximadamente 400 milisegundos, mientras suficiente parte de la red confirma que está lista. Durante esa breve ventana, los bloques nuevos solo contendrán votos de validadores, sin transacciones de usuarios. Nada debería ser rechazado: una transacción enviada justo en ese momento debería llegar un instante después, cuando termine el cambio.
Un efecto secundario que conviene avisar a tu equipo con anticipación: el conteo de transacciones y el TPS en los dashboards públicos se verán más bajos justo después de la activación. No será menos uso, sino que los votos de validadores dejarán de contar como transacciones. Por eso también Alpenglow libera el 75% del espacio de bloque: los votos solían ocupar la mayor parte, y ahora ya no.
Una vez que ocurra la activación, puedes verificar si una red ya cambió llamando a getAgGenesisCert. No devuelve nada antes del cambio y devuelve un resultado (con detalles como el slot exacto) después.
Cómo se preparó Alchemy para Alpenglow
Todos los nodos de RPC de Solana de Alchemy ya ejecutan un cliente compatible con Alpenglow antes de la activación, por lo que los endpoints de RPC, WebSocket y Yellowstone gRPC no necesitarán ningún cambio de tu parte. Nuestro enrutamiento de transacciones también ya reintenta contra otro backend cuando un validador se retrasa brevemente respecto a los nuevos tiempos de finalidad, la misma protección que hoy maneja a los servidores que se retrasan de forma normal.
Aprovecha Alchemy para RPC de Solana de primer nivel, datos archivales y streaming gRPC, usado por equipos líderes en Solana como Phantom, Solflare, Cielo Finance y más:
- 9.21ms de latencia de lectura promedio, aproximadamente 26% más rápido que el siguiente proveedor, medido durante las 24 horas que terminaron el 29 de septiembre de 2026
- Consultas archivales hasta 20 veces más rápidas y 10 veces más rápidas en llamadas pesadas como
getProgramAccounts, con tiempos de respuesta inferiores a 200ms en consultas históricas grandes (validado en producción por Solflare) - SLA de uptime de 99.99% y el doble de throughput que la pila de generación anterior
- gRPC compatible con Yellowstone con entrega promedio de 5-15ms y repetición de bloques de 48 horas, aproximadamente 5 veces más económico que las alternativas
Si transmites datos de Solana directamente, este también es un buen momento para revisar la versión de tu cliente de Yellowstone gRPC y confirmar que solo estás haciendo commit de datos confirmados durante cualquier ventana de migración. Y como confirmed y finalized ahora se resuelven en el mismo punto, los flujos que antes esperaban a finalized, como el acreditado de depósitos, probablemente puedan avanzar más rápido.
Obtén un endpoint RPC gratuito de Solana →
Todo sobre Alpenglow
Cómo Votor y Rotor reemplazan a Tower BFT y Turbine
Alpenglow funciona con dos protocolos nuevos: Votor, que se encarga de la votación y la finalización, y Rotor, que se encarga de la propagación de bloques. La investigación salió del laboratorio de sistemas distribuidos del profesor Wattenhofer en ETH Zurich, con Anza liderando la implementación y el equipo de Firedancer de Jump Crypto trabajando en la compatibilidad multi-cliente.
Cómo la finalidad se vuelve 85 veces más rápida
Tower BFT necesita 32 confirmaciones incrementales, y cada una agrega un período de lockout. Votor lo reduce a una o dos rondas de votación.
- Ruta rápida (~100ms): más del 80% de los validadores aprueban en la primera ronda, listo.
- Ruta lenta (~150ms): entre 60-80% aprueba en la ronda uno, y una segunda ronda lo resuelve con un umbral de más del 60%.
Ambas rutas corren a la vez, y gana la que termine primero. En simulaciones, el 65% del stake finaliza dentro de los 50ms de latencia de red bruta.
Los validadores se envían los votos directamente entre sí como mensajes pequeños, en lugar de como transacciones en la red. Votor luego comprime miles de esos votos en una sola prueba de ~1,000 bytes usando una técnica de combinación de firmas llamada agregación BLS, de modo que solo se registra esa pequeña prueba, en lugar de los ~500KB de datos de voto que hoy se registran por bloque.
Si indexas o consultas ese estado directamente, las llamadas más pesadas como getProgramAccounts ya se ejecutan hasta 10 veces más rápido en la API de Solana de Alchemy, independientemente de las mejoras de tiempos de Alpenglow.
Cómo Alpenglow libera el 75% del espacio de bloque
Ahora mismo, alrededor del 75% de todas las transacciones de Solana son votos de validadores. Alpenglow mueve la votación completamente fuera de la cadena, de modo que ese espacio vuelve a los usuarios reales. No es un ajuste menor: tres cuartas partes de la capacidad de la red regresan al uso real, con comisiones más bajas y menos congestión en períodos de alta demanda.
Cómo Alpenglow retira Proof of History
Alpenglow también abandona el reloj criptográfico original de Solana. En lugar de una cadena de hash continua, los validadores ahora usan temporizadores simples ligados a cuánto debería tardar un bloque: si el bloque llega a tiempo, se aprueba; si el temporizador se agota sin nada, se salta. El desfase de reloj se maneja de forma proporcional: un 5% de desfase solo necesita un timeout 5% más largo.
El tiempo que toma producir cada bloque es un número distinto de la finalidad, y también cambió: cuatro recortes por etapas lo llevaron de 400ms a 200ms, completados este octubre antes de la activación de Alpenglow.
Cómo la finalidad pasa de tres niveles a uno
Este podría ser el cambio que más sientan los desarrolladores. Solana actualmente te da tres formas de verificar si una transacción se completó: processed (la más rápida, la menos segura), confirmed (~500ms, todavía con una pequeña posibilidad de reversión) y finalized (~12.8s, permanencia garantizada). Todo lo que no pueda tolerar ni siquiera una pequeña posibilidad de reversión, como los depósitos en exchanges, las confirmaciones de bridges y las liquidaciones, tiene que esperar a finalized. Todo lo demás se conforma con confirmed y acepta ese pequeño riesgo.
Alpenglow reduce confirmed y finalized a uno: 100-150ms, y cada transacción es permanente en el momento en que se confirma. Processed sigue siendo la etapa de observación más temprana y menos segura, así que no la trates como definitiva. Se acabó cambiar velocidad por certeza.
Eso abre patrones que antes no funcionaban. Order books con spreads más ajustados porque los market makers saben que una cotización es final en 150ms. Subastas JIT más baratas en los exchanges de perpetuos. Bridges cross-chain sin un cuello de botella de finalidad del lado de Solana. Depósitos en exchanges que pasan de una espera de 13 segundos a instantáneos. Y para bancos y fintechs, transacciones que se liquidan lo bastante rápido como para competir con los rieles de pago tradicionales en liquidación de stablecoins y transferencias transfronterizas.
La finalidad rápida y determinística también hace que las transacciones gasless sean una experiencia más limpia de construir en Solana, ya que tanto los patrocinadores como los usuarios finales obtienen una respuesta final en un solo paso, en lugar de esperar una ventana de confirmación.
Cómo Alpenglow cambia la economía de los validadores
Las comisiones de voto, de aproximadamente 1 SOL/día por validador, desaparecen. En su lugar: un Validator Admission Ticket de aproximadamente 0.8 SOL/día, quemado en su totalidad. La red tiene un tope de 2,000 validadores, empezando por el stake más alto. El stake mínimo rentable baja de ~4,850 SOL a ~450 SOL, una barrera aproximadamente 90% más baja para operar un validador, y los costos operativos en general bajan entre 20-50%. Las claves de identidad también pueden pasar a módulos de seguridad de hardware ahora que no firman votos constantemente.
Cómo Alpenglow cambia seguridad por velocidad
Alpenglow usa un modelo de seguridad "20+20". Por sí solo, puede tolerar menos validadores abiertamente maliciosos que antes: 20% de la red en lugar de 33%. Pero combinado con validadores offline o que no responden, puede tolerar hasta un 40% de la red fallando de alguna manera, más que el antiguo límite de 33%. Como las caídas del mundo real suelen ser una mezcla de validadores maliciosos y simplemente offline, ese número combinado es la medida más realista.
Las matemáticas siguen garantizando que dos versiones conflictivas de la historia no pueden ser aprobadas a la vez, ya que los dos umbrales de aprobación (80% y 60%) suman más del 100% de la red.
Cómo llegó hasta aquí el despliegue de Alpenglow
Alpenglow se presentó en Solana Accelerate en mayo de 2025, pasó la gobernanza ese septiembre (SIMD-0326), avanzó por pruebas en clúster privado y el lanzamiento de Agave 4.1, llegó a devnet en septiembre de 2026 y está programado para activarse en mainnet en el epoch 1064 este 21 de octubre. Algunas piezas del whitepaper original, como smart sampling, la ejecución asíncrona y refinamientos adicionales de Rotor, quedan reservadas para propuestas futuras.
Resultado neto: un reemplazo completo del consenso en una red en vivo, transacciones permanentes en menos de 200ms, 75% del espacio de bloque liberado y una barrera 90% más baja para operar un validador.
Preguntas frecuentes
¿Cuándo se activa Alpenglow en la mainnet de Solana?
Epoch 1064, alrededor de las 13:20 UTC del 21 de octubre de 2026. Votor tomará el control en el slot 459,653,000, aproximadamente 18 minutos después del inicio del epoch.
¿Alpenglow causará tiempo de inactividad?
No se espera tiempo de inactividad. El tráfico de RPC, WebSocket y gRPC debería funcionar con normalidad en todo momento. Se espera una breve pausa en las nuevas transacciones de usuarios, de unos 400ms, justo en el cambio, pero nada de lo enviado en ese momento debería perderse: debería llegar cuando el cambio termine.
¿Sigue siendo confirmed un nivel de commitment independiente después de Alpenglow?
No. Confirmed y finalized ahora se resuelven en el mismo punto de ~150ms, reemplazando el antiguo modelo de tres niveles.
¿Cómo verifico si una red ya cambió a Alpenglow?
Llama a getAgGenesisCert (Agave v4.3+). No devuelve nada si la red todavía está en Tower BFT, y devuelve un resultado si ya ejecuta Alpenglow.
¿Necesito cambiar mi integración de Solana con Alchemy para Alpenglow?
No. Los endpoints de RPC, WebSocket y Yellowstone gRPC no necesitarán ningún cambio: los nodos de Solana de Alchemy ya ejecutan un cliente compatible con Alpenglow.
Boletín de Alchemy
Entérate primero de los lanzamientos
Suscríbete a nuestro boletín
Recibe las últimas actualizaciones de productos y recursos de Alchemy
Al ingresar tu correo electrónico, aceptas recibir nuestras comunicaciones de marketing y actualizaciones de productos. Reconoces que Alchemy procesa la información que recibimos de acuerdo con nuestro Aviso de Privacidad. Puedes cancelar tu suscripción en cualquier momento.
Artículos relacionados

Cómo hacer benchmarks de proveedores de RPC para tu flujo de trabajo
Haz benchmarks de proveedores de RPC según latencia bajo carga, retraso de bloques y consistencia de datos, medidos por separado, con los métodos que llama tu app y desde donde corre.

Rendimiento de Solana gRPC: una metodología de benchmark pública
Cómo medimos la latencia de entrega de Solana gRPC en seis regiones, con resultados p50, p90 y p99, la configuración completa de la prueba y los comandos exactos para reproducirlos.

Le dimos a cada blockchain su propio agente de guardia
Cómo Alchemy usa más de 230 agentes, uno por cada red blockchain, para hacer triage y corregir alertas en nuestra flota de nodos. La mediana del tiempo de resolución bajó de 30 minutos a 8.