Si prevede che Solana trasferisca Alpenglow, descritto da Anza come il più grande aggiornamento di consenso della sua storia, sulla testnet pubblica questa settimana.
In un post pubblicato martedì, Brennan Watt, CEO di Anza, ha lasciato intendere che l’aggiornamento sarebbe stato attivato sulla testnet nell’Epoch 1042, previsto tra meno di 2 giorni secondo i dati di Solana Beach.
Questa mossa segna il primo passo formale di una migrazione che porterà alla sostituzione di TowerBFT, l’attuale sistema di consenso di Solana, con Alpenglow. L’aggiornamento è già in esecuzione da oltre 4 mesi su un cluster dedicato della comunità, dove gli operatori hanno ripetutamente simulato il processo di migrazione.
Da 12,8 secondi a 150 millisecondi
Il cambiamento principale di Alpenglow riguarda la velocità con cui Solana raggiunge la finalità, ovvero il momento in cui la rete considera una transazione irreversibile secondo le proprie regole di consenso.
Anza stima che Alpenglow possa ridurre il tempo di finalizzazione da circa 12,8 secondi a circa 100-150 millisecondi. Ciò potrebbe cambiare il modo in cui gli exchange, i bridge e i commercianti gestiscono le transazioni su Solana, poiché questi servizi spesso attendono la finalizzazione prima di accreditare i depositi, sbloccare gli asset o confermare i pagamenti.
L’aggiornamento sostituisce TowerBFT con Votor. Anziché registrare i voti di consenso come transazioni sulla blockchain, i validatori si scambiano i voti direttamente. Votor può finalizzare un blocco attraverso uno dei due percorsi di votazione. Un percorso si completa dopo un round quando partecipa l’80% dello stake, mentre l’altro prevede due round quando la partecipazione raggiunge il 60%. L’eliminazione della votazione on-chain libera inoltre lo spazio di blocco attualmente occupato dal traffico di consenso.
Come Solana cambierà il meccanismo di consenso senza interrompere il servizio
Alpenglow non richiede una nuova catena, un riavvio della rete o una migrazione dei token. Solana cambierà il meccanismo di consenso mentre la rete live continua a funzionare.
La migrazione si svolge in quattro fasi. Innanzitutto, il gate della funzionalità Alpenglow si attiva al confine di un’epoca. Nulla viene migrato immediatamente.
Successivamente, 5.000 slot dopo, si raggiunge il confine di migrazione. I blocchi smettono di trasportare le transazioni degli utenti e contengono solo voti. Ciò crea un punto di rollback sicuro perché i validatori possono scartare i blocchi successivi al confine senza perdere le transazioni degli utenti.
I validatori continuano a eseguire TowerBFT finché un blocco non riceve voti dall’82% dello stake. L’ultimo antenato di quel blocco prima del limite diventa il blocco genesi di Alpenglow.
I validatori firmano quindi un voto di genesi BLS. Una volta che l’82% dello stake ha contribuito, si forma il certificato di genesi.
Infine, i validatori eseguono il rollback di tutto ciò che segue il blocco genesi, cedono il consenso a Votor e riprendono l’elaborazione delle transazioni degli utenti. TowerBFT si ritira, mentre Alpenglow subentra a partire dal blocco genesi in poi.
Agave 4.3 guida il primo test
I validatori che partecipano alla migrazione della testnet devono utilizzare Agave v4.3.0. Il 21 settembre Anza ha raccomandato Agave v4.3 a tutti i validatori della Mainnet-beta, dopo un'implementazione graduale che ha inizialmente coinvolto gli operatori rappresentativi del 10% dello stake e successivamente del 25%.
Il programma attuale di Anza indica il 28 settembre come data provvisoria per l’attivazione delle funzionalità incluse in Agave 4.3 sulla Mainnet-beta. Tuttavia, ciò non rappresenta una data confermata per il lancio della mainnet di Alpenglow.
Firedancer non supporta la migrazione ad Alpenglow
Firedancer e Frankendancer attualmente non supportano la migrazione ad Alpenglow. Gli operatori della testnet che utilizzano uno di questi client devono passare ad Agave v4.3.0 prima che il feature gate venga attivato.
La situazione ha inoltre sollevato preoccupazioni riguardo alla diversità dei client. Mike MacCana, responsabile delle relazioni con gli sviluppatori presso QuickNode, ha espresso preoccupazione per il fatto che la rete dipenda da un unico client durante la migrazione.
Il team di Firedancer intende terminare il supporto a Frankendancer quando Alpenglow raggiungerà la mainnet di Solana, previsto con la v4.3, citando l’onere in termini di manutenzione e sicurezza. Il team si concentrerà invece sul client Firedancer completo.
Timothy Garcia, responsabile delle relazioni con i validatori della Fondazione Solana, ha descritto l’attivazione della testnet come la fine di un’era per Frankendancer, pur riconoscendo al client di aver avuto un impatto significativo sull’ecosistema.
Cosa succederà ora
Dopo la testnet, Alpenglow passerà attraverso la Devnet prima di raggiungere la Mainnet-beta. Ogni cluster dovrà eseguire lo stesso processo di migrazione prima che abbia inizio la fase successiva.
L’aggiornamento rimane inoltre separato dai miglioramenti apportati da Solana al tempo di slot. Il tempo di slot di Solana è recentemente sceso a 250 millisecondi con SIMD-0525, mentre una fase futura punta a raggiungere i 200 millisecondi.
Alpenglow, invece, modifica la velocità con cui i validatori raggiungono la finalità. Se la migrazione avrà esito positivo in ogni fase, Solana si dirigerà verso una rete in cui la finalità dei blocchi potrà avvenire in circa 150 millisecondi senza modificare il modo in cui gli utenti inviano le transazioni o le applicazioni le eseguono.
Per saperne di più su SolanaFloor
X aggiunge un pulsante "Trade" ai Cashtag, rendendo $BTC e $SOL accessibili con un solo clic per gli utenti statunitensi
Cryptopunks, Boogles e zkSnarks registrano milioni di volume di trading mentre i mercati NFT si risvegliano
Come fare trading su Solana come un professionista
