Solana ha migrato la sua rete di sviluppo su Alpenglow, un importante aggiornamento del consenso progettato per ridurre drasticamente i tempi di finalità delle transazioni e cambiare il modo in cui i validatori si coordinano sulla blockchain. La migrazione è stata completata il 25 settembre, con l'attivazione — nota come Alpenswitch — entrata in vigore all'epoca 1167 dopo un conto alla rovescia di 17 minuti. La transizione è stata eseguita dagli ingegneri di Anza, l'azienda che sviluppa il software core per la rete Solana, e il co-fondatore di Solana Anatoly Yakovenko ha evidenziato l'obiettivo raggiunto con un breve post sui social media subito dopo la migrazione.

Alpenglow è progettato per ridurre la finalità delle transazioni di Solana da circa 12,8 secondi a un intervallo di 100-150 millisecondi, abilitando potenzialmente conferme quasi istantanee per le applicazioni che dipendono da un regolamento rapido. La finalità è il punto in cui una transazione è considerata definitivamente regolata e non può essere annullata, il che la rende uno dei parametri fondamentali per quanto una blockchain sia reattiva nella pratica; portare quella garanzia da diversi secondi a una frazione di secondo avvicinerebbe la conferma alla immediatezza che gli utenti si aspettano dalle applicazioni internet convenzionali.

L'aggiornamento è ora in fase di test sul devnet di Solana, dopo che il protocollo era già stato distribuito sulla testnet. Eseguire il nuovo sistema di consenso su entrambi gli ambienti di test pubblici offre a sviluppatori e operatori di rete l'opportunità di esaminarne prestazioni e stabilità prima che venga presa qualsiasi decisione sul deployment sulla rete mainnet-beta, l'ambiente di produzione in le transazioni hanno valore reale.

Votor sostituisce TowerBFT

Il cuore della modifica sostituisce il consolidato meccanismo di consenso TowerBFT di Solana, che garantisce la sicurezza della rete dal lancio della mainnet nel 2020, con Votor, un nuovo sistema di voto sviluppato dagli ingegneri di Anza in collaborazione con ricercatori del ETH Zurich. I validatori hanno approvato la modifica tramite il Solana Improvement Document SIMD-0326, il meccanismo formale della rete per ratificare le modifiche al protocollo.

Votor modifica il modo in cui i validatori scambiano le informazioni di voto. Invece di registrare i singoli voti tecnici come transazioni all'interno dei blocchi, i validatori comunicano tali voti direttamente, e le informazioni possono poi essere consolidate in certificati crittografici BLS — firme aggregate che condensano molti voti individuali in un'unica prova compatta.

La modifica è intesa a ridurre la quota di capacità dei blocchi consumata dall'attività legata al consenso. Le transazioni tecniche di voto occupavano in precedenza una parte sostanziale dello spazio dei blocchi di Solana, con alcune stime che collocavano la cifra fino al 75%. Spostando questa attività fuori dal flusso delle transazioni e aggregandola in certificati compatti, Alpenglow è progettato per liberare capacità di rete aggiuntiva per le transazioni degli utenti, riducendo potenzialmente i costi operativi per i validatori.

In modo significativo, l'aggiornamento non richiede una riprogettazione fondamentale della macchina virtuale o dell'architettura dei smart contract di Solana. Le applicazioni basate sull'attuale Solana Virtual Machine possono continuare a operare mentre cambia il meccanismo di consenso sottostante.

Obiettivi di finalità inferiore al secondo

L'obiettivo principale di Alpenglow è una riduzione sostanziale del tempo necessario affinché le transazioni diventino definitive. Con il nuovo sistema, la finalità è prevista in circa 100 millisecondi quando i validatori che rappresentano almeno l'80% dello stake della rete rispondono entro la finestra richiesta. Un meccanismo di fallback è progettato per garantire la finalità in circa 150 millisecondi quando la soglia più alta non viene raggiunta immediatamente.

Il passaggio a una finalità inferiore al secondo potrebbe rivelarsi particolarmente rilevante per le applicazioni di pagamento, i sistemi di trading e i giochi Web3, dove i ritardi nella conferma delle transazioni incidono direttamente sull'esperienza utente.

Il protocollo incorpora anche un modello di tolleranza ai guasti 20+20. Secondo questa struttura, la rete è progettata per rimanere stabile se il 20% dei validatori diventa non disponibile mentre un altro 20% subisce simultaneamente attacchi o altre interruzioni.

Gli sviluppatori iniziano i test sul campo

Il deployment sul devnet offre agli sviluppatori di applicazioni un ambiente a basso rischio per testare il software rispetto alle nuove regole di consenso. I token del devnet non hanno valore monetario reale, consentendo ai team di esaminare il comportamento delle transazioni senza esporre gli utenti ai rischi finanziari legati all'attività su mainnet. Le applicazioni di pagamento potrebbero utilizzare l'ambiente per valutare conferme più rapide, mentre i giochi blockchain potreb testare se una latenza di regolamento inferiore migliori le esperienze interattive.

Non tutte le applicazioni richiederanno modifiche. Il software di base che invia transazioni o legge i saldi dei conti può continuare a operare senza modifiche importanti. Tuttavia, le piattaforme di analisi e i servizi che contano le transazioni blockchain potrebbero dover adeguare i propri metodi, poiché i voti dei validatori non appariranno più come singole transazioni all'interno dei blocchi.

Alpenglow is live on devnet >
— Solana (@solana) September 25, 2026

Anche i servizi di dati dovranno tenere conto dei blocchi candidati in competizione fino a quando la rete raggiunge l'accordo finale; combinare prematuramente informazioni provenienti da blocchi in competizione potrebbe creare registri storici inesatti.

I tempi per la mainnet restano incerti

Alpenglow è ora in esecuzione sul devnet e sulla testnet di Solana, ma non è stata annunciata una data precisa per il deployment su mainnet-beta. I test di stabilità sono ancora in corso e le cifre di prestazioni citate sono obiettivi basati su test del protocollo e simulazioni, non risultati confermati in condizioni di mercato reali e complete. L'esperienza utente effettiva potrebbe inoltre dipendere dall'elaborazione dei wallet, dalle procedure di deposito degli exchange e da altre infrastrutture esterne al livello di consenso.

La fase di test pubblica offre agli sviluppatori di Solana e ai fornitori di infrastrutture l'opportunità di verificare se la velocità e la resilienza previste da Alpenglow possano tradursi in prestazioni affidabili prima che il protocollo venga considerato per il deployment sulla mainnet. La migrazione rappresenta quindi una significativa prova tecnica per Solana piuttosto che un aggiornamento completato su tutta la rete, e i risultati del devnet e della testnet forniranno prove importanti su come la nuova architettura di consenso si comporta sotto carichi di lavoro più ampi — e se la rete potrà avanzare verso la finalità inferiore al secondo prevista su infrastruttura reale. Gli indicatori da osservare d'ora in avanti sono se devnet e testnet manterranno le cifre di finalità previste man mano che i carichi di test crescono, e se un successivo passo di governance metterà l'attivazione su mainnet-beta su un calendario concreto.