Alpenglow: la gran reescritura del consenso de Solana

Conclusiones prácticas 

• El principal beneficio de Alpenglow para Solana es una reducción de 100 veces en el tiempo hasta la finalidad de las transacciones. Según la ubicación geográfica de un validador, este tiempo bajará de 12,8 segundos a 100-150 ms. Esto permitirá que Solana compita con infraestructura Web2 más centralizada y habilitará aplicaciones en tiempo real.
• Alpenglow simplifica el consenso al eliminar varios componentes heredados de Solana, como Prueba de Historia, Tower BFT y la propagación de votos basada en gossip. En lugar de Prueba de Historia, Alpenglow introduce un tiempo de bloque fijo de 400 ms, que no equivale a tener un reloj sincronizado globalmente, para coordinar los tiempos en toda la red.
• El protocolo se estructura en torno a dos componentes fundamentales: Rotor, un protocolo mejorado de propagación de bloques que amplía y perfecciona la arquitectura Turbine existente de Solana; y Votor, un nuevo mecanismo de votación que sustituye Tower BFT, Prueba de Historia y el uso de gossip para propagar votos.
• Toda la actividad de consenso pasa fuera de la cadena. Los certificados de voto seguirán anclándose en la cadena y sustituirán las transacciones de voto por slot con un sistema ligero de certificados BLS. Este cambio elimina las comisiones de votación como las conocemos hoy, que históricamente han sido el principal costo operativo para los validadores. Esto mejora considerablemente la economía de los validadores más pequeños. El modelo económico exacto aún se está definiendo.
• Alpenglow ofrece un modelo de resiliencia “20+20”: mantiene la seguridad si los adversarios controlan hasta el 20 % del stake y mantiene la vivacidad si otro 20 % independiente del stake está sin conexión o no responde. Esto permite que el protocolo tolere condiciones de red tanto hostiles como inestables.
• Votor utiliza un sistema de votación concurrente de dos niveles para el consenso. En la ruta de finalización rápida, si un bloque recibe la aprobación de ≥80 % del stake en la primera ronda, se finaliza de inmediato con un certificado de finalización rápida. En la ruta de finalización lenta, comienza una segunda ronda en cuanto un bloque recibe la aprobación de ≥60 % del stake. Si esta ronda alcanza una aprobación de ≥60 %, el bloque se finaliza con un certificado de finalización.
• A diferencia de Turbine, que depende de una estructura de árbol de varias capas con un fanout de 200, Rotor utiliza un modelo de un solo salto en el que los nodos de retransmisión gestionan la distribución de shreds. Cada shred se transmite como un único paquete con codificación de borrado, y el diseño de Rotor es compatible de forma nativa con sistemas multicast como DoubleZero. Ten en cuenta que Rotor probablemente será un SIMD separado de Votor.
• Actualmente se espera que Alpenglow llegue a la mainnet de Solana a principios del próximo año. Puedes encontrar una implementación de referencia del protocolo en Github.

Introducción

El algoritmo de consenso Alpenglow representa la reforma más importante hasta la fecha del protocolo central de Solana. Aprovecha los avances más recientes en investigación de blockchain y rediseña desde los cimientos cómo se alcanza el consenso en toda la red.

Alpenglow es obra de la nueva división de investigación de Anza, dirigida por el profesor Roger Wattenhofer de ETH Zurich, una de las instituciones de ciencias de la computación mejor clasificadas del mundo. El profesor Wattenhofer, una autoridad destacada en sistemas distribuidos, fue coautor del artículo de 2024 Cómo detener la blockchain de Solana con una fracción épsilon del stake, que reveló posibles vulnerabilidades de vivacidad en el protocolo de consenso actual de Solana. En Anza lo acompañan sus antiguos estudiantes de doctorado, Kobi Sliwinski y Quentin Kniep.

La tarea del equipo era rediseñar el algoritmo de consenso de Solana para mejorar su rendimiento y demostrar formalmente su corrección, sin abandonar su arquitectura basada en Turbine. Alpenglow incorpora muchos de los avances más recientes en la investigación de sistemas distribuidos, especialmente para gestionar comportamientos adversos en la red.

El nombre Alpenglow deriva de la palabra alemana Alpenglühen, que significa “resplandor de los Alpes”. Se refiere a la llamativa luz que se observa en las cumbres al amanecer o al atardecer y es un guiño al origen suizo del protocolo.

¿Cuáles son los beneficios de Alpenglow?

A continuación, presentamos un resumen general de los principales beneficios que se espera que aporte Alpenglow. Analizaremos cada uno con mayor detalle en el resto del artículo.

Finalidad más rápida

El principal beneficio de Alpenglow para Solana es una reducción de 100 veces en el tiempo hasta la finalidad de las transacciones, es decir, la rapidez con la que las transacciones de los usuarios se arraigan en una red blockchain. Según la ubicación geográfica de un validador, este tiempo bajará de 12,8 segundos a 100-150 ms. Esto permitirá que Solana compita con infraestructura Web2 más centralizada y habilitará aplicaciones en tiempo real.

• Finalidad actual de Solana: 12,8 segundos 
• Confirmación optimista actual de Solana: 500-600 milisegundos
• Finalidad de Alpenglow: 150 milisegundos (valor mediano)*
• Finalidad más rápida de la competencia: 400 milisegundos (según sus propios datos)

*fluctúa según la geografía y la distribución del clúster.

Se acabaron las transacciones de voto

Con Alpenglow, toda la actividad de consenso ocurre fuera de la cadena. Esto reducirá la carga sobre la unidad de procesamiento de transacciones (TPU) y la reproducción, que ya no tendrán que procesar transacciones de voto.

Alpenglow también mejorará considerablemente la economía de los validadores más pequeños. Las comisiones de las transacciones de voto son el mayor gasto operativo de los validadores. Al eliminar estas comisiones mediante la votación fuera de la cadena, los costos de participación se reducen de forma drástica. Esto hace más viable la operación de validadores pequeños y reduce la barrera de entrada para contribuir a la seguridad de la red.

Otras ventajas incluyen una lógica de compromiso más sencilla y un crecimiento más lento del libro mayor, ya que las transacciones de voto dejan de consumir espacio de bloque y de aumentar su tamaño.

