Solana si prepara a mettere alla prova un obiettivo di finalità notevolmente più rapido sulla sua testnet pubblica. Anza, lo studio di sviluppo dietro il client validator Agave, ha inserito Alpenglow sotto la voce "Pending Testnet Activation" nel suo ufficiale tracker dei feature gate, aggiornato il 22 settembre. L'inserimento significa che la funzionalità attende ora l'attivazione sulla testnet pubblica, senza che sia stata finora pubblicata alcuna epoch di attivazione.

La voce identifica la funzionalità come "SIMD-0326: Alpenglow: new consensus algorithm" e la assegna ad Agave v4.3.0. I campi relativi all'epoch di attivazione sulla testnet e alla data di attivazione rimangono vuoti. Agave v4.3.0 è inoltre indicata come il prossimo version floor atteso sulla testnet — ovvero la release software più datata che i validatori possono eseguire restando compatibili con quella rete. Anza descrive il proprio calendario come provvisorio, quindi l'inserimento non costituisce una data di attivazione garantita.

Cosa misura realmente l'obiettivo dei 150ms

Secondo la documentazione ufficiale degli upgrade di Solana, Alpenglow mira a ridurre la finalità da circa 12, secondi a circa 150 millisecondi. Se raggiunto, ciò renderebbe la finalità circa 85 volte più veloce.

La finalità è il punto in cui i validatori hanno raggiunto un accordo sufficiente perché un blocco sia considerato irreversibile. Non è semplicemente il momento in cui una transazione appare per la prima volta sulla rete. Oggi un'applicazione può vedere una transazione Solana come "confirmed" prima che riceva lo stato più forte di "finalized" della rete. Alpenglow è progettato per far convergere queste due fasi, poiché un certificato di finalizzazione potrebbe arrivare in un lasso di tempo simile a quello oggi associato a una conferma iniziale.

Tre orologi possono governare un solo pagamento

• Esecuzione: la transazione viene eseguita e appare inizialmente in un blocco.
• Finalità del protocollo: i validatori stabiliscono che il blocco non deve più essere annullato.
• Rilascio del servizio: un exchange, un bridge o un merchant decide quando accreditare il deposito, sbloccare gli asset o completare l'ordine.

Alpenglow accorcerebbe il secondo orologio. Ciascuna azienda continuerebbe a controllare il terzo, il che significa che un obiettivo di protocollo di 150ms non garantirebbe che ogni pagamento rivolto al cliente si conclusa in 150 millisecondi.

Come Alpenglow modifica il consenso di Solana

La prima fase di Alpenglow introduce Votor, un sostituto del processo di voto utilizzato dall'attuale sistema di consenso TowerBFT di Solana. Attualmente i validatori inviano i voti come transazioni e costruiscono la finalità su una sequenza di slot. Con Votor, si scambierebbero i voti direttamente e li combinerebbero in certificati che attestano che una quota di stake sufficiente ha approvato un blocco.

Un blocco potrebbe finalizzarsi dopo un solo round di voto quando la partecipazione arriva rapidamente. Un secondo round sarebbe disponibile quando le condizioni di rete impediscono la via più rapida.

🚨 Testnet operators: Alpenglow activation on testnet only runs on Agave. If you're on Firedancer or Frankendancer today, switch over to an Agave node before the migration window so your stake counts toward activation. Details in the thread below 👇

— Anza (@anza_xyz) September 22, 2026

L'upgrade non modifica il modo in cui gli smart contract vengono eseguiti, come vengono calcolati i saldi o come gli utenti inviano le normali transazioni. Modifica il modo in cui i validatori concordano sul fatto che il blocco risultante sia definitivo.

Solana ha anche modificato il contenuto possibile delle transazioni. Il recente aumento della dimensione massima delle transazioni ha creato più spazio per firme, istruzioni e proof. Quell'upgrade cambia ciò che può entrare in una transazione; Alpenglow cambia la velocità con cui la rete può considerarla irreversibile.

