Solana porta l'aggiornamento del consenso Alpenglow sul testnet pubblico

Solana ha avviato il rilascio del suo aggiornamento del consenso Alpenglow sul testnet pubblico, una tappa che apre la modifica alla più ampia comunità di validatori della rete, in vista di una riprogettazione pensata per ridurre la finalità delle transazioni a una frazione della durata attuale.

Anza, la società di sviluppo dietro il client validator Agave, ha rilasciato Agave v4.3.0 il 18 settembre come build stabile che ritiene adatta a testnet, devnet e mainnet beta. Dopo aver prima distribuito la versione agli operatori che controllano il 10% e poi il 25% del SOL in staking, Anza ha invitato tutti i validatori della mainnet a eseguire la versione il 21 settembre. L'aggiornamento è tra i più rilevanti per Solana degli ultimi anni: mira a ridurre la finalità da circa 12,8 secondi a circa 150 millisecondi.

Come cambia il modello di consenso

La finalità è il punto oltre il quale una transazione non può più essere annullata. È la condizione che le borse attendono prima di accreditare i depositi e che i bridge attendono prima di sbloccare i fondi. Ridurre quell'attesa da secondi a millisecondi accorcia direttamente il fermo sui depositi e sui trasferimenti cross-chain.

Solana raggiunge attualmente la finalità tramite TowerBFT, che accumula i voti dei validatori registrati on-chain su 32 slot prima che un blocco sia considerato definitivo. Alpenglow sostituisce quel meccanismo con Votor, un protocollo in cui i validatori trasmettono i voti direttamente tra loro e possono concordare un blocco entro uno o due round. L'eliminazione della lunga catena di votazione on-chain, responsabile della maggior parte del ritardo, riduce l'attesa a circa 150 millisecondi.

Un percorso graduale verso la rete principale

Il nuovo codice è in esecuzione da oltre quattro mesi su una rete separata e più piccola, predisposta appositamente per l'aggiornamento. Portarlo sul testnet pubblico di Solana, dove i token non hanno valore reale, verifica se l'intero insieme di computer e servizi che già gestiscono la chain può migrare in modo coordinato.

Il 28 settembre figura nel calendario di Anza come data provvisoria per l'attivazione funzionalità di Agave 4.3 sulla rete principale. Anza non ha confermato un lancio, e il suo tracker segnava ancora come in sospeso lo stesso passaggio al testnet mercoledì mattina. Da qui in poi, gli indicatori da seguire sono la rimozione dello stato di sospeso dal tracker e l'eventuale conferma da parte di Anza del 28 settembre come data di attivazione.

Disponibilità dei client e cambiamenti per gli utenti

Le applicazioni continueranno a elaborare le transazioni come fanno ora, e i possessori non dovranno cambiare wallet né il modo in cui spostano i fondi.

La prima migrazione di Alpenglow sarà interamente gestita tramite Agave, poiché Firedancer e Frankendancer, i due client validator alternativi sviluppati da Jump Crypto, non supportano ancora il test. Queste alternative esistono per ridurre la dipendenza di Solana da un'unica codebase, così che un bug in Agave non colpisca tutti i validatori contemporaneamente. La loro assenza lascia la prima migrazione concentrata su una sola codebase — proprio la dipendenza che i client alternativi erano stati creati per alleviare.

Il cambiamento segue una serie di aggiornamenti di rete costanti, che vanno da una dimensione massima di transazione più ampia a tempi di slot più rapidi sul testnet. Alpenglow va più in profondità: invece di regolare limiti o tempistiche, sostituisce il meccanismo con cui la rete finalizza i blocchi.