Este cambio también elimina la ambigüedad de las métricas de transacciones por segundo (TPS) de Solana. Hoy, las TPS suelen informarse de dos maneras: TPS totales, que incluyen las transacciones de voto, y TPS reales, que solo cuentan las transacciones que no son de voto.

Un protocolo más ágil

Alpenglow agiliza el proceso para alcanzar el consenso al eliminar varios componentes heredados de Solana, como Prueba de Historia, Tower BFT y el uso de gossip para propagar votos. Aunque incorpora avances de vanguardia de la investigación moderna sobre blockchain, lo hace sin introducir complejidad innecesaria.

Votor y Rotor de Alpenglow sientan las bases para futuras mejoras, como la ejecución asíncrona y los múltiples líderes concurrentes (MCL). Esto deja a Solana bien posicionada para seguir mejorando el rendimiento y evolucionando el protocolo.

¿Cuál es el mecanismo de consenso actual de Solana?

Prueba de Historia

La Prueba de Historia (PoH) no es un algoritmo de consenso. Es una herramienta que ayuda a alcanzar el consenso. La confusión probablemente surge de su nomenclatura —“Prueba de X”—, que para quienes conocen la Prueba de Trabajo y la Prueba de Participación implica que el objeto mencionado es un algoritmo de consenso. Resulta más útil considerarla un algoritmo de “preconsenso” que agiliza el consenso mediante el procesamiento eficiente de transacciones.

A grandes rasgos, PoH es un reloj descentralizado que se utiliza para demostrar el paso del tiempo en una red adversa. De manera más formal, PoH es una función criptográfica de sellado de tiempo que permite que los nodos acuerden un orden de eventos sin comunicarse entre sí. Utiliza una función hash secuencial resistente a preimágenes para crear una cadena de hashes. Los líderes aplican marcas de tiempo a los bloques mediante estos hashes para demostrar que ha transcurrido cierto tiempo. Como todos los hashes están encadenados, PoH proporciona un registro histórico que demuestra que los datos existían en un momento específico. 

Este enfoque difiere del de otras cadenas, que suelen decidir el orden de los bloques durante el consenso y añadir las marcas de tiempo después. En Solana, primero se construye un reloj verificable criptográficamente, las transacciones se transmiten conforme a ese reloj y el consenso verifica el registro de transacciones ya ordenado. El encadenamiento de hashes hace indiscutible el orden temporal. 

Tower BFT

Tower BFT opera después de que los shreds (es decir, bloques parciales) se propagan a otros validadores y la red los reproduce para determinar si ese bloque pasa a formar parte del libro mayor. Conceptualmente, es un algoritmo de consenso similar a pBFT, diseñado para aprovechar el reloj de Prueba de Historia que abarca toda la red. En lugar de necesitar una ronda de consenso síncrona para cada slot, los validadores se comprometen de antemano con slots futuros según la secuencia de Prueba de Historia que ya observaron. Esto permite una producción continua de bloques.

Los validadores emiten una transacción de voto por slot, firmada por su cuenta de voto. Los votos en una bifurcación determinada generan un bloqueo (es decir, un tiempo de espera) para esa bifurcación. Un bloqueo es un periodo definido de slots durante el cual un validador no puede votar por otra bifurcación. La idea es obligar a los validadores a comprometerse con una sola bifurcación y aumentar exponencialmente el bloqueo si quieren cambiar a otra. Cada voto incluye un contador de bloqueo que se duplica cada vez que el validador vota por un slot descendiente, lo que crea una “torre de votos” de compromisos. Por lo tanto, si un validador vota por el bloque X, no puede votar por ninguna bifurcación conflictiva durante una cantidad de slots futuros que aumenta exponencialmente (por ejemplo, 1, 2, 4, 8…). El incumplimiento del bloqueo puede demostrarse y sancionarse, aunque el slashing todavía no ha llegado a mainnet.

Solana alcanza dos niveles de finalidad con Tower BFT: confirmación optimista y finalidad determinista. 

Cuando se produce un bloque nuevo y ≥66 % del stake vota por él, el bloque se reconoce como parte de la bifurcación principal o canónica. Esto se conoce como confirmación optimista, ya que el bloque recibe un nivel de compromiso de “confirmado” en cuanto una supermayoría vota por él. La confirmación optimista se introdujo en la versión 1.3 del cliente de Solana Labs (ahora Agave) para mejorar la UX al tratar un bloque como finalizado antes de su finalización formal.

Desde el bloque génesis de Solana, nunca se ha revertido un bloque confirmado de forma optimista. Para hacerlo, al menos un tercio del stake total tendría que revelar una bifurcación conflictiva después de que el 66 % ya hubiera votado honestamente. De forma equivalente, cuando el recuento de confirmación optimista de un bloque alcanza el ~87 % del stake, un adversario necesitaría que ≥20 % de ese mismo stake firmara dos veces, un acto que se puede demostrar y sancionar con slashing. Aunque no es una finalidad absoluta en el sentido estricto de la teoría del consenso, la confirmación optimista ofrece garantías sólidas en la práctica. Estos bloques pueden considerarse finalizados para casi todos los casos de uso. Por eso, para fines prácticos, la finalidad de Solana suele citarse como 500–600 milisegundos.

La verdadera finalidad determinista exige que un bloque alcance el bloqueo máximo en la torre de votos, lo que equivale a 32 votos apilados que lo confirmen. Es decir, deben construirse otros 32 bloques sobre él para que se considere “finalizado” o arraigado en la red. Un bloque tarda ~12,8 segundos en alcanzar la finalidad determinista, dado el requisito de 32 slots y los tiempos de slot de ~0,4 segundos. La finalidad determinista se alcanza cuando la profundidad de los votos bloqueados hace imposible una reversión.

¿Cuáles son las limitaciones del mecanismo de consenso actual de Solana?

Prueba de Historia y Tower BFT ayudaron a Solana a lograr un alto rendimiento y confirmaciones optimistas rápidas. Sin embargo, este diseño tiene varias limitaciones en cuanto a costo, latencia, vivacidad y operación de validadores.

Alto costo y sobrecarga de votación

