Il futuro di Solana: l'aggiornamento Alpenglow porta la finalità delle transazioni a 150 millisecondi

Solana è pronta per il suo cambiamento di protocollo più significativo dal lancio. L'aggiornamento Alpenglow (proposta formale SIMD-0326) è una riscrittura completa dell'architettura di consenso della rete, che sostituisce due dei suoi componenti fondamentali — Proof of History (PoH) e Tower BFT — con un nuovo algoritmo di voto chiamato Votor e firme aggregate basate su BLS . La promessa principale: la finalità delle transazioni scende dagli attuali ~12,8 secondi a soli 100–150 millisecondi, un miglioramento di circa 100 volte .

Ecco tutto quello che c'è da sapere sull'aggiornamento: dai meccanismi tecnici e il rollout graduale tramite il client validatore Agave, alle misure di sicurezza e alla più ampia tabella di marcia infrastrutturale di cui fa parte.

Come Alpenglow Cambia il Consenso e la Finalità

Le modifiche sono profonde. La tabella seguente riassume le differenze principali tra il consenso attuale di Solana e quello che porterà Alpenglow:

Aspetto	Solana Attuale	Dopo Alpenglow
Meccanismo di consenso	Proof of History (PoH) + Tower BFT	Algoritmo di voto Votor + firme BLS
Finalità delle transazioni	~12,8 secondi (finalità deterministica di TowerBFT)	100–150 ms
Tolleranza ai guasti	33%	40% in scenari di guasto misto
Voto dei validatori	On-chain, escalation di voto a più fasi	Off-chain tramite Validator Admission Ticket (VAT); voti aggregati con BLS

Votor è il perno. Invece dell'escalation di voto a più livelli richiesta da Tower BFT — che necessitava di 32 turni di voto incrementali con periodi di lockout cumulativi — Votor permette ai validatori di finalizzare i blocchi in uno o due round . Nel percorso veloce (fast path), un blocco viene finalizzato immediatamente dopo un round se almeno l'80% del peso totale in stake lo supporta, raggiungendo la finalità in circa 100 ms. Se il supporto è tra il 60% e l'80%, si attiva un secondo round, raggiungendo la finalità in circa 150 ms .

Lo spostamento dei dati di voto off-chain tramite firme aggregate BLS ha anche un importante effetto collaterale: libera circa un terzo dell'attuale spazio dei blocchi di Solana — che prima veniva utilizzato per registrare i voti individuali dei validatori come transazioni on-chain — per le transazioni degli utenti reali .

Sviluppo e Tempistiche di Rollout: Agave 4.2 vs. 4.3

Il rollout è deliberatamente suddiviso in due rilasci del client validatore Agave, l'implementazione principale mantenuta da Anza. Questo approccio in due fasi permette di distribuire il codice completo di Alpenglow in anticipo per test della community, audit di sicurezza e validazione su cluster di prova prima dell'attivazione su mainnet.

Agave 4.2 (Agosto 2026) — Il Banco di Prova

• Raccomandato per l'adozione su mainnet: Agosto 2026, con attivazioni delle funzionalità a partire dalla settimana del 17 agosto .
• Cosa attiva su mainnet: Tre aggiornamenti non Alpenglow: una riduzione di circa il 90% dei costi di rent on-chain, il supporto per transazioni più grandi (il nuovo formato Transaction v1) e il primo passo di una riduzione del tempo slot in cinque fasi da 400ms verso un target di 200ms . Il primo decremento porta gli slot da 400ms a 350ms .
• Stato di Alpenglow in 4.2: Il codice completo di Alpenglow viene distribuito completo di funzionalità ma NON viene attivato su mainnet. È incluso per l'uso su cluster di test della community e per la revisione della sicurezza .

Agave 4.3 (Settembre–Ottobre 2026) — Attivazione su Mainnet

