Il concorso di sicurezza da 50.000 SOL di Solana non ha coperto un attacco al clock divulgato mesi prima

Al USENIX Security, una delle principali conferenze del settore sottoposte a revisione paritaria, i ricercatori hanno presentato il 12 agosto un attacco al clock basato su Proof-of-History di Solana che avevano divulgato privatamente agli sviluppatori di Solana nel dicembre 2025. Anza — l'azienda che sviluppa il client di validazione Agave — ha chiuso il proprio concorso Alpenglow da 50.000 $SOL sette giorni dopo, e le sue regole sembrano aver collocato l'attacco al di fuori dell'ambito.

Il paper descrive un metodo valido a livello di protocollo con cui un leader programmato può estendere la propria finestra effettiva di blocco e sopprimere le proposte dei leader onesti in una variante assistita dai fork. La tecnica dipende da Proof-of-History e TowerBFT — l'orologio logico di Solana e il meccanismo di consenso costruito al di sopra di esso — i componenti che Alpenglow è destinato a sostituire ma che non aveva ancora rimpiazzato sulla mainnet in Agave 4.2.

Il risultato solleva due questioni distinte: se l'attacco rientrasse nell'ambito del concorso e se la transizione del protocollo lasci di per sé spazio a rischi.

Le regole del concorso escludevano i comportamenti raggiungibili solo quando Alpenglow era inattivo. I documenti di progettazione pubblici indicano che l'esatto percorso legacy descritto nel paper dovrebbe diventare irraggiungibile dopo l'attivazione, ma Anza e la Solana Foundation non hanno pubblicato una valutazione specifica sul paper né un'analisi a livello di implementazione.

Come un leader può allungare il clock di Solana

Proof-of-History, o PoH, utilizza una catena di hash sequenziale per fornire a Solana un orologio logico. I validator continuano a far avanzare la propria visione locale di tale orologio quando un leader programmato non pubblica immediatamente un blocco.

Secondo i ricercatori, un leader programmato malintenzionato può trattenere un blocco valido a livello di protocollo mentre i validator onesti procedono, per poi rilasciare in un secondo momento il blocco ancorato a un punto precedente del tempo logico. Se i validator adottano quel ramo, allineano il proprio stato PoH al punto precedente del blocco. I ricercatori definiscono questo ripristino “re-anchoring”.

Time Inflation, o TI, ripete quella manovra per dare all'attaccante più tempo fisico per scegliere le transazioni mentre il tempo logico avanza più lentamente. Fork-Assisted Time Inflation, o FTI, combina il ripristino con la fork choice di TowerBFT.

Nelle condizioni modellate, il ramo dell'attaccante può rendere orfano il blocco di un leader onesto, e la regola di Solana di un blocco per slot impedisce a quel leader di produrre semplicemente un altro blocco per lo stesso slot.

Il modello di minaccia assegna all'avversario meno del 33% dello stake — al di sotto del limite di tolleranza di un terzo dei guasti che i protocolli Byzantine-fault-tolerant sono convenzionalmente progettati per tollerare — e nessun controllo sullo scheduler di rete. Assume una programmazione dei leader nota e ponderata per stake, una sincronia parziale e la consegna di un blocco onesto ai validator onesti entro uno slot nominale dopo la stabilizzazione della rete.

Per un attaccante che controlla ℓ turni consecutivi di leader da quattro slot, gli esperimenti utilizzano un ritardo massimo conservativo e indipendente dallo stake di 4ℓ + 1 unità di slot. Un turno corrisponde a un parametro di ritardo di cinque unità di slot.

Il paper afferma che uno stake maggiore potrebbe ampliare una finestra di rilascio senza rischio, ma non presenta tale configurazione sperimentale come un risultato universale sulla mainnet.

I ricercatori hanno implementato TI e FTI su una testnet Solana locale e hanno utilizzato simulazioni per configurazioni di attaccanti su epoch complete. Non hanno identificato una specifica versione di Agave interessata, quindi il paper non stabilisce che ogni versione corrente del client sia esposta nello stesso modo.