Cada validador debe votar continuamente en cada slot para contribuir al consenso. Los votos son transacciones que interactúan con el programa de votación, consumen recursos de red y pagan comisiones. 

Aproximadamente tres cuartas partes de las transacciones de Solana son transacciones de voto. Estas generan una sobrecarga considerable para la red y un costo real para los validadores en cada slot. Esta dependencia innecesaria de una votación incesante introduce una gran sobrecarga y costos que aumentan con la cantidad de slots procesados y el número de validadores del clúster. 

Latencia de finalidad

Aunque la confirmación optimista es rápida, la finalidad determinista no lo es. ~12,8 segundos es lento en comparación con protocolos de consenso más nuevos, como Mysticeti de Sui, que presume un tiempo hasta la finalidad de ~500 ms. Esto crea problemas para aplicaciones, como los exchanges, que necesitan certeza absoluta para operar. En la práctica, los usuarios confían en los bloques confirmados. Sin embargo, la red aún debe mantener largos historiales de bifurcaciones por si ocurren pequeñas reorganizaciones antes de la finalización. 

La brecha entre la confirmación optimista y la latencia determinista es una concesión: Tower BFT prioriza la vivacidad con una breve ventana de contingencia ante bifurcaciones, a costa de una finalidad más lenta. Incluso sin ataques ni errores de consenso, una finalidad de ~12,8 segundos queda muy por detrás de las cadenas con finalidad rápida y de la infraestructura Web2 existente.

Vivacidad y tolerancia a particiones de red

Tower BFT requiere que una supermayoría de validadores esté en línea y responda para confirmar y finalizar bloques nuevos. El consenso puede detenerse si más de un tercio del stake está fuera de línea o si la red está muy fragmentada. Solana aún puede producir bloques y priorizar la vivacidad, pero la red puede no alcanzar el umbral de votos necesario para confirmar esos bloques de forma optimista. En el peor de los casos, como se vio en las interrupciones recientes de Solana, los validadores atascados esperando votos o incapaces de procesar la bifurcación optimista podrían provocar una detención de la red que requiera un reinicio coordinado.

Esta es una limitación clásica del consenso BFT. Solana no ofrece una tolerancia integrada para grandes grupos de validadores que dejen de responder temporalmente. Por eso, la vivacidad de Solana se vio afectada en condiciones extremas: el protocolo no podía gestionar con fluidez una caída por debajo del umbral de supermayoría para el consenso. Tower BFT tenía que seguir produciendo bloques con menos del 60 % del stake en línea. Esto significa que esos bloques nunca podían alcanzar la confirmación optimista y podían revertirse.

Complejidad operativa de los validadores

Tower BFT exige mucho de los validadores: transacciones de voto constantes, redes robustas, actualizaciones del cliente, evitar incumplimientos y conservar el “estado de la torre”. Si un validador se reinicia o pierde el estado más reciente de su torre, corre el riesgo de emitir un voto que infrinja un compromiso de bloqueo anterior, lo que provocaría una pérdida de créditos de voto.

La dependencia del protocolo del hashing continuo de Prueba de Historia y de la propagación de votos mediante gossip obliga a los validadores a esforzarse para seguir el ritmo de los slots de ~400 ms de Solana. Los altos requisitos de hardware de Solana, aunque disminuyen con el tiempo, tampoco son triviales. Además, independientemente del stake, todos los validadores deben votar en cada slot para maximizar sus recompensas. Esto significa que, en general, los validadores más pequeños pagan las mismas comisiones y tienen la misma carga de trabajo que los grandes. Como los slots de líder se asignan proporcionalmente al stake, los validadores con más stake producen más bloques y, por lo tanto, cobran una mayor parte de las comisiones de voto que pagan otros validadores. Esto crea un flujo circular de valor en el que las comisiones de voto redistribuyen capital hacia los validadores con más stake.

Además, el mecanismo de consenso actual de Solana hace que la reproducción de bloques duplicados sea extremadamente compleja, ya que los clientes deben gestionar varios candidatos para el mismo slot. El sistema de certificados de Votor garantiza que cada slot confirme un único hash o una omisión explícita, lo que simplifica la reproducción de bloques duplicados.

Queda claro que el diseño de Tower BFT, aunque innovador, genera bastante complejidad operativa para los validadores.

¿Cómo funciona Alpenglow?

Alpenglow se basa en dos componentes principales:

• Rotor: un protocolo mejorado de propagación de bloques que amplía y optimiza la arquitectura Turbine existente.
• Votor: un nuevo protocolo de votación que sustituye Tower BFT, la propagación de votos basada en gossip y Prueba de Historia para participar en el consenso.

En las siguientes secciones, analizaremos estos componentes en detalle.

Rotor: nueva capa de distribución de datos

Rotor es un protocolo mejorado de propagación de bloques que se basa en el diseño Turbine existente de Solana, con mejoras importantes de eficiencia y simplicidad. A diferencia de Turbine, que utiliza una estructura de árbol de varias capas con un fanout de 200, Rotor utiliza un modelo de un solo salto (2δ). 

Los bloques se dividen en segmentos y cada segmento se codifica en varios shreds mediante códigos de borrado Reed-Solomon. Para garantizar la autenticidad de los shreds, el líder crea un árbol de Merkle con los hashes de los shreds y firma la raíz. Cada shred incluye su ruta en este árbol y la firma del líder.

Cada shred se envía directamente a un nodo de retransmisión. Después, los nodos de retransmisión difunden su shred a todos los nodos de la red, comenzando por el siguiente líder. Este enfoque de una sola capa reduce la latencia y simplifica la ruta de propagación. También es sorprendentemente rápido:

Tanto el líder como los nodos de retransmisión de shreds se seleccionan mediante un muestreo ponderado por stake. Esto significa que cada nodo se encarga de transmitir datos en proporción a su stake. Gracias a la codificación de borrado, los nodos solo necesitan recibir un subconjunto de los shreds para reconstruir el segmento original del bloque.

Una diferencia importante respecto de Turbine es que Rotor transmite una sola versión con codificación de borrado de cada shred. Esto elimina la necesidad de enviar por separado shreds de datos y de recuperación, como hace Turbine. Aunque la redundancia (es decir, la proporción de expansión de datos) se mantiene, este diseño elimina cualquier dinámica extraña relacionada con el reenvío de shreds de datos y garantiza la simplicidad del protocolo.

