Yakovenko di Solana mette in discussione la costruzione di Alpenglow mentre le transazioni di voto escono

Il co-fondatore di Solana, Anatoly Yakovenko, ha affermato che Alpenglow avrebbe potuto essere completato in metà del tempo attraverso una modifica più semplice del programma di voto, in vista della migrazione del consenso del 21 ottobre che rimuoverà le transazioni di voto dei validatori dai blocchi.

Riepilogo

• Yakovenko ha dichiarato che una modifica più semplice del programma di voto avrebbe potuto dimezzare il tempo di sviluppo di Alpenglow.
• La rimozione delle transazioni di voto dei validatori abbasserà i conteggi TPS senza necessariamente cambiare l'attività degli utenti.
• Una tassa di ammissione di 0,8 SOL bruciata per epoca sostituirà le singole tasse di voto.
• Alcuni nodi RPC potrebbero ricevere aggiornamenti di finalità più tardi rispetto all'obiettivo di 150 millisecondi di Alpenglow.

Yakovenko, in un post su X del 21 ottobre, ha fatto il commento citando un commento che celebrava la prevista rimozione dei voti on-chain e deridendo le critiche ricorrenti secondo cui la maggior parte delle transazioni al secondo di Solana consiste in voti dei validatori.

"Alpenglow sarebbe stato completato in metà del tempo se avessero semplicemente cambiato il programma di voto nello stato della macchina ag"

Il design pubblicato da Anza descrive un sostituto per TowerBFT, il sistema utilizzato dai validatori per concordare sui blocchi, con votazione diretta e certificati compatti.

La migrazione della mainnet è stata programmata per il 21 ottobre, come riportato in precedenza da crypto.news mentre copriva il previsto passaggio del consenso. La guida aggiornata della Solana Foundation identifica l'epoca 1064 come il trigger e stima il suo inizio intorno alle 13:20 UTC.

La pagina di migrazione di Anza separa l'attivazione delle funzionalità dal passaggio del consenso. Il confine di migrazione arriva 5.000 slot dopo, quando i blocchi portano temporaneamente solo voti mentre i validatori completano la transizione.

Alpenglow rimuove i voti dai conteggi delle transazioni principali

La guida alla migrazione della Solana Foundation informa gli esploratori e i servizi di analisi di reimpostare le linee di base del conteggio delle transazioni e dei TPS perché le transazioni di voto scompariranno dai blocchi. Un totale che include i voti diminuirà anche se pagamenti, scambi e altre transazioni non di voto rimarranno invariati.

La Fondazione afferma che i servizi che tracciano la partecipazione dei validatori devono sostituire la loro lettura delle istruzioni del programma di voto con i dati dei certificati nei footer dei blocchi. La sua guida nota che il messaggio del footer gRPC di Yellowstone non inoltra ancora quei certificati.

Gli sviluppatori avevano accesso al comportamento modificato quando Alpenglow ha raggiunto il devnet a settembre, dopo la transizione del testnet. La copertura del 26 settembre ha descritto come gli esploratori devono mantenere separati i blocchi candidati concorrenti fino alla conferma, mantenendo il blocco selezionato invece di combinare le loro transazioni.

La documentazione dell'operatore di Anza spiega come i plugin ottengono i metadati sostitutivi. Agave 4.3 fornisce una notifica opzionale del footer del blocco, che i servizi devono abilitare e implementare se necessitano di dati del footer. Quelle notifiche mantengono il loro ordinamento rispetto alle notifiche di ingresso.

Sotto la stessa documentazione, l'orologio della catena mantiene il suo formato esistente e la precisione al secondo intero. Durante l'esecuzione delle transazioni, il suo timestamp stima quando è terminato il blocco padre, e agli operatori viene detto di continuare a trattare quel valore come approssimativo.

Le tasse dei validatori si spostano su una tassa separata per epoca

La documentazione delle tasse della Solana Foundation afferma che la rimozione dei voti on-chain termina le tasse pagate sulle singole transazioni di voto. I validatori invece pagano una tassa fissa di ammissione di 0,8 SOL per epoca, con l'intero importo bruciato.

Il denaro proviene dall'account di voto, sostituendo l'account di identità come fonte dei pagamenti legati al voto. Gli operatori devono mantenere la tassa sopra il minimo esente da affitto dell'account, secondo la stessa guida.

Il pagamento viene effettuato un'epoca prima. La prima tassa all'inizio dell'epoca 1064 copre la partecipazione all'epoca 1065, e un validatore che non può pagare perde il permesso di votare o produrre blocchi nell'epoca successiva.

La Fondazione afferma che la registrazione della chiave pubblica BLS è diventata disponibile sulla mainnet l'8 luglio, mentre la funzionalità di ammissione è stata attivata il 22 luglio. Questi cambiamenti preparatori non hanno attivato di per sé il consenso di Alpenglow.

Prima della migrazione, la sua lista di controllo richiede la versione 4.3.2 di Agave, Jito-Solana o Harmonic Salsa. Firedancer e Frankendancer non sono supportati durante il passaggio, secondo le istruzioni dell'operatore della Fondazione.

Due percorsi di voto sostituiscono TowerBFT

Anza descrive Votor come un sistema che esegue due percorsi di voto contemporaneamente. Uno finalizza un blocco in un solo round con risposte dall'80% dello stake, mentre il secondo utilizza due round e soglie del 60%.

I voti diventano messaggi diretti firmati con crittografia BLS, consentendo a più firme di essere combinate in un certificato compatto. Anza afferma che i validatori utilizzano i propri timer per identificare un leader non reattivo e votare per saltarlo.

La proposta SIMD-0326 pubblicata documenta le alternative considerate durante lo sviluppo. Un design senza finalità a round singolo offriva un'operazione più semplice e una tolleranza ai guasti bizantini del 33%, ma i suoi autori hanno elencato una latenza peggiore e una minore resilienza ai crash tra gli svantaggi.

Un'altra alternativa utilizzava un grafo aciclico diretto, con possibili risparmi di larghezza di banda. Gli autori della proposta hanno elencato la latenza e la difficoltà di utilizzare completamente la larghezza di banda tra i suoi svantaggi.

La proposta limita il set ammesso a 2.000 validatori, dando priorità agli operatori con il maggior stake. I suoi autori spiegano che il limite aiuta a mantenere i certificati abbastanza piccoli per un singolo messaggio UDP, mentre i registri di partecipazione supportano ricompense per i validatori che votano attivamente.

L'approvazione della governance ha preceduto l'implementazione. A settembre 2025, la proposta Alpenglow è stata approvata con il 98,27% di supporto tra i voti espressi, mentre lo stake partecipante rappresentava il 52% del totale, secondo le cifre pubblicate della scheda completata.

La consegna RPC può ritardare rispetto alla finalità del consenso

La documentazione dell'operatore di Anza qualifica l'obiettivo di finalità di circa 150 millisecondi spiegando che i nodi al di fuori del set di validatori ammessi possono ricevere il risultato più tardi.

Attraverso il percorso predefinito, quei nodi apprendono la finalità dai certificati inclusi in un blocco successivo. Anza afferma che ciò può aggiungere fino a un intervallo di blocco prodotto, con attese più lunghe quando i blocchi vengono saltati o ritardati.

Un validatore ammesso può inviare messaggi di consenso direttamente a un nodo partner, lasciando la latenza di rete tra i partner come il principale ritardo aggiunto. Se ogni partner configurato diventa irraggiungibile, il destinatario torna ad apprendere la finalità dai footer dei blocchi successivi.