• Attivazione mainnet prevista: Ci sono due date pubbliche da fonti ufficiali. Anza ha pubblicato un calendario il 12 agosto con target il 28 settembre 2026 per l'attivazione delle funzionalità su mainnet-beta . La Solana Foundation ha descritto l'obiettivo come ottobre 2026 .
• Cosa attiva: Il consenso Alpenglow entra in funzione su mainnet. I validatori devono aver creato un Validator Admission Ticket (VAT) e aggiornato la gestione delle chiavi pubbliche BLS per partecipare .
• Incertezza chiave: Alcuni resoconti e discussioni hanno indicato un lancio a settembre, ma le indicazioni ufficiali della Solana Foundation legano l'attivazione ad Agave 4.3 con un target di ottobre . Le date rimangono obiettivi, non garanzie. L'impalcatura ingegneristica — approvazione della governance, mesi di test sui cluster, uno sprint di sicurezza con bug bounty e la registrazione delle chiavi BLS già attiva su mainnet — è ampiamente in atto, ma non è stato pubblicato alcun blocco o epoca di attivazione esatta .

Misure di Sicurezza: Bug Bounty, Test e Sicurezza Economica

Data la portata del cambiamento, Anza e la Solana Foundation hanno implementato un approccio alla sicurezza a più livelli:

• Competizione Bug Bounty: Anza ha aperto un bug bounty dedicato per Alpenglow su GitHub, con invii aperti dal 5 agosto 2026 al 19 agosto 2026 . I premi arrivano fino a 50.000 SOL (circa 3,8 milioni di dollari) per i ricercatori che trovano vulnerabilità nei componenti principali di Votor e BLS . La competizione si concentra su quattro moduli nel codebase anza-xyz/agave: votor (il motore di voto), votor-messages (serializzazione di voti e certificati), bls-sigverify e bls-cert-verify .
• Test Multi-fase: Il codice di Alpenglow è attivo su un cluster di test della community di Anza dall'11 maggio 2026 — la prima volta che validatori esterni hanno potuto eseguirlo . È poi stato distribuito in Agave 4.2 per test più ampi della community e revisione della sicurezza prima dell'attivazione su mainnet . Durante i primi test sul cluster, sono stati scoperti e corretti almeno due bug: uno nel codice di migrazione TowerBFT/PoH e un secondo in cui i validatori bannavano accidentalmente le connessioni peer .
• Validator Admission Ticket (VAT): Una tassa fissa di 1,6 SOL per epoca per i validatori per partecipare al set di consenso attivo, progettata per prevenire spam e proteggere economicamente il set di voto .
• Maggiore tolleranza ai guasti: Il nuovo consenso aumenta la tolleranza ai guasti bizantini in scenari di guasto misto dal 33% al 40%, migliorando la resilienza contro scenari in cui fino al 20% dei validatori si comporta in modo malevolo e un altro 20% è contemporaneamente offline .

Contesto Generale: Alpenglow nella Roadmap 2026 di Solana

Alpenglow è un tassello del più ampio programma di sviluppo infrastrutturale di Solana per il 2026, volto a far evolvere la rete in quelli che il team chiama "Mercati Finanziari di Internet" (Internet Capital Markets) — una piattaforma finanziaria ad alte prestazioni e di livello istituzionale .

• Firedancer: Un client validatore indipendente di Jump Crypto che ha superato il 20% dello stake su mainnet dopo circa 100 giorni . Firedancer e Alpenglow sono complementari — Firedancer migliora la diversità dei client e la throughput di esecuzione (raggiungendo 1 milione di TPS nei test), mentre Alpenglow rielabora la finalità del consenso .
• ACE (Asynchronous Concurrent Execution): Un nuovo modello di esecuzione progettato per un ordinamento delle transazioni più equo e una maggiore produttività sotto carico .
• DoubleZero / IBRL: Miglioramenti al livello di rete e larghezza di banda per ridurre ulteriormente la latenza dei validatori .
• Mandato di Governance: La SIMD-0326 è stata approvata con il 98,27% dei voti dei validatori a settembre 2025, riflettendo un consenso eccezionalmente forte della community per il cambiamento .

Insieme, questi aggiornamenti posizionano Solana per offrire finalità sub-150ms, capacità di picco di milioni di TPS e ridondanza multi-client — caratteristiche che rendono la rete credibile come infrastruttura per trading ad alta frequenza, carichi di lavoro finanziari tradizionali e applicazioni consumer che richiedono regolamento quasi istantaneo .