La arquitectura de Rotor también es compatible con sistemas multicast como DoubleZero, lo que ofrece flexibilidad para distribuir los bloques. Como la propagación de bloques consume un ancho de banda considerable —actualmente, los validadores grandes se acercan a 150.000 paquetes salientes por segundo—, Rotor introduce un modelo que recompensa a los nodos de retransmisión por distribuir datos. Así, alinea los incentivos para respaldar el rendimiento de la red.

El documento técnico de Alpenglow no define un mecanismo concreto para calcular o distribuir recompensas. Sin embargo, señala que las recompensas de Rotor deben tener en cuenta el ancho de banda consumido y que se espera que los nodos que retransmitan más datos reciban una mayor proporción de las recompensas.

¿Qué es Blokstor?

Blokstor es donde los nodos almacenan y gestionan los datos de bloques que reciben de Rotor. De manera más formal, Blokstor es una estructura de datos que gestiona el almacenamiento de segmentos. Cuando se recibe un shred, su contenido se añade a Blokstor si se cumplen ciertas condiciones, entre ellas:

• Blokstor aún no contiene un shred para esos índices
• Una firma válida del líder
• Una ruta válida del árbol de Merkle

Blokstor emite un evento "Block(slot(b), hash(b) hash(parent(b)))" cuando recibe el primer bloque completo b para slot(b). Blokstor también puede ejecutar procedimientos de reparación para recopilar y almacenar bloques alternativos para el mismo slot. Cuando un bloque se finaliza, Blokstor debe almacenar únicamente ese bloque en el slot correspondiente.

Votor: nuevo motor de votación y finalización

Votor es el nuevo motor de votación y finalización de Aplenglow, que sustituye Tower BFT para certificar y finalizar bloques. Se inspira en la línea de investigación de Simplex para mejorar la eficiencia y la simplicidad, y la aplica a un contexto de Prueba de Participación. 

Simplex demuestra que se puede alcanzar un acuerdo bizantino eficiente en un entorno de Prueba de Participación con líderes rotativos y mensajes extremadamente pequeños, siempre que exista un límite superior estricto para el retraso de la red. A partir de estas ideas, Votor alcanza el consenso en una o dos rondas.

A grandes rasgos, Votor garantiza que, para cada slot, exista un certificado de omisión que indique que el slot se omitió o algún bloque certificado que se construya sobre la cadena canónica de bloques certificados. Para que un bloque se certifique, debe tener un certificado válido. En lugar de inundar gossip con votos, los validadores transmiten mensajes de voto ligeros a un conjunto de pares ponderado por stake mediante una especie de malla de “envío directo”, en vez del gossip tradicional de Solana. Cuando se alcanza un cuórum, cualquier nodo puede agregar estas firmas en un certificado mediante el esquema de firmas Boneh–Lynn–Shacham (BLS). Esto elimina la necesidad de transacciones de voto por slot, ya que el encabezado del certificado agregado es lo que se ancla en la cadena.

¿Cómo funciona el mecanismo de votación de Votor?

Votor utiliza un mecanismo de votación concurrente por niveles, dividido en dos rutas:

• Finalización rápida: si el bloque propuesto recibe la aprobación de ≥80 % del stake en la primera ronda de votación, se finaliza de inmediato y se genera un certificado de finalización rápida. Esta finalización en una sola ronda es posible porque el 80 % del stake supera ampliamente el umbral de supermayoría, por lo que no se necesita una segunda ronda de votación.
• Finalización lenta: si la primera ronda recibe la aprobación de <80 % del stake, pero al menos ≥60 %, Votor inicia de inmediato una segunda ronda. Cuando esta segunda ronda alcanza la aprobación de ≥60 % del stake, se genera un certificado de finalización.

Ambas rutas se ejecutan al mismo tiempo, y la primera que alcanza su umbral finaliza el bloque. En cuanto un líder termina de incorporar el bloque principal, puede empezar a transmitir el siguiente bloque mientras los votos siguen acumulándose. Así, se produce un bloque cada ~400 ms, igual que con el consenso anterior de Solana. Este diseño garantiza que, si la primera ronda no recibe la aprobación de ≥80 % del stake, Votor recurra a la segunda ronda. También garantiza que dos bloques conflictivos no puedan alcanzar la finalidad debido a la superposición del stake.

¿Qué es la estructura de datos Pool de Votor?

El Pool es una estructura de datos que mantiene cada nodo y que funciona como un libro mayor local de la actividad de votación y la generación de certificados. Memoriza los votos recibidos para cada slot y cada nodo. Cuando se reciben suficientes votos, se genera el certificado correspondiente. Cuando se añade al Pool un certificado recién recibido o creado por el propio nodo, se transmite a todos los demás nodos. 

Aunque varios validadores pueden crear certificados casi al mismo tiempo, cualquier certificado que alcance el umbral de cuórum es funcionalmente equivalente para el consenso, independientemente de qué validadores específicos estén incluidos en el conjunto de firmas. La única excepción es el certificado de finalización, ya que pueden existir hasta tres certificaciones distintas que deban circular. Nunca hay más de cuatro certificados únicos de todos los tipos para un mismo slot, y cada certificado único se transmite una sola vez. Este enfoque evita el spam de votos y permite que cualquier nodo honesto cree y comparta el certificado en cuanto el Pool muestre un cuórum.

Conclusiones clave

Los votos se transmiten como paquetes UDP individuales a todos los validadores, que memorizan los votos recibidos para cada slot y cada nodo. La certificación y la finalidad de un bloque determinado con Votor se definen mediante las tres condiciones siguientes:

• Aprobación de ≥80 % del stake en la primera ronda de votación.
• Aprobación de ≥60 % del stake en la primera y segunda rondas de votación.
• El validador recibe un certificado válido de otro validador que declara que el bloque se ha finalizado.

Se acabó la Prueba de Historia

