Punti chiave
- Solana ha attivato Alpenglow sulla testnet il 24 settembre e sulla devnet il 25 settembre, sostituendo il suo vecchio sistema TowerBFT con Votor.
- Alpenglow mira a ridurre il tempo di finalizzazione di Solana da 12,8 secondi a soli 100-150 millisecondi.
- Anza non ha ancora fissato una data di lancio sulla mainnet, mentre Firedancer e Frankendancer devono ancora aggiungere il supporto per Votor.
Solana ritira il suo vecchio motore di consenso su due reti pubbliche
Solana ha appena realizzato qualcosa che ai suoi esordi sarebbe sembrato fantascienza. La sua revisione del consenso Alpenglow è ora operativa su due reti di test pubbliche, con un design mirato a garantire un regolamento irreversibile in circa un decimo di secondo.
Si tratta di un risultato ben lontano dai circa 12,8 secondi che la rete impiega attualmente per raggiungere la finalità economica. Il cofondatore Anatoly Yakovenko ha celebrato il conto alla rovescia sulla devnet con cinque parole: “Non siete pronti per questo”. Eppure la vera prova deve ancora arrivare, e il sistema responsabile della sicurezza di miliardi in asset non ha ancora effettuato il passaggio.
TowerBFT viene disattivato dopo un conto alla rovescia di 17 minuti
Anza, l’azienda dietro il client validatore Agave di Solana, ha attivato Alpenglow sulla testnet pubblica il 24 settembre. Dopo un conto alla rovescia di 5.000 slot durato circa 17 minuti, la transizione si è conclusa allo slot 444.625.255. L’ultimo blocco TowerBFT rappresentava l’82% dello stake. È seguito un blocco genesi di Alpenglow, che ha dismesso il precedente sistema di consenso su quel cluster e ha affidato i compiti di finalizzazione a Votor.
Anche Devnet si è unita all’iniziativa il 25 settembre, completando la propria transizione allo slot 504.148.999. Non si è trattato, del resto, di esperimenti del tutto nuovi. Un cluster dedicato della comunità ha provato il cambiamento sin da maggio, compreso un primo tentativo fallito che ha richiesto un riavvio. Il protocollo di base, SIMD-0326, ha ricevuto l’approvazione della governance nel settembre 2025 con il 98,27% dei voti partecipanti.
Da 12,8 secondi a un battito di ciglia
È qui che le cose si fanno interessanti. Il sistema attuale di Solana richiede ai validatori di inviare i voti come transazioni on-chain e di attendere una catena di conferma di 32 slot. Secondo quanto riferito, tali transazioni di voto rappresentano circa il 75% del volume totale delle transazioni di rete. Votor sposta la votazione off-chain, raccogliendo invece i voti peer-to-peer in certificati BLS compatti. Due percorsi di conferma operano simultaneamente.
- Percorso veloce: l’80% dello stake concorda in un unico round, con l’obiettivo di 100 millisecondi.
- Percorso di riserva: il 60% raggiunge l’accordo inizialmente, seguito da un altro round, con un obiettivo di 150 millisecondi.
Il compromesso è un modello di sicurezza rivisto che tiene conto di un 20% di stake ostile e di un altro 20% offline. Rotor, il sostituto previsto per la propagazione dei blocchi di Turbine, arriverà in seguito. La Solana Virtual Machine, il formato delle transazioni, i programmi e le commissioni rimangono invariati. Gli utenti dei wallet non dovranno effettuare alcuna migrazione.
Una finalizzazione più rapida comporta un problema per gli exchange
La dichiarazione di Yakovenko comporta un’implicazione pratica. Anche se il protocollo Solana regola le transazioni in 100 millisecondi, gli exchange, i bridge e i custodi potrebbero comunque elaborare i depositi utilizzando sistemi progettati per periodi di conferma notevolmente più lunghi. C’è un altro aspetto da considerare. La rimozione dei voti dei validatori dai blocchi farà diminuire il numero di transazioni riportate, anche se l’attività effettiva degli utenti non è cambiata.
Anza avverte i fornitori di infrastrutture di prepararsi. Gli indicizzatori dovranno distinguere le banche candidate concorrenti fino alla certificazione definitiva, mentre i consumatori di Geyser e gRPC riceveranno un nuovo identificatore bank_id. Ilan Gitter della Fondazione Solana ha citato oltre 25.000 transazioni al secondo con una finalità di 150 millisecondi sul cluster della testnet dopo l’attivazione. Una cifra notevole, certamente, ma misurata su un cluster di test piuttosto che sulla mainnet.
La mainnet ha ancora alcuni ostacoli da superare
Le prestazioni pubblicizzate di 100-150 millisecondi derivano da simulazioni e test su scala ridotta. I risultati costanti su un set completo di validatori pubblici che gestiscono l’attività di mercato in tempo reale rimangono da dimostrare. La diversità dei client rappresenta un’ulteriore complicazione. Firedancer e Frankendancer non hanno ancora implementato Votor, lasciando le prime transazioni pubbliche dipendenti da Agave 4.3.
Anza desidera che gli sviluppatori testino le integrazioni durante un periodo di osservazione prima di qualsiasi migrazione alla mainnet beta. Non è stata annunciata alcuna data definitiva di attivazione. Il 28 settembre compare nei programmi di Agave come finestra temporale per la ripresa delle attivazioni delle funzionalità, non come data confermata per il lancio di Alpenglow. Per Solana, la proposta è abbastanza chiara. Le transazioni che attualmente richiedono alcuni secondi per essere finalizzate potrebbero alla fine essere regolate in millisecondi. Se gli exchange, i custodi e i fornitori di infrastrutture che gestiscono tali transazioni saranno in grado di tenere il passo è tutta un’altra questione.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
