Solana attiva Alpenglow, finalità target a 150 millisecondi

Il 21 ottobre 2026, alle ore 13:54 UTC circa, Solana ha attivato Alpenglow sulla mainnet-beta, sostituendo TowerBFT con Votor e portando il target di finalità da circa 12,8 secondi a 150 millisecondi, secondo Anza e la Solana Foundation.

Abbiamo letto la pagina ufficiale Alpenglow della Solana Foundation (aggiornata ottobre 2026), le dichiarazioni di Anza del 21 ottobre e i resoconti di Decrypt, The Block e Unchained. Nessuna fonte primaria è risultata inaccessibile.

Cosa è stato attivato il 21 ottobre

L’epoch 1064 è iniziato intorno alle 13:36 UTC. Dopo 5.000 slot, a slot 459.653.000, il network ha effettuato il passaggio da TowerBFT a Votor. Anza ha dichiarato che la finalità è passata da 12,8 secondi a circa 150 millisecondi. La Solana Foundation conferma che Alpenglow è live da quell’epoch e che Votor è la fase ora operativa.

Votor fa sì che i validatori scambino voti direttamente e li aggreghino in certificati, invece di inserirli come transazioni on-chain. Un blocco diventa finale dopo uno o due round di voto (percorso veloce all’80% di stake o fallback al 60%). L’esecuzione delle transazioni, la SVM, i programmi e le fee restano invariati.

Perché conta per exchange, merchant e utenti

Sotto TowerBFT una transazione poteva essere confermata in pochi secondi ma richiedeva circa 12,8 secondi per la finalità piena, il punto in cui non è più reversibile. Con Votor il target è di portare quel momento a circa 150 millisecondi. Secondo Anza, questo riduce il tempo di attesa per exchange che accreditano depositi e per merchant che processano pagamenti.

Per gli utenti finali wallet e app continuano a funzionare come prima. La differenza percepita, se il target viene rispettato, è una conferma quasi immediata. La Foundation sottolinea che la finalità di 150 ms è un target di design, non una garanzia indipendente da condizioni di rete. Anza ha precisato che le prestazioni reali dipenderanno dalle condizioni della rete e dalla distribuzione geografica dei validatori.

Il passaggio è avvenuto dopo l’approvazione della proposta SIMD-0326 nel settembre 2025, con circa il 98% dei voti favorevoli dei validatori. Anza ha portato il protocollo da white paper (maggio 2025) a mainnet in meno di 18 mesi. I test su cluster comunitari e su devnet/testnet avevano già mostrato la capacità di completare migrazioni live, anche se con alcuni rollback durante le prove.

Cosa non cambia e cosa resta aperto

Rotor, la seconda fase che dovrebbe sostituire Turbine nella propagazione dei blocchi, non ha ancora una data. La Solana Foundation lo indica come “later release, unscheduled”. Anche Proof of History non governa più il ritmo dei blocchi nello stesso modo, ma i dettagli di esecuzione per gli sviluppatori di applicazioni semplici restano invariati.

I validatori devono usare un client basato su Agave 4.3.2 (Agave, Jito-Solana o Harmonic Salsa) e mantenere almeno 0,8 SOL nel vote account sopra il minimo rent-exempt per pagare il Validator Admission Ticket. Firedancer e Frankendancer non erano supportati per la migrazione.

Le prime letture di dashboard, riportate da Altcoin Buzz e altri, hanno mostrato valori intorno ai 202 millisecondi in singoli campioni. Non esiste ancora una media sostenuta e indipendente pubblicata che confermi i 150 ms su mainnet. È una nostra lettura: il dato di design è chiaro, la misura operativa è ancora in fase di osservazione.

Il contesto con gli altri upgrade di Solana

Questo passaggio di consenso è distinto dalla riduzione dei tempi di slot. Come abbiamo ricostruito nell’articolo sulla riduzione degli slot da 400 a 350 ms, SIMD-0525 interviene sulla durata target dei blocchi, non sulla finalità. Alpenglow agisce sul protocollo di accordo tra validatori.

In aprile avevamo descritto il disegno di Alpenglow come upgrade pianificato. Ora la prima fase è live. Il network continua a gestire volumi elevati di attività, incluso il 97% del volume di azioni tokenizzate on-chain secondo dati riportati in precedenza su Solana e RWA.

La proposta SIMD-0370 di Firedancer, che mira a rimuovere limiti statici di calcolo per blocco dopo Alpenglow, resta un percorso successivo e non ancora approvato, come descritto nel pezzo sulla proposta per blocchi senza limiti.

E in Italia?

Non esistono, al momento, comunicazioni specifiche di exchange o operatori italiani su modifiche operative legate ad Alpenglow. La finalità più rapida, se confermata dalle misure, riduce il tempo di attesa teorico per depositi e prelievi, ma le policy di conferma di ciascuna piattaforma restano autonome. La classificazione di Solana come digital commodity, riportata nel documento congiunto SEC-CFTC del marzo 2026 e ricostruita nel nostro pezzo su Bitcoin, Ethereum e Solana come commodity digitali, non cambia con questo upgrade tecnico. Un ulteriore elemento di contesto è la capacità della rete di gestire carichi elevati, già discussa nel pezzo sulla resilienza di Solana durante l’attacco DDoS da 6 Tbps.

Per chi opera su Solana da Italia il punto pratico è lo stesso di altri utenti: wallet e app non richiedono azioni. I validatori italiani, se presenti, devono rispettare i requisiti di client e di balance sul vote account.

Alpenglow in sintesi

Cosa è confermato, cosa no

• Confermato: Votor attivo su mainnet dal 21 ottobre 2026 a slot 459.653.000; TowerBFT ritirato; target di finalità ~150 ms dichiarato da Anza e Solana Foundation.
• Non indicato: misura indipendente e sostenuta della finalità media su mainnet; data di Rotor; impatto operativo specifico per piattaforme italiane.
• Da seguire: letture dashboard e misurazioni indipendenti nelle prossime settimane; eventuale attivazione di Rotor; adozione dei requisiti di client da parte dei validatori.

La lettura più grande

È una nostra lettura: Alpenglow chiude un ciclo iniziato con il white paper di maggio 2025 e porta Solana a un modello di finalità in millisecondi, allineando il tempo di irreversibilità a quello di molte infrastrutture di pagamento tradizionali. Il cambiamento è reale sul protocollo di consenso. La misura operativa del “150 millisecondi” resta un target dichiarato, non ancora un dato consolidato da osservatori indipendenti.

I segnali concreti da seguire sono le prime medie di finalità pubblicate da dashboard e provider RPC, l’eventuale annuncio di una data per Rotor, e se i validatori che non hanno ancora aggiornato il client mantengono la partecipazione. Per gli utenti e le piattaforme il test pratico sarà se i tempi di conferma percepiti si accorciano senza cambiamenti di codice lato client.