Como Rotor propaga los datos de bloques en un solo salto y Votor tiene una latencia máxima objetivo de ~150 ms —lo analizaremos con mayor detalle en la siguiente sección—, Solana ya no necesita un reloj descentralizado. Bastan relojes locales sencillos. Alpenglow sustituye Prueba de Historia por temporizadores locales de tiempo de espera.

¿Cómo funciona el mecanismo de tiempo de espera de Votor?

En la práctica, el sistema de tiempo de espera funciona así:

• Ventana del líder: el líder se encargará de una ventana de cuatro slots con Δblock ≈ 400ms por slot.
• Llegada de datos o tiempo de espera: en cuanto se certifica el bloque principal de un líder, cada validador activa sus tiempos de espera y preconfigura cuatro plazos, uno por slot, en t = now + Δtimeout + slotIndex * Δblock, donde Δblock ≈ 400ms. Ten en cuenta que estos temporizadores nunca se reinician y actúan como límites superiores. Si los shreds de un bloque llegan a tiempo, se vota por ese slot con un mensaje NotarVote y el tiempo de espera pendiente queda sin efecto. Sin embargo, si el tiempo vence antes de que llegue algún shred, el validador supone que el líder es deshonesto o está incumpliendo y emite un SkipVote.
• Certificación: se genera un certificado de finalización rápida o de finalización para los bloques certificados, como se describió antes. También puede generarse un certificado de omisión para los slots omitidos.

Alpenglow introduce un sistema en el que cada validador mide los tiempos de espera de manera local e independiente. Por lo tanto, Solana no necesita un único reloj basado en hashes como Prueba de Historia. Como los mensajes son un solo paquete UDP y Rotor solo requiere un salto, el límite de 400 ms es realista sin hashing. Los validadores ya no necesitarán calcular hashes continuamente, podrán votar en contra de bloques sin quedar sujetos a bloqueos y los clientes alternativos, como Firedancer, no estarán obligados a reproducir la implementación de Prueba de Historia del cliente Agave.

Omisión de slots

Los validadores también pueden omitir un slot enviando un mensaje SkipVote. Si ≥60 % del stake emite un mensaje SkipVote, se genera un certificado de omisión y el slot se omite formalmente. Los votos de omisión tienen el mismo peso de recompensa que los votos de certificación, por lo que un validador no tiene incentivos para guardar silencio cuando el líder se comporta mal. Ten en cuenta que esto puede cambiar cuando se finalice el modelo económico de Alpenglow.

Los validadores envían un SkipVote para un slot cuando determinan que no pueden finalizar un bloque para ese slot. Esto puede deberse a que se alcanzó el tiempo de espera, falta un bloque o se produjo un bloque inválido o malformado. Si el primer slot de la ventana de cuatro slots de un líder activa alguna de esas condiciones, los validadores marcan toda la ventana como defectuosa. Después, recorren los slots restantes de la ventana y emiten SkipVotes para cada slot en el que todavía no hayan votado. Así, toda la ventana de cuatro slots puede reducirse a una sola ronda de omisión. Cada voto sigue correspondiendo a un solo slot, pero como la mayoría de los validadores envían la misma ráfaga, los tres slots pendientes alcanzan el umbral del 60 % casi al mismo tiempo. Esto evita que el clúster permanezca inactivo durante otros tres slots vacíos mientras vence el tiempo de espera de un líder fuera de línea.

Evidentemente, esto deja huecos en la producción de bloques. Sin embargo, la cadencia de los slots continúa sin interrupciones gracias a estos certificados rápidos de omisión. Esto simplifica la elección de bifurcaciones y mejora la coherencia, ya que un certificado de omisión funciona como un “bloque nulo” canónico para ese slot. Todos los nodos honestos adoptan la omisión como resultado. Por lo tanto, no existe una bifurcación competidora y las omisiones no generan bifurcaciones persistentes, lo que permite mantener el ritmo normal de producción de bloques.

Recompensas de los validadores

Las recompensas de los validadores con Votor se basan en su participación en la votación y la generación de certificados. Los nodos que contribuyen al consenso emitiendo votos a favor (NotarVote) o en contra (SkipVote) de un bloque reciben la misma recompensa. Esto fomenta la participación honesta y garantiza que los nodos voten según su propio estado, en lugar de intentar predecir o seguir a la mayoría.

Por ahora, no se ha especificado una implementación exacta de las recompensas.

Benchmarks de rendimiento y resultados de simulaciones de Alpenglow

Las simulaciones de Anza muestran que Alpenglow finaliza un bloque en aproximadamente 100-150 ms, según si la ruta de finalización rápida o la alternativa (es decir, la finalización lenta) certifica el bloque. La ruta de finalización rápida busca una latencia de ~100 ms, mientras que la ruta de finalización lenta busca una latencia de ~150 ms.

Histograma de latencia

La latencia de red establece un límite inferior fundamental para la comunicación en cualquier sistema distribuido. Por ejemplo, si el líder se encuentra en Nueva York y la mayoría del stake está en Europa, la mediana de la latencia unidireccional para que un nodo envíe información a otros nodos de la red puede alcanzar unos 200 milisegundos. La latencia es menor para los nodos geográficamente cercanos (por ejemplo, los que están en el mismo centro de datos o región) y considerablemente mayor para los nodos ubicados en el Sur Global u otras zonas distantes.

• Red: Es la latencia de red necesaria para enviar 1 bit a otros nodos a través de internet
• Rotor: Cuánto más lento es Rotor en comparación con este límite inferior
• Certificación: Tiempo necesario para recibir votos certificados del 60 % del stake (también puede realizarse una ronda de votación adicional; una vez recibidos, puede comenzar la finalidad)
• Finalidad: Tiempo de finalización

En general, la finalidad de Alpenglow es 2 veces el límite inferior. Es decir, la sobrecarga del consenso multiplica por 2 el límite mínimo de la red sin procesar. Por lo tanto, si el salto unidireccional más largo entre el líder y el stake de la supermayoría es, por ejemplo, de ~70 ms (es decir, ~140 ms de RTT), la finalidad de la ruta rápida debería situarse en el rango de 120-150 ms.

El histograma de latencia de las simulaciones de Anza muestra que el 65 % del stake finaliza con una diferencia de hasta 50 ms respecto de la latencia de red sin procesar. Esto significa que la mayoría de los validadores votan casi tan pronto como llegan los datos.

