Revisione tecnica: 23 ottobre 2026. Alpenglow di Solana cambia il modo in cui i validatori raggiungono il consenso. La pagina aggiornata della Solana Foundation indica Votor attivo in mainnet dal 21 ottobre, nell’epoca 1064. Rotor è una fase successiva. Il riferimento a circa 150 millisecondi riguarda un obiettivo di finalità, non una durata garantita per ogni operazione.
Per capire l’aggiornamento bisogna separare tre domande: quando una transazione diventa definitiva, come viaggiano i dati e quale stato mostra il proprio servizio. Confondere questi livelli porta a conclusioni sbagliate su velocità, sicurezza e lavoro necessario per aggiornare un’applicazione.
Alpenglow di Solana: consenso, non un nuovo wallet
Il consenso serve a stabilire quali blocchi entrano nella storia condivisa della rete. Non è la schermata che permette di firmare un pagamento e non è una promessa di rendimento per SOL. L’utilità del cambiamento va valutata sul funzionamento dell’infrastruttura, separatamente dalle aspettative sul token.
Un utente che attende l’esito di un pagamento e un operatore che raccoglie dati dai validatori osservano parti differenti dello stesso processo. Il primo vuole sapere se può considerare conclusa l’operazione; il secondo deve capire quale informazione riceve, da quale nodo e con quale ritardo. Un unico numero non risponde a entrambe le domande.
Votor e Rotor hanno compiti e tempi diversi
La specifica SIMD-0326 distingue il voto Votor dalla futura diffusione dei dati Rotor. Quest’ultima prende il posto di Turbine: descriverla come un semplice rimpiazzo di Proof of History era impreciso. Non bisogna attribuire alla fase già distribuita ogni caratteristica del progetto completo.
| Elemento | Come leggerlo |
|---|---|
| Votor | Voto e finalizzazione; fase indicata come attiva dalla Foundation |
| Rotor | Diffusione dei dati al posto di Turbine; fase successiva |
| 150 ms | Riferimento alla finalità, non garanzia per il singolo pagamento |
| 80% / 60% | Soglie di stake dei percorsi di voto, non percentuali di utenti |
Le soglie corrette sono 80% e 60%
SIMD-0326 descrive finalizzazione rapida dopo un round con l’80% dello stake e un percorso a due round con il 60%. Il 70% riportato nella vecchia versione inglese non era coerente con la specifica. Queste percentuali riguardano il peso dei voti, non il numero di wallet o di persone collegate.
Un esempio aiuta a leggere il dato senza trasformarlo in una simulazione: contare quante macchine rispondono non basta, se i loro voti hanno pesi diversi. Per valutare una soglia servono la stessa unità di misura e le condizioni previste dal protocollo. Non si può dedurre la sicurezza di una rete da un semplice conteggio di nodi online.
Perché 150 ms non significa sempre 150 ms sullo schermo
La documentazione Anza distingue la finalizzazione dal momento in cui un nodo riceve l’informazione: alcuni percorsi aggiungono attesa. Una misurazione dell’applicazione comprende anche invio, rete, servizio RPC e aggiornamento dell’interfaccia. Occorre quindi dichiarare dove parte e dove finisce il cronometro.
Finalità, intervallo dei blocchi e throughput restano misure diverse. Il confronto tra due servizi dovrebbe usare lo stesso punto iniziale, lo stesso stato finale e condizioni confrontabili. Confrontare una previsione di protocollo con il tempo percepito da un utente remoto produce una classifica apparente, non un test ripetibile.
Cosa controllare per applicazioni e validatori
Anza distingue processed dai livelli successivi: sotto Alpenglow, confirmed e finalized descrivono lo stesso stato di finalizzazione. Un messaggio che dice soltanto “ricevuto” non deve quindi essere presentato come pagamento definitivo. Per applicare questa distinzione occorre sapere quale stato restituisce il proprio servizio, non interpretare il colore di una spunta come specifica tecnica.
Per chi sviluppa, il primo passo è inventariare le dipendenze: lettura dello stato, flussi di blocchi, conteggio delle transazioni e assunzioni sui tempi. La guida Anza ai commitment è il riferimento per interpretare gli stati. Non conviene copiare un’etichetta nell’interfaccia senza sapere a quale evento corrisponde.
Per un operatore contano inoltre versione compatibile, account di voto e costi effettivi. La guida agli account di voto va controllata nella versione applicabile, invece di assumere che un valore letto in una proposta storica sia ancora quello operativo. Questa pagina non sostituisce una procedura di migrazione né contiene comandi da eseguire alla cieca.
Limiti: consenso veloce non significa assenza di rischio
Finalizzare più rapidamente non dimostra che uno smart contract sia sicuro, che un ordine venga eseguito al prezzo desiderato o che un destinatario sia corretto. Sono problemi diversi. Un’applicazione deve continuare a gestire errori, risultati non disponibili e verifiche dell’operazione senza confondere reattività e affidabilità complessiva.
Il confronto tra Solana ed Ethereum offre il contesto delle architetture. Le transazioni Solana da 4.096 byte riguardano invece un altro livello: capacità e formato delle transazioni non sono sinonimi del meccanismo di consenso.
La lettura corretta di Alpenglow è quindi concreta: distinguere la fase attiva da quella futura, applicare le soglie corrette e misurare il risultato effettivamente utile. Questa revisione corregge il vecchio testo; non presenta benchmark della redazione, garanzie di disponibilità o previsioni sul prezzo di SOL.
