L'upgrade Alpenglow di Solana è pronto ad attivare un nuovo protocollo di consenso sulla Mainnet Beta della blockchain il 21 ottobre, con una finalità attesa in calo dai roughly 12,8 secondi a circa 150 millisecondi. La rete principale, tuttavia, dovrà ancora dimostrare questo obiettivo nella pratica.

Solana è una blockchain di layer 1 su cui i validatori producono blocchi e li confermano mediante voto. Il protocollo di consenso determina quando una transazione si considera irreversibile — un compito affidato finora a un meccanismo chiamato TowerBFT. Alpenglow ha debuttato a maggio 2025 alla conferenza Solana Accelerate. Il concetto è stato sviluppato sotto la guida di Roger Wattenhofer dell'ETH di Zurigo, insieme ai suoi ex dottorandi Kobi Sliwinski e Quentin Kniep, che ora lavorano presso Anza, sviluppatore di Solana. A settembre 2025, i validatori hanno approvato la proposta SIMD-0326 con il 98,27% dei voti espressi. Il suo componente centrale, Votor, sostituisce l'attuale TowerBFT.

Rispetto ai valori attuali, l'obiettivo dei 150 ms equivale a una finalità circa 85 volte più rapida. I 150 millisecondi si riferiscono al tempo di finalità, non al tempo di blocco: l'esecuzione delle transazioni, la Solana Virtual Machine (SVM) e le commissioni restano invariate.

Votor sostituisce TowerBFT nella votazione dei validatori

Con TowerBFT, i voti dei validatori transitano sulla blockchain come normali transazioni. È proprio questo che Votor modifica. Da ora in poi, i validatori si scambieranno i voti direttamente tra loro e li raggrupperanno in certificati BLS, così che un unico certificato combini l'approvazione di molti validatori in un solo record. Di conseguenza, i voti non compariranno più come transazioni on-chain all'interno dei blocchi. L'accelerazione proviene quindi dal nuovo processo di voto, non da blocchi più veloci.

Votor ha due percorsi verso la finalità. Se almeno l'80% dello stake certifica un blocco nel primo round, il blocco diventa definitivo al termine di quel round — un percorso rapido che dovrebbe richiedere circa 100 millisecondi. Fino a un quinto dello stake può restare assente senza bloccare questa via. Al contrario, se l'approvazione del round 1 si colloca tra il 60% e l'80%, subentra il percorso più lento, a circa 150 millisecondi.

Solana stessa descrive i 150 millisecondi nella sua pagina ufficiale dell'upgrade come un'aspettativa, non una costante. In, la riduzione della durata dello slot da 400 a 200 millisecondi non fa parte di Alpenglow; la rete ha completato questa modifica separata in precedenza, in quattro fasi fino a ottobre 2026. Per exchange, market maker e fornitori di servizi di pagamento, la finalità è la metrica chiave, poiché determina quando una transazione si considera regolata. Risultati positivi negli ambienti di test, pertanto, non sostituiscono la prova sotto il carico reale della mainnet.

La migrazione Alpenglow nell'epoch 1064 richiede un coordinamento rigoroso

Il passaggio inizia con l'avvio dell'epoch 1064 il 21 ottobre, quando una feature gate attiverà la nuova logica. TowerBFT produrrà prima altri 5.000 slot — circa 18 minuti — prima che Alpenglow subentri allo slot 459.653.000. Durante questa transizione, la rete sospenderà brevemente l'inclusione delle transazioni degli utenti nei blocchi. Votor si avvia solo quando i validatori che detengono almeno l'82% dello stake avranno firmato un certificato di genesi, il che rende questo un intervento coordinato e una tantum su una rete attiva.

La questione dei client dei validatori è delicata. La migrazione esclude per ora i client alternativi Firedancer e Frankendancer, quindi i loro operatori dovranno passare temporaneamente a software basati su Agave 4.3 prima dell'epoch 1064. Le opzioni includono Agave stesso, Jito-Solana e Harmonic Salsa, con Solana che specifica la versione 4.3.2. Qualsiasi validatore che non effettuerà il passaggio in tempo non figurará nel certificato di genesi — e più stake non effettua il passaggio, più sottile diventa il margine sopra la soglia dell'82%. Quanto stake finirà in quel primo certificato sarà quindi uno dei primi risultati visibili del passaggio.

