La prossima grande revisione del consenso di Solana, Alpenglow, è prevista per iniziare il rollout sulla mainnet il 21 ottobre 2026 e potrebbe produrre un effetto collaterale che pochi osservatori casuali si aspettano: un brusco, puramente statistico, calo del conteggio delle transazioni riportato dalla rete.

Secondo la documentazione di Alpenglow della Solana Foundation, l'epoca 1064 dovrebbe iniziare approssimativamente alle 15:00 UTC del 21 ottobre. Poiché i tempi delle epoche possono variare, quell'orario è una stima e non un momento di attivazione fisso. Le epoche sono lunghe sequenze di slot che strutturano il ledger di Solana, quindi i loro confini cambiano con la produzione effettiva dei blocchi: utile saperlo per chiunque segua il rollout in tempo reale. TowerBFT rimarrà in vigore per i primi 5.000 slot dell'epoca, circa 18 minuti, dopo i quali il consenso Alpenglow subentrerà allo slot 459.653.000.

Il rilascio sulla mainnet è incentrato su Votor, il nuovo protocollo di voto e finalità di Alpenglow, che punta a una finalità dei blocchi di circa 150 millisecondi, rispetto ai circa 12,8 secondi dell'attuale sistema TowerBFT. Rotor, un componente separato di Alpenglow progettato per sostituire il sistema di propagazione dei blocchi Turbine di Solana, è previsto per un rilascio successivo e non ha ancora una data per la mainnet. L'approccio graduale mantiene l'attivazione di ottobre concentrata esclusivamente sulle modifiche al consenso.

Un Aggiornamento Diverso a Seconda di Chi Osserva

La distinzione è importante. Alpenglow è progettato per lasciare intatta l'esperienza ordinaria del portafoglio, mentre l'infrastruttura che produce, trasmette e interpreta i dati di Solana cambierà in modo sostanziale. Non ci si aspetta che gli utenti quotidiani inviino transazioni in modo diverso; il lavoro di adeguamento ricade sugli operatori dei validator, sui fornitori di infrastruttura e sulle piattaforme di dati.

Votor Sostituisce i Voti On-Chain con i Certificati dei Validator

Il consenso è il processo con cui i validator di una blockchain concordano quali blocchi sono validi. Con l'attuale consenso TowerBFT di Solana, i validator esprimono i voti come transazioni on-chain. Quei voti si accumulano su 32 slot prima che un blocco raggiunga la finalità, creando l'attesa di circa 12,8 secondi per la più forte garanzia di regolamento.

Votor rimuove quei voti dal blocco stesso. I validator li inviano direttamente gli uni agli altri e li aggregano in certificati, consentendo a un blocco di raggiungere la finalità in una o due tornate di voto.

L'obiettivo dei 150 millisecondi si riferisce al tempo necessario affinché una transazione diventi finale, cioè irreversibile. Non significa che Solana produrrà un nuovo blocco ogni 150 millisecondi; i tempi degli slot sono stati ridotti separatamente a 200 millisecondi in ottobre.

Per i servizi che attendono la finalità prima di accreditare un deposito, rilasciare merci o completare un trasferimento, la modifica potrebbe eliminare gran parte del ritardo creato dal processo di consenso stesso di Solana. Non elimina i ritardi imposti dai controlli di rischio degli exchange, dai bridge, dai fornitori di pagamento o da altre chain. Il beneficio è più rilevante nei flussi di lavoro in cui una parte attende una garanzia di regolamento più forte prima di completare l'altra parte della transazione. Lo strumento di escrow delivery-versus-payment di Solana è un esempio di infrastruttura che potrebbe beneficiare di una finalità più rapida senza richiedere agli utenti di cambiare il modo in cui inviano le transazioni.

La Rimozione dei Voti Ridisegnerà i Dati delle Transazioni di Solana da un Giorno all'Altro