Dove una finalità più rapida potrebbe fare la differenza

• Exchange: una piattaforma potrebbe accreditare prima un deposito Solana, sebbene i controlli di identità, lo screening dei wallet e i controlli intern di rischio possano comunque ritardare l'accesso ai fondi.
• Bridge: un bridge potrebbe verificare prima il lato Solana di un trasferimento, ma i suoi relayer e la blockchain di destinazione continuerebbero a operare su tempistiche separate.
• Merchant: se la finalità della blockchain è la parte più lenta del checkout, un processore di pagamenti potrebbe confermare prima un pagamento irreversibile e iniziare a evadere l'ordine.

Il miglioramento sarebbe più visibile dove un servizio attende attualmente la garanzia di settlement più forte di Solana. Avrebbe minor effetto quando i controlli di conformità, un'altra blockchain o un sistema di pagamento offchain causano già il ritardo maggiore.

L'attivazione tracciata supporta attualmente solo Agave

Solana può essere gestita tramite client validator sviluppati in modo indipendente. Agave è mantenuto da Anza, mentre Firedancer e Frankendancer offrono implementazioni alternative. L'attuale voce di Alpenglow assegna la funzionalità ad Agave v4.3.0 e contrassegna sia Firedancer sia Frankendancer come non supportati.

La voce descrive il feature gate in attesa sulla testnet; non stabilisce quali client supporteranno Alpenglow al momento in cui verrà valutata un'eventuale attivazione sulla mainnet. Nel tracker non compare alcuna data per l'aggiunta del supporto a uno dei due client alternativi. La loro prontezza rimane pertanto una questione aperta di rollout, piuttosto che una prova di un'esclusione permanente.

Cosa dovrà dimostrare l'attivazione sulla testnet

• Migrazione: i validatori possono passare da un sistema di consenso all'altro senza interrompere la produzione di blocchi?
• Velocità osservata: la finalità misurata si avvicina ai 150ms invece di limitarsi a raggiungere l'obiettivo in test controllati?
• Ritardi di rete: la finalità resta affidabile quando i validatori o le connessioni internet rispondono lentamente?
• Consegna dell'infrastruttura: i fornitori RPC e gli indexer ricevono i nuovi dati di finalità in modo rapido e coerente?
• Prontezza dei client: quando potranno supportare il nuovo sistema di consenso ulteriori implementazioni validator?

La cifra di 150ms è un'aspettativa, non una costante. La documentazione di Solana afferma che la finalità può variare in base alla distribuzione dello stake e al fatto che un blocco richieda uno o due round di voto. Alcune infrastrutture potrebbero inoltre venire a conoscenza della finalizzazione di un blocco più tardi rispetto ai validatori che producono direttamente il certificato.

Anche un risultato positivo sulla testnet non garantirebbe prestazioni identiche sulla mainnet. La partecipazione dei validatori, la distribuzione dello stake e il traffico di rete possono differire tra i due ambienti.

Un'epoch di attivazione avvierà la prova reale

Il prossimo traguardo verificabile sarà la pubblicazione di un'epoch di attivazione o un avviso ufficiale dell'apertura del feature gate. I dati pubblici della testnet potranno quindi mostrare quanto Alpenglow si avvicini al proprio obiettivo e quanto rapidamente il segnale di finalità risultante raggiunga wallet e infrastrutture.

Per le aziende di, un accordo più rapido tra i validatori è utile solo se ricevono tali informazioni abbastanza presto da modificare i tempi di sblocco dei fondi. L'epoch di attivazione avvierà tale prova; da sola non risolverà la questione.

Questo articolo è fornito a solo scopo informativo. I calendari di rete, il supporto dei client validator e la finalità misurata possono cambiare con l'avanzare dei test.

Fonte: Solana Prepares to Test 150ms Finality — Coindoo