Cosa mostrano i dati pubblici

I ricercatori hanno inoltre esaminato dati pubblici della mainnet e selezionato due validator che si collocavano ripetutamente nella coda della distribuzione degli intervalli tra timestamp. Questi validator associavano intervalli più lunghi a un'inclusione delle transazioni più elevata e a tassi di skip bassi.

Il pattern è coerente con il canale di incentivi di TI perché una finestra fisica più lunga crea più opportunità di selezionare transazioni con commissioni — un vantaggio nell'ordinamento delle transazioni del tipo che l'industria più ampia discute sotto l'etichetta maximal extractable value, o MEV.

Il paper rileva che differenze hardware, batching locale o altre scelte di configurazione, condizioni di rete e interruzioni operative potrebbero creare pattern temporali simili. Non ha inoltre riscontrato alcun tasso di skip a valle significativamente elevato e ha affermato che il pattern osservato era incompatibile con un'attribuzione a FTI.

La ricerca stabilisce una questione di equità e latenza valida a livello di protocollo attraverso test controllati e misurazioni indicative. Non mostra alcun exploit attivo, furto, manipolazione dimostrata sulla mainnet o violazione della sicurezza del consenso.

Perché il concorso Alpenglow di Solana probabilmente lo ha escluso

Le candidature al concorso Alpenglow si sono chiuse il 19 agosto alle 16:00 UTC. Le regole coprivano la superficie di consenso con la funzionalità Alpenglow attiva, il codice di integrazione il cui comportamento cambiava perché Alpenglow era attivo e il percorso di migrazione da TowerBFT ad Alpenglow.

I comportamenti raggiungibili solo quando Alpenglow era inattivo appartenevano al dominio di TowerBFT ed erano esclusi dal concorso. Anche i problemi già resi pubblici in precedenza non erano ammessi.

Il divario è un tema noto nei concorsi di sicurezza a tempo limitato: sono le regole di ambito, non la gravità, a decidere cosa viene premiato. Il concorso copriva i guasti causati da Alpenglow o dalla sua migrazione, mentre il paper prende di mira il modello legacy di tempo e fork choice che Alpenglow è progettato per sostituire.

Cosa cambia Alpenglow

La panoramica di Alpenglow di Anza afferma che l'aggiornamento sostituisce TowerBFT e PoH come componenti principali del consenso con Votor. La proposta ufficiale SIMD-0326 — un Solana Improvement Document nel processo formale di modifica della rete — descrive timeout locali che svolgono un ruolo temporale senza tempo sincronizzato e definisce la modifica incompatibile con le versioni precedenti.

Quei progetti eliminano i prerequisiti di re-anchoring di PoH e di fork choice di TowerBFT utilizzati da TI e FTI. Il registro pubblico non comprende un'analisi di Anza o della Solana Foundation che mappi ogni fase dell'attacco sul codice Alpenglow in distribuzione o che escluda un problema analogo nella logica di migrazione.

Secondo i ricercatori, il team di sviluppo di Solana ha risposto entro un giorno dalla divulgazione del dicembre 2025. Il paper afferma che il team considerava il comportamento già noto internamente, si aspettava che un futuro aggiornamento del protocollo come Alpenglow lo affrontasse, lo monitorava e riteneva gli scenari più severi improbabili nelle condizioni attuali.

Gli autori hanno inoltre dichiarato di non aver distribuito completamente le mitigazioni al momento della pubblicazione.

Una panoramica della Solana Foundation su Agave 4.2 ha indicato che il client includeva codice Alpenglow per i cluster di test della community ma non attivava il nuovo consenso sulla mainnet, con attivazione prevista in Agave 4.3.

L'attacco legacy a PoH descritto nel paper sembra essere caduto al di fuori del concorso da 50.000 $SOL, e Alpenglow è progettato per eliminarne i prerequisiti esatti. Fino all'attivazione — prevista in Agave 4.3 — e a una risposta pubblica a livello di implementazione, la transizione resta la parte irrisolta della vicenda.