La modifica più visibile per gli analisti potrebbe non essere affatto la finalità. Le transazioni di voto non compariranno più nei blocchi di Solana con Votor. Poiché quei voti sono stati registrati nei blocchi come qualsiasi altra transazione, i dashboard che conteggiano tutto ciò che un blocco contiene li hanno da sempre inclusi nei dati principali di throughput e, dato che i voti hanno rappresentato una quota elevata delle transazioni conteggiate nei blocchi, il totale dei conteggi delle transazioni e i valori di TPS possono crollare bruscamente dopo l'attivazione.

Si tratterebbe di una modifica contabile, non di una prova che Solana abbia improvvisamente perso utenti o domanda per le applicazioni. Un dashboard che continua a confrontare i totali post-Alpenglow con le cifre precedenti all'aggiornamento senza adeguare la propria base di riferimento potrebbe riportare falsamente un crollo dell'attività di rete.

Prima di concludere che «le transazioni di Solana sono calate, quindi l'utilizzo di Solana è calato» dopo il 21 ottobre, verificare se il dashboard include i voti dei validator precedenti all'aggiornamento nella propria base storica. In tal caso, il conteggio principale delle transazioni non è più direttamente confrontabile. Le st indicazioni di Solana chiedono agli indicizzatori e ai dashboard di throughput di ricalibrare i propri dati, e gli strumenti che in precedenza misuravano la partecipazione analizzando le istruzioni del Vote Program devono passare ai certificati contenuti nel footer dei blocchi di Alpenglow.

Usare un Paniere di Misure di Attività Dopo l'Aggiornamento

Nessuna singola metrica può descrivere la domanda di rete. Una volta che le transazioni di voto scompariranno, la lettura più corretta combinerà più misure anziché trattare il TPS totale come un verdetto a sé stante:

• Transazioni non di voto: misura diretta delle transazioni generate al di fuori della votazione dei validator.
• Pagatori di commissioni attivi: indicatore migliore dell'ampiezza della partecipazione rispetto ai soli totali grezzi delle transazioni.
• Conteggio e valore dei trasferimenti di stablecoin: utili per monitorare l'attività di pagamento e regolamento.
• Volume DEX e trader unici: insieme, forniscono più contesto del solo volume.
• Ricavi da commissioni: utili insieme alle metriche degli utenti, pur potendo variare anche con le condizioni delle commissioni e l'intensità degli scambi.

Questo approccio rende i confronti post-aggiornamento più onesti. Se il TPS totale cala mentre le transazioni non di voto, i pagatori di commissioni attivi e il volume delle applicazioni restano stabili, la rete ha cambiato la propria contabilità, non necessariamente la propria domanda.

Cosa Mostrerà se il Rollout Ha Funzionato

Il primo test è la finalità effettiva. La rete deve dimostrare che i blocchi raggiungono la finalità vicino all'obiettivo dichiarato, senza instabilità significative o un aumento degli slot saltati.

Il secondo è la prontezza operativa. I validator devono migrare verso client supportati basati su Agave; Firedancer e Frankendancer non sono supportati durante la transizione. Anche gli indicizzatori e gli utenti di RPC/Geyser devono gestire il nuovo campo bank_id, perché uno slot può contenere più di un blocco candidato.

Il terzo è la continuità dei dati. Explorer, piattaforme di analisi e report dei media devono distinguere tra un minor numero di voti dei validator e una domanda applicativa più debole prima di trarre conclusioni dai grafici delle transazioni post-aggiornamento di Solana.

Finalità Più Rapida e una Base TPS Obsoleta

La promessa immediata di Alpenglow è una finalità molto più rapida senza cambiare il modo in cui gli utenti ordinari inviano le transazioni. La sua conseguenza meno evidente è che le familiari statistiche di attività di Solana dovranno essere azzerate una volta che i voti dei validator spariranno dai blocchi. Dopo il 21 ottobre, un calo del conteggio principale delle transazioni dovrebbe essere trattato prima di tutto come una questione di misurazione. Solo un calo simultaneo dell'attività non di voto, dei pagatori di commissioni attivi e dell'utilizzo a livello applicativo supporterebbe la conclusione che la domanda stessa si sia indebolita.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria o di investimento. I tempi di attivazione sulla mainnet e le prestazioni dipendono dalle condizioni della rete e dalla prontezza dell'implementazionen
Fonte: Coindoo