Con Alpenglow, los compromisos deterministas se mantienen muy por debajo de los de cualquier L1 competidora. Esto acerca mucho más la experiencia on-chain de Solana a la de los servicios Web2 tradicionales.

Análisis de seguridad y tolerancia a fallas de Alpenglow

El consenso de Alpenglow mejora el consenso BFT tradicional, que mantiene la resiliencia frente a adversarios que controlan hasta el 33 % del stake de la red. Esto se expresa como “3f + 1”. Alpenglow reduce estos límites al 20 % del stake de la red con base en el límite de 5f + 1 presentado por Martin y Alvisi en Consenso bizantino rápido. Usa un modelo de resiliencia “20+20” en el que la seguridad se divide en dos partes:

• Fallas bizantinas ≤ 20 %: La seguridad se mantiene si menos del 20 % del stake total está bajo el control de validadores adversarios. Esta es una cantidad considerable de dinero, de miles de millones de dólares, y sería fácil de identificar y sancionar. Por lo tanto, un atacante se arriesga a perder todo su stake, lo que hace que estos ataques sean económicamente inviables.
• Fenómenos no maliciosos ≤ 20 %: La vitalidad se mantiene si, como máximo, el 20 % del stake total, sin contar el stake adversario, está desconectado, ha fallado o no participa en el consenso por otro motivo. Esto incluye interrupciones de red, configuraciones incorrectas y errores de software. Así, la red puede seguir finalizando bloques incluso si una minoría considerable de validadores no responde.

Seguridad

La seguridad está garantizada siempre que el stake adversario total sea ≤20 % y no pueda impedir una participación honesta de al menos el 60 % en una bifurcación. Estas condiciones hacen que cualquier umbral de votos que el protocolo considere final (es decir, una ronda rápida o dos rondas lentas) sea lo suficientemente alto como para impedir que se alcance un umbral conflictivo en otra bifurcación. Si los validadores adversarios intentan emitir votos contradictorios (es decir, votar por dos bifurcaciones distintas o producir dos bloques distintos en el mismo slot), los nodos honestos terminarán recibiendo sus firmas conflictivas. Esto es fácil de identificar y, en el futuro, idealmente dará lugar a infracciones sancionables como el slashing. 

Además, si un líder intentara producir un bloque no válido, los validadores honestos simplemente se negarían a votarlo. El modelo de comunicación directa para la votación de Alpenglow dificulta que un actor malicioso aísle o eclipse a un nodo honesto en términos de stake, ya que los votos de la mayoría honesta terminarán exponiéndolo. En el mejor de los casos, un líder malicioso podría forzar al consenso a usar su ruta más lenta o causar un retraso de un slot, pero no puede bloquear ni bifurcar la cadena de forma permanente.

Vitalidad

La vitalidad está garantizada bajo condiciones de sincronía parcial, siempre que se respeten los umbrales de fallas. Esto significa que, después de cierto retraso de red, los validadores honestos podrán comunicarse y reunir ≥60 % del stake en algún bloque. Si exactamente el 20 % del stake total está desconectado, la ruta rápida podría funcionar si todos los nodos honestos restantes votan. Si algo más del 20 % del stake total está desconectado, la red usará de forma constante la ruta de finalización lenta para una segunda ronda de votación. La finalidad sigue garantizada, aunque será más lenta. Por lo tanto, las fallas benignas afectan principalmente al rendimiento, no a la seguridad.

Alta resiliencia ante fallas

Alpenglow está diseñado explícitamente con una alta resiliencia ante fallas para soportar condiciones de red adversas. Es decir, Alpenglow seguirá siendo seguro y operando en escenarios con un 20 % de stake malicioso y un 20 % de stake que no responde. 

Sin embargo, esto no resuelve todas las fallas posibles. Alpenglow supone una mejora importante para Solana, pero no elimina por completo el riesgo de que la red se detenga o sufra interrupciones si no se cumplen sus supuestos. Se necesita ≥60 % del stake para producir nuevos bloques, y ≥20 % del stake actuando de forma maliciosa podría impedir el consenso o causar una falla. Aun así, dentro de los límites definidos, Alpenglow garantiza la seguridad y la vitalidad en una o dos rondas de votación.

¿Eliminar Proof of History debilita la seguridad?

Aunque es fundamental para el funcionamiento actual de Solana, eliminar Proof of History no debilita la seguridad de ninguna forma significativa. Como se mencionó antes, el límite universal de 400 ms reemplaza el reloj de hashes de Proof of History. Incluso si la red experimenta retrasos considerables, la superposición de stake de Votor (es decir, ≥80 % en una ronda y ≥60 % + ≥60 % en dos rondas) impide que los validadores honestos aprueben dos bifurcaciones distintas.

Sin embargo, sí modifica las garantías de vitalidad, ya que esta depende del mensaje de sincronía: la vitalidad se mantendrá siempre que los mensajes honestos lleguen dentro de este plazo. La difusión de datos en un solo salto de Rotor y los votos de un solo paquete hacen que la latencia se mantenga dentro del margen de 400 ms, incluso bajo presión.

En general, eliminar Proof of History acabará con la dependencia del cálculo continuo de hashes y, por lo tanto, eliminará cualquier vector de ataque basado en detenerlos. Como se mencionó antes, también modifica las garantías de vitalidad. Sin embargo, eliminar Proof of History no debilita la seguridad de ninguna forma significativa.

Puntos clave

Alpenglow intercambia una ligera reducción de la tolerancia bizantina por finalidad determinista en menos de un segundo, manejo fluido de grandes interrupciones benignas y una identificación más sencilla de validadores maliciosos. Estos puntos pueden resumirse de la siguiente manera:

• Dos bloques conflictivos no pueden finalizar a menos que ≥20 % del stake firme ambos, una acción fácil de demostrar y sancionar.
• Solana seguirá finalizando bloques siempre que ≥60 % del stake pueda comunicarse, incluso si el resto está desconectado.
• En el peor de los casos, la finalidad recurre a una segunda ronda de votación con un objetivo de latencia de ~150 ms, de modo que los ataques degraden la velocidad de la cadena antes de amenazar su seguridad.
• El costo de superar el límite bizantino del 20 % es prohibitivo, mientras que las infracciones menores se pueden detectar y sancionar tanto social como económicamente una vez que el slashing se active en mainnet.

