El concurso de seguridad de 50,000 SOL de Solana no cubrió un ataque al reloj divulgado meses antes

En USENIX Security, una de las principales conferencias con revisión por pares del área, investigadores presentaron el 12 de agosto un ataque al reloj de Proof-of-History de Solana que habían divulgado de forma privada a los desarrolladores de Solana en diciembre de 2025. Anza —la firma que desarrolla el cliente de validación Agave— cerró su concurso Alpenglow de 50,000 $SOL siete días después, y sus reglas parecen haber situado el ataque fuera del alcance.

El documento describe un método válido según el protocolo mediante el cual un líder programado puede ampliar su ventana efectiva de bloques y suprimir las propuestas de los líderes honestos en una variante asistida por bifurcaciones. La técnica depende de Proof-of-History y TowerBFT —el reloj lógico de Solana y el mecanismo de consenso construido sobre él—, los componentes que Alpenglow está destinado a reemplazar pero que aún no había desplazado en la mainnet en Agave 4.2.

El resultado plantea dos cuestiones separadas: si el ataque pertenecía al alcance del concurso y si la propia transición del protocolo deja espacio para riesgos.

Las reglas del concurso excluían el comportamiento alcanzable solo cuando Alpenglow estaba inactivo. Los documentos públicos de diseño indican que la ruta heredada exacta descrita en el documento debería volverse inalcanzable tras la activación, pero Anza y la Solana Foundation no han publicado una adjudicación específica sobre el documento ni un análisis a nivel de implementación.

Cómo un líder puede estirar el reloj de Solana

Proof-of-History, o PoH, utiliza una cadena de hashes secuencial para dotar a Solana de un reloj lógico. Los validadores siguen avanzando su visión local de ese reloj cuando un líder programado no publica un bloque de inmediato.

Según los investigadores, un líder programado malicioso puede retener un bloque válido según el protocolo mientras los validadores honestos avanzan, y liberar después ese bloque anclado a un punto anterior del tiempo lógico. Si los validadores aceptan esa rama, alinean su estado de PoH al punto anterior del bloque. Los investigadores denominan a este reinicio «reanclaje» (re-anchoring).

Time Inflation, o TI, repite esa maniobra para darle al atacante más tiempo físico para elegir transacciones mientras el tiempo lógico avanza más lentamente. Fork-Assisted Time Inflation, o FTI, combina el reinicio con la elección de bifurcación de TowerBFT.

Bajo las condiciones modeladas, la rama del atacante puede dejar huérfano el bloque de un líder honesto, y la regla de un bloque por slot de Solana impide que ese líder simplemente produzca otro bloque para el mismo slot.

El modelo de amenaza otorga al adversario menos del 33% del stake —por debajo del límite de fallas de un tercio que los protocolos tolerantes a fallas bizantinas están diseñados convencionalmente para tolerar— y ningún control sobre el planificador de la red. Asume un cronograma de líderes conocido y ponderado por stake, sincronía parcial y la entrega de un bloque honesto a los validadores honestos dentro de un slot nominal después de que la red se estabiliza.

Para un atacante que controla ℓ rondas consecutivas de líderes de cuatro slots, los experimentos utilizan un retraso máximo conservador e independiente del stake de 4ℓ + 1 unidades de slot. Una ronda se corresponde con un parámetro de retraso de cinco unidades de slot.

El documento señala que un mayor stake podría ampliar una ventana de liberación sin riesgo, pero no presenta ese escenario experimental como un resultado universal de la mainnet.

Los investigadores implementaron TI y FTI en una testnet local de Solana y usaron simulaciones para configuraciones de atacantes de épocas completas. No identificaron una versión específica de Agave afectada, por lo que el documento no establece que todas las versiones actuales del cliente estén expuestas de la misma manera.

Qué muestran los datos públicos

Los investigadores también estudiaron datos públicos de la mainnet y seleccionaron dos validadores que se situaban repetidamente en la cola de la distribución de intervalos entre marcas de tiempo. Esos validadores combinaban intervalos más largos con una mayor inclusión de transacciones y bajas tasas de omisión.

El patrón es consistente con el canal de incentivos de TI porque una ventana física más larga crea más oportunidades para seleccionar transacciones con comisiones —una ventaja en el ordenamiento de transacciones del tipo que la industria en general analiza bajo la etiqueta de valor extraíble máximo, o MEV.

El documento indica que las diferencias de hardware, el procesamiento por lotes local u otras decisiones de configuración, las condiciones de la red y las interrupciones operativas también podrían generar patrones de temporización similares. También encontró que no había una tasa de omisión río abajo significativamente elevada y señaló que el patrón observado era inconsistente con una atribución a FTI.

La investigación establece un problema de equidad y latencia válido según el protocolo mediante pruebas controladas y mediciones indicativas. No muestra una explotación en vivo, un robo, una manipulación demostrada de la mainnet ni una ruptura de la seguridad del consenso.

Por qué el concurso Alpenglow de Solana probablemente lo excluyó

Las presentaciones al concurso Alpenglow cerraron el 19 de agosto a las 16:00 UTC. Las reglas cubrían la superficie de consenso con la función Alpenglow activa, el código de integración cuyo comportamiento cambió porque Alpenglow estaba activo y la ruta de migración de TowerBFT a Alpenglow.

El comportamiento alcanzable solo cuando Alpenglow estaba inactivo pertenecía al dominio de TowerBFT y quedaba fuera del concurso. Los problemas previamente públicos también eran inelegibles.

La brecha es conocida en los concursos de seguridad con plazo definido: las reglas de alcance, no la gravedad, deciden qué se recompensa. El concurso cubría fallas causadas por Alpenglow o su migración, mientras que el documento se dirige al modelo heredado de tiempo y elección de bifurcación que Alpenglow está diseñado para reemplazar.

Qué cambia Alpenglow

La descripción general de Alpenglow de Anza indica que la actualización reemplaza TowerBFT y PoH como componentes centrales del consenso por Votor. La propuesta oficial SIMD-0326 —un Documento de Mejora de Solana dentro del proceso formal de cambios de la red— describe tiempos de espera locales que cumplen una función de temporización sin tiempo sincronizado y califica el cambio como incompatible con versiones anteriores.

Esos diseños eliminan los requisitos previos de reanclaje de PoH y de elección de bifurcación de TowerBFT que utilizan TI y FTI. El registro público no incluye un análisis de Anza o de la Solana Foundation que mapee cada paso del ataque al código de Alpenglow en producción o que descarte un problema análogo en la lógica de migración.

Según los investigadores, el equipo de desarrollo de Solana respondió dentro de un día tras la divulgación de diciembre de 2025. El documento señala que el equipo consideraba el comportamiento como conocido internamente, esperaba que una actualización futura del protocolo como Alpenglow lo abordara, lo monitoreaba y consideraba que los escenarios más graves eran improbables en las condiciones actuales.

Los autores también dijeron que no habían desplegado completamente la mitigación al momento de la publicación.

Una descripción general de la Solana Foundation sobre Agave 4.2 señaló que el cliente incluía código de Alpenglow para clústeres de prueba comunitarios pero no activaba el nuevo consenso en la mainnet, con activación esperada en Agave 4.3.

El ataque heredado a PoH descrito en el documento parece haber quedado fuera del concurso de 50,000 $SOL, y Alpenglow está diseñado para eliminar sus requisitos previos exactos. Hasta la activación —esperada en Agave 4.3— y una respuesta pública a nivel de implementación, la transición sigue siendo la parte no resuelta de la historia.