Solana Alpenglow oggi sulla mainnet: obiettivo finalità in 150 ms

📌 In Sintesi

• Solana programma l’attivazione di Alpenglow il 21 ottobre 2026, con l’avvio dell’epoch 1064 previsto intorno alle 15:20 italiane e il cambio di consenso circa 18 minuti dopo.
• Votor sostituisce TowerBFT e punta a ridurre la finalità delle transazioni da 12,8 secondi a circa 150 millisecondi, senza modificare esecuzione e commissioni.
• I validatori devono aggiornare i client e finanziare il nuovo sistema di ammissione, mentre explorer e indexer dovranno adattarsi alla scomparsa delle transazioni di voto.

Solana si prepara ad attivare Alpenglow sulla mainnet il 21 ottobre 2026, sostituendo TowerBFT con un nuovo protocollo di consenso progettato per ridurre la finalità delle transazioni da circa 12,8 secondi a 150 millisecondi. È uno dei cambiamenti più importanti nell’architettura della blockchain dalla sua nascita, perché interviene sul meccanismo attraverso il quale i validatori concordano definitivamente sullo stato della rete. La migrazione è programmata nell’epoch 1064, con una finestra iniziale prevista intorno alle 15:20 italiane. L’obiettivo dichiarato promette una finalizzazione molto più rapida, ma i 150 millisecondi restano un traguardo tecnico da verificare sulla mainnet, non una prestazione già dimostrata in produzione.

Alpenglow entra nell’epoch 1064: il cambio di consenso avviene dopo 5.000 slot

La documentazione ufficiale della Solana Foundation identifica l’epoch 1064 come il momento previsto per l’attivazione della nuova architettura. L’orario indicato, circa 13:20 UTC, corrisponde alle 15:20 in Italia, ma rappresenta una stima soggetta alla durata effettiva degli slot. L’avvio dell’epoch non coincide inoltre con l’immediata sostituzione di TowerBFT: per i primi 5.000 slot, equivalenti approssimativamente a 18 minuti, la rete continuerà a utilizzare il consenso precedente, mentre il passaggio a Votor è programmato allo slot 459.653.000. La migrazione è concepita per avvenire senza riavviare l’intera blockchain. Per stabilire se l’operazione sia realmente completata, la Foundation indica un controllo tecnico preciso: la chiamata RPC getAgGenesisCert, che restituisce null finché il cluster utilizza TowerBFT e un certificato di genesi quando Alpenglow diventa operativo. Il semplice raggiungimento dell’orario previsto non dimostra quindi il successo dell’attivazione. La distinzione è particolarmente importante perché Solana aveva già ridotto la durata degli slot a 250 millisecondi, intervenendo sulla velocità di produzione dei blocchi senza risolvere il problema dei tempi necessari alla loro finalizzazione definitiva.

Leggi anche: Solana lancia DvP per Wall Street con il contributo di JPMorgan

Votor sostituisce TowerBFT e porta i voti fuori dalla blockchain

Il principale cambiamento introdotto da Alpenglow riguarda il modo in cui i validatori approvano i blocchi. TowerBFT utilizza transazioni di voto registrate nella blockchain e richiede una successione di conferme prima di raggiungere la finalità. Votor elimina invece le transazioni di voto on-chain, consentendo ai validatori di comunicare direttamente e aggregare le firme crittografiche in certificati verificabili. Nel percorso più rapido un blocco può essere finalizzato dopo un solo turno, quando raggiunge l’approvazione dell’80% dello stake; se questa soglia non viene raggiunta, il protocollo prevede un secondo turno con certificati basati su soglie del 60%. Secondo la proposta tecnica SIMD-0326, il modello è progettato per tollerare una combinazione di 20% di stake malevolo e 20% di stake offline nelle condizioni previste dal protocollo. Questo non significa immunità contro qualsiasi attacco o interruzione. Cambia invece il rapporto tra resilienza, traffico di consenso e tempo necessario a considerare irreversibile un blocco. La fase attuale riguarda Votor; Rotor, destinato a sostituire successivamente il sistema di propagazione dei blocchi Turbine, rimane un aggiornamento separato e non ancora calendarizzato.

Validatori obbligati ad aggiornare Agave e versare 0,8 SOL per epoch