Il percorso verso l'attivazione è tuttavia proceduto per fasi ordinate. Da luglio 2026, due passi preliminari sono in esecuzione sulla mainnet: la gestione delle chiavi BLS nell'account di voto (SIMD-0387) e il Validator Admission Ticket (SIMD-0357). Anza ha lanciato un cluster di test comunitario a maggio 2026, seguito da una testnet pubblica a settembre e da una devnet un giorno dopo. A metà ottobre, il team di sviluppo ha annunciato la data della mainnet.

I validatori pagano 0,8 SOL per epoch invece delle commissioni di voto

Sparite le transazioni di voto, spariscono anche le loro commissioni. Al loro posto subentra il Validator Admission Ticket (VAT), il cui fondamento tecnico è attivo sulla mainnet da luglio 2026. Costa 0,8 SOL per epoch, che la rete brucia, rimuovendo i token dalla circolazione. Inoltre, il saldo dell'account di voto deve trovarsi ad almeno 0,8 SOL sopra il minimo esente da affitto. La commissione scade per la prima volta all'inizio dell'epoch 1064, coprendo l'epoch 1065; i validatori che non pagano non potranno né votare né produrre blocchi nell'epoch successivo. Il primo ciclo di addebito mostrerà quindi, nella pratica, quanti operatori finanziano i propri account di voto nei tempi previsti.

Per gli operatori, questo stravolge la struttura dei costi. Finora ogni singolo voto richiedeva una transazione on-chain e con essa commissioni continue — costi che si generavano per validatore, in gran parte indipendentemente dallo stake. Se la nuova commissione fissa è inferiore alle precedenti commissioni di voto, ne beneficiano soprattutto i validatori più piccoli poiché costi fissi di questo tipo pesano in modo comparativamente rilevante rispetto al loro stake.

Si perde inoltre un effetto collaterale statistico. Le transazioni di voto contavano in precedenza nel dato dei transazioni al secondo (TPS) riportato, quindi il TPS dichiarato potrebbe diminuire dopo l'upgrade. Si tratta di un effetto di conteggio, non di un problema di rete.

Tolleranza bizantina ridotta, domande aperte su latenza e MEV

Anche il modello di sicurezza cambia. TowerBFT può resistere fino al 33% di stake bizantino, ovvero stake che agisce in modo malevolo. Votor abbassa questa tolleranza puramente bizantina al 20%, tollerando al contempo che un ulteriore 20% dello stake sia offline — il cosiddetto modello 20+20. La tolleranza complessiva alle interruzioni aumenta quindi, mentre diminuisce la tolleranza agli attacchi attivi.

Anche il settore ha sollevato obiezioni specifiche. Il progetto blockchain Sei vede una pressione verso la centralizzazione, osservando che un segnale richiede circa 80-100 millisecondi per un round trip attraverso l'Atlantico — un tragitto che da solo supera metà del valore obiettivo. Il fornitore di infrastrutture Helius indica questioni aperte riguardo a Multiple Concurrent Leaders e MEV nella votazione off-chain, e le penalità per l'equivocazione — l'invio di blocchi o voti contrastanti per lo stesso slot — restano anch'esse irrisolte. Poiché questi punti riguardano la progettazione del protocollo più che i meccanismi della migrazione, restano aperti anche dopo l'attivazione di Alpenglow.

Questa attivazione lascia fuori alcuni componenti. Rotor, la sostituzione prevista del layer di distribuzione dati Turbine, appartiene solo alla seconda fase e non ha ancora una data. In seguito, Agave 4.4 dovrebbe introdurre un Fast Leader Handoff, che Anza prevede in meno dell'1% degli slot. In ultima analisi, solo i dati di misurazione dopo l'epoch 1064 mostreranno se Votor raggiunge i 150 millisecondi nell'operatività quotidiana.