¿Qué impacto tiene Alpenglow en los validadores?

Los costos de votación son la mayor barrera de entrada para operar un validador de Solana. No se requiere una cantidad mínima estricta de SOL para operar uno. Sin embargo, enviar transacciones de voto en cada slot, algo necesario para participar en el consenso, puede costar hasta ~1 SOL al día.

Alpenglow busca reemplazar las transacciones de voto por slot con un sistema compacto de certificados que elimina de forma efectiva las comisiones de votación tal como las conocemos hoy. Cada validador transmitiría mensajes de voto ligeros a todos los demás nodos. Cualquier nodo puede agregar esas firmas en un certificado mediante el esquema de firmas BLS una vez alcanzado el cuórum. Como estos votos ahora están agregados mediante BLS, solo el encabezado del certificado se registra on-chain. En la práctica, esto eliminaría el costo diario de ~1 SOL por validador. 

Como se mencionó antes, con Alpenglow cada propuesta de bloque se evalúa mediante dos rutas de votación simultáneas:

• Finalización rápida (una ronda)
  • Se activa cuando el recuento de votos certificados para un bloque determinado en la primera ronda alcanza ≥80 % del stake
  • Produce un certificado de finalización rápida 
  • Tiene un objetivo de latencia de ~100 ms
• Finalización lenta (dos rondas)
  • Se activa cuando el recuento de votos certificados para un bloque determinado en la primera ronda alcanza ≥60 % del stake
  • Produce un certificado de finalización cuando el recuento de votos certificados de la segunda ronda alcanza ≥60 % del stake
  • Tiene un objetivo de latencia de ~150 ms

Votor ejecuta ambas rutas simultáneamente. Esto significa que ambos recuentos se actualizan desde el mismo stream de votos de la primera ronda, de modo que el primer certificado que supere su umbral finalice el bloque. El conjunto de stake superpuesto (es decir, ≥60 %) garantiza que dos bloques conflictivos nunca puedan alcanzar la finalidad.

Las consecuencias operativas de este nuevo diseño son positivas para los validadores:

Menores costos operativos 

Eliminar las comisiones de votación reduce considerablemente la barrera de entrada para los posibles validadores. A su vez, estas comisiones hacían que los validadores más pequeños dependieran más de las recompensas por inflación durante los mercados bajistas. Su eliminación podría justificar futuras conversaciones sobre la inflación de Solana, dada la polémica votación de SIMD-228. Según la implementación de Alpenglow que se debate actualmente, esta reducción disminuiría la cantidad mínima de SOL necesaria para ser rentable de ~4850 SOL (~800 mil USD) a ~450 SOL (~75 mil USD), según los cálculos realizados con la calculadora de rentabilidad de validadores de Cogent Crypto.

Gestión de claves simplificada 

Los validadores de Solana ya no necesitan firmar votos por slot. Esto permite almacenar la clave de identidad del validador en un módulo de seguridad de hardware (HSM) sin riesgos para el rendimiento, lo que reduce de forma efectiva el riesgo de usar una hot wallet.

Menor carga de red durante el slot del líder

Agregar un certificado por bloque reemplaza miles de transacciones de voto individuales por epoch, lo que reduce la carga de red durante el slot del líder. 

Sin cálculos de bloqueo

Se elimina la tabla de bloqueos exponenciales al estilo Tower de Solana. Ahora, los validadores solo necesitan mantener en memoria la cadena de certificados más reciente, lo que acorta los tiempos de reinicio.

¿Qué impacto tiene Alpenglow en los proveedores de RPC?

Las consecuencias operativas de este nuevo diseño son, en su mayoría, positivas para los proveedores de RPC, aunque algunas plantean posibles problemas de escalabilidad:

Niveles de compromiso simplificados 

Este nuevo nivel de finalidad eliminaría la diferencia histórica entre los niveles de compromiso confirmado (es decir, optimista) y finalizado (es decir, enraizado). Por ejemplo, cualquier lógica de UX que espere dos niveles de confirmación (como mostrar un indicador de carga hasta la finalización) puede reducirse a una sola comprobación de certificado.

Menor tamaño del ledger

Dada la demanda actual de Solana, el crecimiento del ledger se reduciría aproximadamente en tres cuartas partes debido a la ausencia de transacciones de voto. Esto también reduciría el tamaño de las snapshots y los archivos. Sin embargo, dados los objetivos proyectados de aumento de las CU máximas por bloque, aún está por verse cómo funcionará esto en la práctica.

Cuello de botella en la distribución de WebSocket

Con Alpenglow, ya no tiene sentido consultar transacciones periódicamente, dado que la finalidad llega en ~100-150 ms y se codifica en un único certificado. Tendría más sentido obtener información sobre la finalidad mediante un canal push que permanezca abierto durante toda la vida de la app, el navegador o el bot, y que transmita cada nuevo certificado a todos los clientes suscritos. Los puntos problemáticos pasan de millones de pequeñas consultas HTTP a cientos de miles de sockets en tiempo real.

Actualización de la caché en tiempo real

Cualquier caché que retenga datos de cuentas durante más de un cuarto de segundo podría mostrar datos obsoletos, ya que los certificados confirman un bloque en 100-150 ms. Las cachés perimetrales, las CDN y los proxies de capa 7 necesitarán TTL extremadamente cortos o hooks de purga que reconozcan certificados.

¿Cuál es el cronograma de desarrollo de Alpenglow?

Alpenglow se presentó oficialmente en la conferencia New York Accelerate a finales de mayo. La siguiente fase implica publicar un documento formal de mejora de Solana (SIMD), que abrirá la propuesta a los comentarios de la comunidad a través de GitHub, los foros de gobernanza de Solana y el Discord de Solana Tech.

Después del periodo de revisión de la comunidad, la propuesta pasará a una votación de gobernanza on-chain por parte de la comunidad de validadores. En paralelo, el nuevo diseño se someterá a pruebas exhaustivas para garantizar su rendimiento y seguridad.

