---
title: "Solana Alpenglow: la mayor renovación de consenso en la historia de Solana"
description: "Alpenglow reemplaza tanto Proof of History como Tower BFT con una nueva arquitectura de consenso que reduce la finalidad de 12.8 segundos a 150 milisegundos y elimina el 75% del overhead de block space de Solana."
---

# Solana Alpenglow: la mayor renovación de consenso en la historia de Solana

<ImageBlock
  src="https://media.alchemy.com/solana-alpenglow-blog-header.png"
  alt="Explicación de la actualización de consenso Alpenglow de Solana"
  width={1920}
  height={900}
  priority
/>

Las transacciones de Solana tardan 12.8 segundos en finalizar. Después de Alpenglow, eso baja a 150 milisegundos.

Pero la velocidad es solo la superficie. Alpenglow elimina Proof of History y Tower BFT, los dos sistemas que han definido el consenso de Solana desde su lanzamiento, y los reemplaza con una arquitectura más simple que también elimina las transacciones de voto on-chain. Esos votos actualmente consumen ~75% del espacio de bloque de Solana. Pasó la gobernanza con 98.27% de aprobación, está en pruebas de clúster privado ahora, y se espera que llegue a mainnet a fines de 2026.

## ¿Qué es Alpenglow?

Alpenglow es un reemplazo completo de la capa de consenso de Solana. La nueva arquitectura finaliza transacciones en 100-150 milisegundos en lugar de 12.8 segundos, y al mover el voto de los validadores fuera de la cadena, libera aproximadamente tres cuartas partes del espacio de bloque para transacciones reales de usuarios.

Formalizado como [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md), el upgrade se construye alrededor de dos protocolos nuevos:

- Votor: un nuevo sistema de votación y finalización que reemplaza a Tower BFT
- Rotor: un nuevo sistema de propagación de bloques que reemplaza a Turbine

Piénsalo así: Tower BFT es como un proceso de aprobación de 32 pasos donde cada bloque sube por capas de confirmación. Alpenglow reduce eso a una o dos rondas rápidas. El upgrade también retira Proof of History, el reloj criptográfico original de Solana. En lugar de ejecutar una cadena de hash continua, los validadores usan un tiempo de bloque fijo de 400ms con timeouts locales.

## ¿Quién lo está construyendo?

La investigación vino del laboratorio de sistemas distribuidos del profesor Wattenhofer en ETH Zurich. [Anza](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana), el equipo central detrás del [cliente validador Agave](/blog/preparing-for-the-agave-2-0-upgrade), lidera la implementación. El equipo de Firedancer de Jump Crypto está colaborando en la compatibilidad multi-cliente.

## ¿En qué punto está ahora?

- **Mayo de 2025**: Presentado en Solana Accelerate en Nueva York
- **Septiembre de 2025**: Voto de gobernanza aprobado, 98.27% a favor, con 52% del stake total participando
- **Principios de 2026**: Disponible en la rama master de Agave para pruebas de clúster privado
- **Q3 2026**: Lanzamiento completo enfocado en Agave 4.1
- **Fines de 2026**: Se espera la activación en mainnet tras pruebas de la comunidad y auditorías de seguridad (aún no está en clústeres de producción a abril de 2026)

## ¿Cómo funciona Alpenglow?

Tres cambios.

### 1. Votor: cómo se finalizan los bloques

El sistema actual (Tower BFT) requiere 32 confirmaciones incrementales. Cada capa agrega un período de lockout.

Votor reemplaza esto con una o dos rondas de votación:

- **Ruta rápida (~100ms)**: Si más del 80% de los validadores aprueban en la primera ronda, el bloque es final. Listo.
- **Ruta lenta (~150ms)**: Si entre 60-80% aprueba en la ronda uno, se ejecuta una segunda ronda. Si más del 60% aprueba de nuevo, es final.

Ambas rutas corren simultáneamente. La que termine primero gana.

