Solana Gli sviluppatori core hanno introdotto una revisione del consenso chiamata "Alpenglow" nel processo formale di governance della blockchain, proponendo di sostituire l'attuale sistema TowerBFT della rete con un'architettura riprogettata che promette tempi di finalizzazione dei blocchi di 100-150 millisecondi. La proposta, scritta da Quentin Kniep, Kobi Sliwinski e Roger Wattenhofer, rappresenta ciò che descrivono come "una revisione importante del protocollo di consenso core di Solana" che eliminerebbe i meccanismi esistenti di Proof-of-History e TowerBFT.
Cosa sapere:
- Alpenglow introduce il protocollo Votor, spostando il voto dei validatori fuori catena per ottenere la finalità del blocco sotto il secondo e ridurre la larghezza di banda della rete
- La proposta richiede una quota di Ticket di Ammissione dei Validatori di 1.6 SOL per epoca per mantenere barriere economiche comparabili ai costi di voto attuali sulla catena
- Il voto della comunità avviene tra le epoche 840-842, richiedendo una supermaggioranza di due terzi per l'approvazione con i validatori che utilizzano i token di voto reclamabili
Cronologia di Governance e Meccaniche di Voto
Il quadro di governance stabilisce un programma di implementazione in tre fasi che si estende su più epoche. Le discussioni si svolgono tra le epoche 833-838, seguite dalla cattura della ponderazione di quota nell'epoca 839, e dai voti vincolanti tra le epoche 840-842 utilizzando token di voto reclamabili distribuiti agli account "Sì", "No" o "Astieni" designati. Con Solana attualmente nell'epoca 834, la finestra di discussione rimane attiva mentre il periodo di voto si avvicina in diverse epoche.
L'approvazione richiede una soglia di supermaggioranza in cui i voti favorevoli devono costituire almeno due terzi dei voti combinati Sì e No, insieme a un quorum del 33% che include le astensioni.
I token di voto saranno distribuiti tramite un sistema adattato di distributore di Merkle, consentendo ai validatori di indirizzare i token verso i loro account preferiti durante la finestra di epoca designata. La fondazione pubblicherà le ponderazioni di quota e uno script di conteggio pubblico per la verifica indipendente dei risultati.
Architettura Tecnica del Sistema Alpenglow
La proposta si concentra su Votor, un protocollo di finalità ad voto diretto, leader-pipelined che cambia fondamentalmente l'approccio al consenso di Solana. Invece di elaborare i voti come transazioni sulla catena tramite reti gossip pesanti, Alpenglow passa allo scambio di voti fuori catena con aggregazione locale delle firme. I validatori votano per notarizzare o saltare i blocchi, mentre i leader aggregano i voti otto slot dopo e presentano prove compatte alla rete.
Questo cambiamento architettonico supporta quello che gli sviluppatori chiamano un modello di "20+20" vitalità, progettato per tollerare fino al 20% di validatori avversari e al 20% di validatori non responsivi senza interrompere il progresso della rete.
Il sistema mira a ridurre significativamente la latenza riducendo al contempo i requisiti di larghezza di banda sulla rete. Secondo gli autori della proposta, "Alpenglow consente una latenza molto più bassa, una tolleranza ai guasti migliorata e una maggiore efficienza del protocollo in generale."
L'aggiornamento creerebbe cambiamenti visibili a livello di client, sostituendo la conferma ottimistica con la finalità attuale in tempi inferiori al secondo. Gli sviluppatori affermano che questo approccio porta le latenze di conferma in linea con le aspettative degli utenti Web2 rafforzando al contempo le garanzie di sicurezza che risultavano difficili da formalizzare sotto l'attuale sistema TowerBFT.
Ristrutturazione Economica e Incentivi ai Validatori
Il passaggio dei voti fuori catena richiede cambiamenti significativi all'economia dei validatori all'interno dell'ecosistema Solana. La proposta introduce un sistema di Ticket di Ammissione dei Validatori che richiede una quota fissa di 1.6 SOL per epoca che viene bruciata per mantenere barriere economiche approssimativamente equivalenti alle strutture di costo di voto attuali sulla catena. Questo importo rappresenta circa l'80% dei costi di voto esistenti, garantendo che nessun operatore di validatori sperimenti condizioni economiche peggiori durante la transizione.
Con Alpenglow, i validatori devono esprimere esattamente un voto valido per slot, con voti in conflitto rilevabili attraverso il sistema. La non partecipazione persistente rende i validatori non idonei per le ricompense e rischia la rimozione dal set di validatori attivi. I leader ricevono una compensazione pari alle ricompense dei voti per slot dagli aggregati delle votazioni, oltre a bonus fissi quando includono certificati di finalizzazione rapida o finalizzazione nei loro blocchi.
Risposta della Comunità e Preoccupazioni sull'Implementazione
Il feedback dei validatori si è concentrato sui rischi operativi e sui protocolli di distribuzione riguardanti i cambiamenti proposti. Una risposta mirata ai validatori sottolinea la necessità di "piani di test, distribuzione e fallback" integrati prima di qualsiasi implementazione nella rete principale, confrontando l'entità con altre importanti transizioni di protocollo a livello industriale.
I membri della comunità hanno sollevato domande specifiche sui livelli di prezzo del VAT, sui meccanismi di scadenza delle transazioni in un ambiente post-Proof-of-History e sulle procedure di gestione della equivocazione dei leader.
Ulteriori preoccupazioni si concentrano sugli effetti potenziali sulle aste MEV e sull'esperienza dell'utente del client quando porzioni di blocco vengono ignorate in determinate condizioni di fallimento.
Queste discussioni evidenziano che mentre l'obiettivo di finalità di 150 millisecondi genera entusiasmo, le decisioni di voto dipenderanno probabilmente dal comfort dei validatori con le prove di sicurezza, i casi limite degli incentivi e la chiarezza del percorso di migrazione.
Comprensione dei Termini Chiave della Blockchain
Diversi concetti tecnici centrali nella proposta Alpenglow richiedono spiegazione per una comprensione più ampia. I meccanismi di consenso determinano come le reti blockchain concordano sulla validità delle transazioni e sull'ordinamento dei blocchi, mentre la finalità si riferisce al punto in cui le transazioni diventano irreversibili. TowerBFT rappresenta l'attuale sistema di tolleranza ai guasti bizantina di Solana, progettato per mantenere la sicurezza della rete anche quando alcuni validatori agiscono in modo malevolo o non rispondono.
Proof-of-History serve come meccanismo di temporizzazione unico di Solana, creando ritardi verificabili tra eventi senza richiedere la comunicazione dei validatori. L'economia dei validatori comprende gli incentivi finanziari e i costi associati all'operazione di nodi di validazione della rete. MEV, o Valore Estraibile Massimo, descrive i profitti che i validatori possono guadagnare riordinando le transazioni all'interno dei blocchi.
Contesto di Mercato e Sviluppo Futuro
Al momento del rapporto, SOL era scambiato a $181.89, riflettendo l'interesse continuo del mercato nella traiettoria di sviluppo tecnico di Solana. La documentazione di proposta di Alpenglow fa riferimento a un white paper completo di oltre 50 pagine insieme ad analisi indipendenti a supporto dell'approccio tecnico. Tuttavia, l'implementazione iniziale si concentra specificamente sui meccanismi di finalizzazione e voto, con un protocollo di diffusione dati separato chiamato Rotor pianificato per future proposte SIMD.
Il processo di governance rispecchia i precedenti meccanismi consultivi di Solana ma comporta rischi significativamente più alti date le modifiche fondamentali della natura del consenso.
Il successo posizionerebbe Solana tra le reti blockchain principali a finalizzazione più veloce, potenzialmente attirando applicazioni che richiedono conferma delle transazioni quasi istantanee.
Considerazioni Finali
Alpenglow rappresenta il cambiamento proposto più significativo nell'architettura core di Solana dalla sua nascita, promettendo miglioramenti drammatici nei tempi di finalità e nella tolleranza ai guasti. Il voto della comunità previsto per le epoche 840-842 determinerà se i validatori accetteranno questa revisione completa del consenso nonostante le complessità di implementazione e i requisiti di ristrutturazione economica.