Si todas las etapas avanzan según lo previsto, se espera que el despliegue en la mainnet de Solana ocurra a principios del próximo año.

Riesgos y preguntas abiertas de Alpenglow

Un nuevo algoritmo de consenso

Migrar a un nuevo protocolo de consenso es una tarea importante, pero existen precedentes relevantes. The Merge de Ethereum de 2022 demostró que una gran red activa puede cambiar con éxito su mecanismo de consenso principal, al pasar de Proof-of-Work a Proof-of-Stake sin interrumpir sus operaciones. Es decir, aún existen numerosos riesgos, pero no es un territorio completamente desconocido.

Esta transición también requeriría guías de migración para evitar que las apps, los SDK, las wallets y los bots dejen de funcionar silenciosamente cuando Alpenglow combine los niveles de compromiso confirmado y finalizado en una única comprobación de certificación. Cualquier código que consulte explícitamente dos niveles de compromiso o use de forma predeterminada el nivel confirmado dejará de funcionar. Antes de que Alpenglow se active, el ecosistema deberá coordinar sus esfuerzos en torno a la documentación, las advertencias de lint, los métodos RPC y la arquitectura general del código. 

Gobernanza

El riesgo de gobernanza es otro factor que debe considerarse. La reciente votación de SIMD-228 demuestra que Solana funciona como una red verdaderamente descentralizada, donde no está garantizada la aprobación de propuestas, incluso de aquellas respaldadas por desarrolladores principales y miembros destacados de la comunidad. Sin embargo, los próximos cambios de Alpenglow, en particular la reducción de los costos de votación, son ampliamente favorables para los validadores, especialmente para los operadores más pequeños. Por eso, creemos que la probabilidad de resistencia en la gobernanza es relativamente baja.

Recompensas

El whitepaper de Alpenglow y los materiales relacionados publicados hasta ahora no especifican los mecanismos exactos para recompensar la actividad de votación de los validadores ni compensar a los relays de Rotor por el uso de ancho de banda. El whitepaper también afirma claramente que emitir votos contradictorios es sancionable, pero no especifica quién aplica la sanción, cuál es su magnitud ni si se impone automáticamente o mediante la gobernanza. Estas omisiones dejan sin definir aspectos clave de la economía de los validadores y podrían convertirse en puntos de debate polémico dentro del ecosistema.

MEV

Alpenglow también reestructurará por completo el panorama actual de MEV en Solana. La latencia sigue siendo un factor determinante para MEV, ya que algunas estrategias rentables dependen de replicar el tráfico de TPU o de cancelar mediante spam y reemplazar transacciones en un orden determinado antes de que se confirmen de forma optimista. Todo esto ocurre dentro de la ventana actual de ~500-600 ms, que Alpenglow busca reducir a ~150 ms. A primera vista, los líderes, especialmente los validadores que ya alojan infraestructura personalizada de construcción de bloques, podrían capturar una mayor proporción de MEV. Mientras tanto, los arbitrajistas de latencia independientes podrían perder su ventaja, a menos que sigan desarrollando sistemas de trading aún más rápidos y granulares.

Varios líderes simultáneos

El diseño de Alpenglow es mucho más flexible para adoptar un marco de varios líderes, conocido como Multiple Concurrent Leaders (MCL), que la arquitectura de consenso actual de Solana. Como señaló Anatoly Yakovenko, un primer prototipo de MCL podría consistir en iniciar dos instancias de Alpenglow que compartan el mismo conjunto de Rotor y publiquen todos los shreds simultáneamente. Rotor distribuiría los streams paralelos y Votor certificaría cada vía. Sin embargo, empiezan a surgir varias preguntas sobre la capa de ejecución. En concreto:

• ¿Cómo deben dividirse los conjuntos de escritura para que los bloques de dos líderes nunca bloqueen la misma cuenta o, si lo hacen, para que la resolución del conflicto sea determinista y económica?
• ¿Cómo se combinan los certificados de cada vía en una única raíz de estado canónica sin duplicar el costo de reproducción?
• ¿Qué lógica de mercado de comisiones se aplica cuando las vías compiten por activos?
• ¿Qué tipos de estrategias de MEV entre vías permitiría esto?
• ¿Podría un único validador con mucho stake dominar slots simultáneos sin límites por vía? 

Aunque el diseño de Alpenglow ayuda a convertir MCL en un elemento realista del roadmap al eliminar obstáculos a nivel de consenso, sigue siendo una iniciativa prometedora para el futuro hasta que se respondan estas preguntas abiertas.

Conclusión

Este informe analizó los componentes principales de Alpenglow y examinó cómo transforman el modelo de consenso de Solana. También analizamos las mejoras técnicas, los cambios en la economía de los validadores, los efectos a nivel de red y los beneficios para el rendimiento, la simplicidad y la escalabilidad.

El whitepaper de Alpenglow marca un punto de inflexión para Solana, no solo en el diseño del protocolo, sino también en su filosofía de desarrollo. Por primera vez, Solana publicó pruebas formales de corrección para su algoritmo de consenso. Esto señala un cambio desde su enfoque tradicionalmente empírico e impulsado por la ingeniería hacia una base más rigurosa y respaldada por la investigación. Esta evolución refleja un ecosistema que está madurando y continúa priorizando el rendimiento, ahora con la disciplina adicional de la verificación formal.

La obsolescencia de Proof-of-History (PoH) representa un cambio igualmente simbólico en la identidad de la red. Aunque la importancia práctica de PoH se ha exagerado a menudo, durante mucho tiempo ha sido la innovación distintiva de Solana, ha ocupado un lugar destacado en introducciones técnicas y se ha convertido en sinónimo de la marca. Su eliminación marca el final de una era y el comienzo de otra. Solana está madurando.

Recursos adicionales

• Diapositivas de la presentación de Alpenglow en Accelerate - Roger Wattenhofer
• Alpenglow: un nuevo consenso para Solana - Blog de Anza
• Implementación de referencia de Alpenglow - GitHub
• Whitepaper de Alpenglow - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Consenso en Solana - Blog de Helius
• Escalar o morir en Accelerate 2025: presentación de Alpenglow, el nuevo consenso de Solana - Video de YouTube