Solana gli sviluppatori principali hanno introdotto un ampio rinnovamento del consenso chiamato "Alpenglow" nel processo formale di governance del blockchain, proponendo di sostituire l'attuale sistema TowerBFT della rete con un'architettura ridisegnata che promette tempi di finalizzazione dei blocchi di soli 100-150 millisecondi. La proposta, scritta da Quentin Kniep, Kobi Sliwinski e Roger Wattenhofer, rappresenta quella che descrivono come "un'importante revisione del protocollo di consenso principale di Solana" che eliminerebbe i meccanismi esistenti di Proof-of-History e TowerBFT.
Cosa sapere:
- Alpenglow introduce il protocollo Votor, trasferendo la votazione dei validatori fuori dalla chain per ottenere una finalità dei blocchi sub-secondo e ridurre la larghezza di banda della rete
- La proposta richiede una commissione di 1.6 SOL per epoca per il biglietto di ammissione del validatore per mantenere barriere economiche paragonabili ai costi attuali di voto nella chain
- La votazione della comunità avviene durante le epoche 840-842, richiedendo una maggioranza qualificata di due terzi per il passaggio con i validatori che utilizzano token di voto riscattabili
Cronologia della governance e meccaniche di voto
Il quadro di governance stabilisce un programma di implementazione in tre fasi che si estende su più epoche. La discussione si svolge durante le epoche 833-838, seguita dalla cattura del peso dello stake nell'epoca 839, e votazioni vincolanti nelle epoche 840-842 utilizzando token di voto riscattabili distribuiti a conti designati "Sì", "No" o "Astieni". Con Solana attualmente nell'epoca 834, la finestra di discussione rimane attiva mentre il periodo di voto si avvicina in diverse epoche.
Il passaggio richiede una soglia di maggioranza qualificata in cui i voti affermativi devono costituire almeno due terzi dei voti combinati Sì e No, accanto a un quorum del 33% che include le astensioni.
I token di voto saranno distribuiti tramite un sistema di distributori Merkle adattato, permettendo ai validatori di indirizzare i token ai propri conti di scelta preferita durante la finestra dell'epoca designata. La fondazione pubblicherà i pesi degli stake e uno script pubblico per la verifica indipendente dei risultati.
Architettura tecnica del sistema Alpenglow
La proposta si concentra su Votor, un protocollo di finalità leader-pipelined con voto diretto che cambia fondamentalmente l'approccio al consenso di Solana. Piuttosto che processare i voti come transazioni sulla chain attraverso reti di gossip pesanti, Alpenglow si trasferisce allo scambio di voti fuori dalla chain con aggregazione delle firme locali. I validatori votano per notarizzare o saltare i blocchi, mentre i leader aggregano i voti otto slot più tardi e inviano prove compatte alla rete.
Questo cambiamento architettonico supporta ciò che gli sviluppatori chiamano un modello di vivacità "20+20", progettato per tollerare fino al 20% di validatori avversari e 20% di validatori non responsivi senza fermare il progresso della rete.
Il sistema punta a ridurre drasticamente la latenza mentre diminuisce i requisiti di larghezza di banda attraverso la rete. Secondo gli autori della proposta, "Alpenglow consente una latenza molto inferiore, una tolleranza ai guasti migliorata e un'efficienza generale del protocollo maggiore."
L'aggiornamento produrrebbe cambiamenti visibili a livello di client, sostituendo la conferma ottimistica con una finalità effettiva a scala di tempo sub-secondo. Gli sviluppatori affermano che questo approccio porta le latenze di conferma in linea con le aspettative degli utenti Web2 mentre rafforza le garanzie di sicurezza che si sono rivelate difficili da formalizzare sotto il sistema TowerBFT esistente.
Ristrutturazione economica e incentivi per i validatori
Spostare i voti fuori dalla chain richiede importanti cambiamenti nell'economia dei validatori all'interno dell'ecosistema Solana. La proposta introduce un sistema di biglietti di ammissione del validatore che richiede una tariffa fissa di 1.6 SOL per epoca che viene bruciata per mantenere barriere economiche approssimativamente paragonabili alle attuali strutture di costo del voto nella chain. Questo importo rappresenta circa l'80% dei costi di voto esistenti, assicurando che nessun operatore di validatore sperimenti condizioni economiche peggiori durante la transizione.
Sotto Alpenglow, i validatori devono esprimere esattamente un voto valido per slot, con voti conflittuali che rimangono rilevabili attraverso il sistema. Una partecipazione non persistente rende i validatori non idonei per i premi e rischia la rimozione dal set di validatori attivi. I leader ricevono una compensazione pari ai premi di voto per slot dai voti aggregati, oltre a bonus fissi quando includono certificati di finalizzazione rapida o di 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 focalizzata sui validatori sottolinea la necessità di piani di "test, distribuzione e fallback" incorporati prima di qualsiasi implementazione sulla mainnet, comparando la portata ad altre transizioni di protocollo di scala industriale importanti.
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 delle equivoche leader.
Ulteriori preoccupazioni si concentrano sugli effetti potenziali sulle aste MEV e sull'esperienza utente del client quando porzioni di blocchi 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.
Comprendere i principali termini della blockchain
Diversi concetti tecnici centrali nella proposta di 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 agli Errori Bizantini 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 univoco di Solana, creando ritardi verificabili tra eventi senza richiedere la comunicazione tra i validatori. L'economia dei validatori comprende gli incentivi finanziari e i costi associati all'operare i nodi di validazione della rete. MEV, o Valore Estraibile Massimo, descrive i profitti che i validatori possono guadagnare riorganizzando transazioni all'interno dei blocchi.
Contesto di mercato e sviluppo futuro
Al momento del rapporto, SOL ha negoziato a $181.89, riflettendo l'interesse continuo del mercato nella traiettoria di sviluppo tecnico di Solana. La documentazione della proposta Alpenglow fa riferimento a un white paper completo che supera le 50 pagine insieme ad analisi indipendenti che supportano l'approccio tecnico. Tuttavia, l'implementazione iniziale si concentra specificamente sui meccanismi di finalizzazione e di voto, con un protocollo di diffusione dei dati separato chiamato Rotor pianificato per le proposte future SIMD.
Il processo di governance rispecchia i precedenti meccanismi consultivi di Solana ma comporta sfide significativamente maggiori date la natura fondamentale delle modifiche al consenso.
Il successo posizionerebbe Solana tra le reti blockchain di maggior finalizzazione veloce, potenzialmente attirando applicazioni che richiedono conferme di transazioni quasi istantanee.
Pensieri conclusivi
Alpenglow rappresenta il più significativo cambiamento proposto all'architettura centrale di Solana dal lancio della rete, promettendo miglioramenti drammatici nei tempi di finalità e nella tolleranza ai guasti. Il voto della comunità programmato per le epoche 840-842 determinerà se i validatori abbracceranno questa revisione completa del consenso nonostante le complessità di implementazione e le esigenze di ristrutturazione economica.