La migrazione comporta requisiti immediati per gli operatori della rete. Solana richiede client compatibili basati su Agave 4.3.2, includendo le versioni corrispondenti di Jito-Solana e Harmonic Salsa. Durante il passaggio Firedancer e Frankendancer non sono supportati e gli operatori interessati devono utilizzare temporaneamente un client compatibile. Cambia anche il finanziamento della partecipazione al consenso: con la rimozione delle transazioni di voto scompaiono i relativi costi, sostituiti dal Validator Admission Ticket (VAT), che richiede 0,8 SOL per epoch prelevati dal vote account. La somma deve essere disponibile oltre al saldo minimo necessario per l’esenzione dalla rent; il primo pagamento viene effettuato all’inizio dell’epoch 1064 e riguarda la partecipazione all’epoch successivo. Un validatore che non disponga del saldo richiesto viene escluso dal voto e dalla produzione dei blocchi nell’epoch seguente. Il meccanismo modifica la struttura dei costi operativi, ma introduce anche un requisito amministrativo che gli operatori devono rispettare puntualmente. Non è un costo imposto ai normali possessori di SOL, né richiede agli utenti di trasferire token o modificare i propri wallet.

Le transazioni sembreranno diminuire, ma non sarà necessariamente un calo dell’attività

Alpenglow modifica anche il modo in cui viene rappresentata l’attività sulla blockchain. Poiché i voti dei validatori non saranno più registrati come transazioni nei blocchi, i sistemi che calcolano il throughput includendo quel traffico potrebbero mostrare un brusco calo del numero complessivo di transazioni e dei TPS. Non sarebbe automaticamente una perdita di capacità o di utilizzo reale della rete, ma una discontinuità statistica che richiede nuove basi di confronto. Explorer, piattaforme analitiche e operatori di infrastrutture RPC dovranno quindi distinguere le transazioni effettivamente generate dagli utenti dal traffico di consenso eliminato. Cambiano anche le informazioni trasmesse attraverso Geyser, perché uno slot può avere più blocchi candidati e i sistemi di indicizzazione devono identificare correttamente quello finalizzato. Inoltre, con Votor gli stati confirmed e finalized convergono, mentre il riferimento temporale dei blocchi non deriva più dalla precedente mediana dei timestamp dei voti. Queste modifiche sono rilevanti per piattaforme finanziarie, servizi di indicizzazione e applicazioni che ricostruiscono gli eventi on-chain. Il tema è particolarmente sensibile mentre NYSE e operatori finanziari sperimentano mercati tokenizzati e negoziazioni continue, nei quali precisione temporale e certezza del regolamento assumono un ruolo operativo.

Pagamenti e tokenizzazione sono i benefici attesi della finalità rapida

Per gli utenti ordinari la Foundation non prevede modifiche alle procedure di firma, invio delle transazioni o gestione degli account. Alpenglow non cambia Solana Virtual Machine, formati delle transazioni o meccanismi delle commissioni: interviene sulla conferma definitiva delle operazioni, mentre la durata degli slot è già stata ridotta separatamente fino a circa 200 millisecondi. Una finalità prossima ai 150 millisecondi potrebbe migliorare pagamenti, trasferimenti di stablecoin, scambi di asset tokenizzati e applicazioni che richiedono tempi prevedibili per concludere un’operazione. Il vantaggio potenziale è evidente nella convergenza tra criptovalute, pagamenti programmabili e agenti AI, dove aspettare diversi secondi per la finalizzazione può rappresentare un limite nelle transazioni automatizzate. Tuttavia finalità blockchain e tempo complessivo percepito dall’utente non coincidono: wallet, connessione di rete, infrastrutture RPC, controlli applicativi e servizi esterni possono introdurre ulteriori ritardi. Un protocollo più rapido non garantisce dunque pagamenti istantanei in ogni situazione, ma riduce uno dei vincoli alla base delle applicazioni finanziarie costruite su Solana.

Continua con:

Europa e criptovalute: XRP Ledger e Solana accelerano nei pagamenti

Solana e Monad tra ETF, geopolitica e adozione istituzionale

Il vero test sarà mantenere la finalità rapida senza sacrificare la stabilità

Il successo di Alpenglow non potrà essere misurato soltanto dal raggiungimento dei 150 millisecondi in condizioni favorevoli, ma dalla capacità di mantenere finalità prevedibile, continuità operativa e correttezza del consenso quando la rete è sottoposta a carico elevato o parte dei validatori incontra problemi. Anza ha accompagnato lo sviluppo con prove su cluster dedicati e un programma di bug bounty che prevedeva un montepremi massimo di 50.000 SOL, dedicato anche a vulnerabilità capaci di compromettere consenso, disponibilità o sicurezza dei fondi. Il programma di verifica pubblicato nel repository ufficiale testimonia l’importanza attribuita al controllo del nuovo protocollo, senza costituire una garanzia di assenza di vulnerabilità. Al momento della preparazione di questo articolo, l’attivazione sulla mainnet è ancora programmata e deve essere confermata attraverso lo stato effettivo del cluster. Se la migrazione riuscirà, Solana avrà ridotto drasticamente il tempo necessario alla finalizzazione senza modificare la logica di esecuzione delle applicazioni. La prova decisiva arriverà però dalle prestazioni osservate dopo il cambio di consenso, non dalla sola promessa dei 150 millisecondi.