Los validadores envían votos como mensajes UDP livianos directamente entre sí, no como transacciones on-chain. Votor agrupa estos votos usando [agregación de firmas BLS](https://en.wikipedia.org/wiki/BLS_digital_signature): miles de firmas individuales comprimidas en una sola prueba compacta. Solo el certificado agregado (~1,000 bytes) llega a la cadena, reemplazando los ~500KB de datos de voto que actualmente se registran por slot.

Esto es un cambio grande. Ahora mismo, ~75% de todas las transacciones de Solana son votos de validadores. Alpenglow los elimina por completo.

### 2. Rotor: cómo se propagan los datos de bloque

*Nota: Rotor es parte de la visión más amplia de Alpenglow, pero se lanza como un SIMD separado de los cambios centrales de consenso de Votor.*

Actualmente, Solana usa Turbine, un árbol de retransmisión multicapa con un fanout de 200 nodos. Los datos de bloque saltan por múltiples capas. Piénsalo como el juego del teléfono descompuesto.

Rotor reemplaza esto con una transmisión de un solo salto: el productor de bloques envía los datos a un conjunto pequeño de nodos de retransmisión, y esos nodos lo distribuyen a todos a la vez. De un árbol de teléfono a una transmisión grupal.

Los números del [whitepaper de Alpenglow](https://www.anza.xyz/alpenglow-1-1): transmitir 1,500 shreds toma 18ms con un ancho de banda de 1 Gb/s. Alcanzar el 80% del stake total necesita solo ~150 nodos en aproximadamente 2ms.

### 3. Se acabó Proof of History

Alpenglow retira el reloj criptográfico de Solana. En su lugar, los validadores usan un tiempo de bloque fijo de 400ms y relojes locales con timeouts:

- El bloque llega antes del timeout: se aprueba (NotarVote)
- El timeout expira sin bloque: se salta (SkipVote)

El protocolo tolera el desfase de reloj de forma proporcional: un 5% de desfase solo necesita una extensión de timeout del 5%.

## ¿Cómo cambia el modelo de seguridad?

Alpenglow introduce un marco de tolerancia a fallas "20+20":

<EmbeddedTable
  table={{
    columns: [
      { key: "scenario", width: 200, title: "Scenario", dataType: "object" },
      { key: "traditional", width: 200, title: "Traditional BFT", dataType: "object" },
      { key: "alpenglow", width: 200, title: "Alpenglow", dataType: "object" },
    ],
    data: [
      {
        scenario: { title: "Malicious validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        scenario: { title: "Offline validators", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 20%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        scenario: { title: "Both at once", tooltip: "", icon: "" },
        traditional: { title: "Up to 33%", tooltip: "", icon: "" },
        alpenglow: { title: "Up to 40%", tooltip: "", icon: "" },
        id: 2,
      },
    ],
  }}
/>

¿Por qué funciona esto? Para la seguridad: forks en conflicto no pueden alcanzar quórum los dos porque 80% + 60% = 140% > 100%. Para la vivacidad (liveness): la red sigue finalizando a través de la ruta lenta incluso si el 20% del stake queda offline.

El trade-off: la tolerancia Bizantina pura baja de 33% a 20%. Pero en la práctica, las fallas del mundo real son mixtas. Algunos nodos son maliciosos, otros simplemente están offline. La tolerancia combinada del 40% maneja ese escenario mejor que el 33% del BFT tradicional.

## ¿Cuáles son las ganancias de rendimiento?

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 220, title: "Metric", dataType: "object" },
      { key: "current", width: 200, title: "Current Solana", dataType: "object" },
      { key: "alpenglow", width: 200, title: "With Alpenglow", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "Transaction finality", tooltip: "", icon: "" },
        current: { title: "~12.8 seconds", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "Optimistic confirmation", tooltip: "", icon: "" },
        current: { title: "500–600ms", tooltip: "", icon: "" },
        alpenglow: { title: "100–150ms (deterministic)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "Max theoretical TPS", tooltip: "", icon: "" },
        current: { title: "~65,000", tooltip: "", icon: "" },
        alpenglow: { title: "~107,000", tooltip: "", icon: "" },
        id: 2,
      },
      {
        metric: { title: "Vote transactions (% of block space)", tooltip: "", icon: "" },
        current: { title: "~75%", tooltip: "", icon: "" },
        alpenglow: { title: "0%", tooltip: "", icon: "" },
        id: 3,
      },
      {
        metric: { title: "Validator vote cost", tooltip: "", icon: "" },
        current: { title: "~1 SOL/day", tooltip: "", icon: "" },
        alpenglow: { title: "Eliminated", tooltip: "", icon: "" },
        id: 4,
      },
      {
        metric: { title: "Min. profitable stake", tooltip: "", icon: "" },
        current: { title: "~4,850 SOL", tooltip: "", icon: "" },
        alpenglow: { title: "~450 SOL", tooltip: "", icon: "" },
        id: 5,
      },
      {
        metric: { title: "On-chain vote data per slot", tooltip: "", icon: "" },
        current: { title: "~500KB", tooltip: "", icon: "" },
        alpenglow: { title: "~1,000 bytes", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

Los resultados de simulación muestran que el 65% del stake finaliza dentro de los 50ms de latencia de red bruta. Con un salto de red de ida más largo de ~70ms, la finalidad de la ruta rápida queda alrededor de 120-150ms.

## ¿Qué cambia para los validadores?

La economía cambia:

- **Desaparecen las comisiones de voto.** Actualmente ~1 SOL/día por validador. Alpenglow mueve todo el voto fuera de la cadena.
- **Nuevo costo: Validator Admission Ticket (VAT).** ~0.8 SOL/día, quemado en su totalidad para reducir la inflación.
- **Límite de validadores: 2,000** (se selecciona el stake más alto).
- **La barrera de entrada baja ~90%.** El stake mínimo rentable pasa de ~4,850 SOL a ~450 SOL.
- **Los costos operativos bajan 20-50%** en general.
- **Soporte para HSM.** Las claves de identidad pueden vivir en módulos de seguridad de hardware ya que dejan de firmar transacciones de voto de alta frecuencia.

## ¿Qué cambia para desarrolladores y usuarios?

**Para los desarrolladores**, el cambio más grande no es el número de velocidad. Es que la finalidad se vuelve una sola cosa.

Hoy, Solana tiene tres niveles de commitment: `processed`, `confirmed` (~500ms, probabilístico), y `finalized` (~12.8s, determinístico). Cada desarrollador toma una decisión por funcionalidad: aceptar el riesgo de rollback y mostrarle al usuario un resultado rápido, o esperar 12.8 segundos y tener certeza. El acreditado de depósitos en exchanges, las confirmaciones de bridges, y los motores de liquidación esperan todos a `finalized` porque incluso un riesgo pequeño de rollback es inaceptable. Todo lo demás usa `confirmed` y espera lo mejor.

Alpenglow reduce esto a un solo nivel. 100-150ms, finalidad determinística en cada transacción. Sin trade-offs entre niveles de commitment. Sin lógica de reintento para transacciones desaparecidas. Una sola verificación, listo.

Eso es lo que hace viables los patrones nuevos: los order books onchain pueden ofrecer spreads más ajustados porque los market makers saben que el estado de su cotización es final en 150ms. Los exchanges de perpetuos podrían ver menores costos de latencia en las subastas JIT. Los bridges cross-chain eliminan el cuello de botella de finalidad del lado de Solana. Y el acreditado de depósitos en exchanges pasa de una espera de 13 segundos a instantáneo.

**Para los usuarios**, las transacciones se confirman lo suficientemente rápido como para sentirse instantáneas. El cambio más grande es la capacidad: eliminar las transacciones de voto libera 75% del espacio de bloque, lo que significa comisiones más bajas y menos congestión durante períodos de alto tráfico.

**Para [instituciones financieras que construyen sobre Solana](/overviews/complete-guide-to-solana-for-financial-institutions)**, la finalidad determinística en menos de un segundo cierra la brecha con los rieles de pago tradicionales. La liquidación de stablecoins, las operaciones de tesorería tokenizadas, y las transferencias transfronterizas ya no necesitan un buffer de 13 segundos.

## ¿Qué falta por llegar?

Alpenglow también le facilita la vida a [Firedancer](https://jumpcrypto.com/firedancer/), el cliente validador independiente de Jump Crypto escrito en C/C++. Firedancer mejora el rendimiento de un solo nodo; Alpenglow rediseña cómo los nodos alcanzan consenso. El protocolo más simple significa menos complejidad de consenso que reimplementar en una segunda base de código — una ventaja práctica para la diversidad multi-cliente.

[SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md) cubre solo los cambios de consenso de Votor. Tres componentes del [whitepaper de Alpenglow](https://www.anza.xyz/alpenglow-1-1) quedan diferidos a propuestas futuras:

- Rotor (propagación de bloques), SIMD separado
- Smart Sampling (optimización de ancho de banda)
- Ejecución Lazy/Asíncrona

El camino hacia mainnet: lanzamiento de Agave 4.1 en Q3 2026, pruebas de la comunidad y auditorías de seguridad durante el Q4, activación en mainnet a fines de 2026.

## Construye en Solana con Alchemy

Alpenglow hace a Solana más rápido, pero todavía necesitas infraestructura confiable para construir sobre ella.

[La plataforma de Solana de Alchemy](https://www.alchemy.com/solana) te da [acceso a datos archivales hasta 20 veces más rápido](/blog/how-alchemy-built-the-fastest-archival-methods-on-solana) que otros proveedores, streaming gRPC a la mitad del precio con recuperación de reconexión de 6,000 bloques, y llamadas a métodos pesados 10 veces más rápidas, como `getProgramAccounts`.

- **Smart WebSockets** que eliminan conexiones caídas, además de conexiones con stake para un enrutamiento confiable de transacciones
- **Soporte de transacciones gasless** para reducir la fricción de los usuarios finales
- **99.99% de confiabilidad** con despliegue multi-región y 3-5 capas de failover autónomo

[Solflare](https://www.alchemy.com/dapps/solflare), Robinhood, OpenSea y Circle ya corren sobre [la infraestructura de Solana de Alchemy](/blog/solana-infrastructure). Precios pay-as-you-go, sin compromisos de largo plazo.

[Empieza con un endpoint RPC gratuito de Solana →](https://www.alchemy.com/solana)

## Preguntas frecuentes

### ¿Qué es Solana Alpenglow?

Alpenglow es un reemplazo completo de la capa de consenso de Solana que reduce la finalidad de transacciones de 12.8 segundos a 100-150 milisegundos y elimina las transacciones de voto on-chain, liberando aproximadamente el 75% del espacio de bloque para transacciones de usuarios.

### ¿Qué reemplaza Alpenglow en la arquitectura actual de Solana?

Alpenglow elimina Proof of History, Tower BFT y las transacciones de voto on-chain, reemplazándolos con Votor (un nuevo sistema de votación), Rotor (un nuevo sistema de propagación de bloques) y un tiempo de bloque fijo de 400ms con timeouts locales.

### ¿Cuándo se lanzará Alpenglow en mainnet?

Se espera que Alpenglow se active en mainnet a fines de 2026, después del lanzamiento de Agave 4.1 en Q3 2026 y las pruebas de la comunidad y auditorías de seguridad subsecuentes durante el Q4 de 2026.

### ¿Cómo logra Alpenglow una finalidad más rápida?

Votor reduce el proceso actual de confirmación de 32 pasos a una o dos rondas de votación: la ruta rápida finaliza en ~100ms con más del 80% de aprobación de validadores, mientras que la ruta lenta finaliza en ~150ms con más del 60% de aprobación en dos rondas.

### ¿Cómo impacta Alpenglow los costos de los validadores?

Alpenglow elimina el costo de ~1 SOL/día por transacciones de voto on-chain y reduce el stake mínimo rentable de ~4,850 SOL a ~450 SOL, aunque los validadores pagarán una nueva comisión de Validator Admission Ticket de ~0.8 SOL/día que se quema.

### ¿Cuáles son los trade-offs de seguridad en Alpenglow?

Alpenglow tolera hasta un 20% de validadores maliciosos y un 20% de nodos offline (o 40% combinado), en comparación con el límite del 33% del BFT tradicional, usando un quórum del 80% para la finalidad de ruta rápida y del 60% para la finalidad de ruta lenta para prevenir forks en conflicto.

### ¿Cómo cambia Alpenglow los niveles de commitment para los desarrolladores?

Alpenglow reduce los tres niveles de commitment de Solana (processed, confirmed, finalized) a una sola finalidad determinística en 100-150ms, eliminando la necesidad de elegir entre velocidad y riesgo de rollback.

### ¿Cuál es el estado actual del desarrollo de Alpenglow?

Alpenglow pasó la gobernanza con 98.27% de aprobación en septiembre de 2025, está disponible en la rama master de Agave para pruebas de clúster privado desde principios de 2026, y aún no está en clústeres de producción a abril de 2026.

## Recursos clave

- [Whitepaper de Alpenglow v1.0](https://www.anza.xyz/alpenglow-1-0) | [v1.1](https://www.anza.xyz/alpenglow-1-1)
- [Propuesta SIMD-0326 (GitHub)](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md)
- [Blog de Anza: Alpenglow, un nuevo consenso para Solana](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana)