Da marzo 2020 a ottobre 2026 ogni blocco di Solana è stato timbrato da un contatore che non si fermava mai. Un solo core del processore, sulla macchina del leader, prendeva un hash SHA-256, calcolava l’hash del risultato, poi quello del risultato successivo, e andava avanti così: circa due milioni di volte per ogni slot da 200 millisecondi, con i parametri di ottobre 2026. Quella catena di hash era la proof of history di Solana, e permetteva a migliaia di macchine che non si fidavano degli orologi altrui di mettersi d’accordo su che cosa fosse venuto prima e su chi dovesse costruire blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il blocco successivo.
Il 21 ottobre 2026 alle 13:36:05 UTC, allo slot 459.648.000, la feature gate di Alpenglow si è attivata sulla mainnet e, circa 18 minuti dopo, la rete ha passato il consenso da Tower BFT a un nuovo protocollo di voto chiamato Votor. Anza, lo sviluppatore del client validatore Agave, scrive oggi nella sua pagina su Alpenglow che «Proof of History is gone» (la proof of history non c’è più). O quasi. Un tick da un solo hash chiude ancora ogni blocco: un residuo che la proposta di migrazione conserva perché toglierlo sarebbe «a load of risky work», cioè un lavoro carico di rischi.
Questa lezione spiega che cosa faceva l’orologio, che cosa Solana ha costruito intorno a esso, perché entrambi sono stati ritirati e chi governa la rete all’8 novembre 2026. Segue la lezione sul consenso BFT, Tendermint e HotStuff, che ha mostrato come i protocolli di voto classici raggiungano un quorum dei due terzi. Un promemoria dalla lezione su finalità e riorganizzazioni: Solana espone tre livelli di commitment (processed, confirmed, finalized); con Tower BFT «finalized» significava 31 blocchi confermati sopra, circa 12,8 secondi con slot da 400 millisecondi, e Alpenglow ha fuso confirmed e finalized in un solo passaggio. Qui si scende di un piano, fino all’orologio che stava sotto quei livelli e ai meccanismi che lo hanno sostituito. Se quorum e guasti bizantini sono concetti nuovi, conviene partire dal problema dei generali bizantini.
Proof of history Solana: come funziona una catena di hash che conta il tempo
I sistemi distribuiti non hanno un orologio condiviso. Ogni server tiene il proprio tempo, lo sbaglia e può anche mentire. Bitcoin aggira il problema ordinando le transazioni solo quando un miner trova un blocco; i protocolli BFT classici le ordinano con round di messaggi. Il white paper di Anatoly Yakovenko, che descrive la versione 0.8.14 del progetto, proponeva una terza strada: scrivere nel registro stesso una prova verificabile del tempo trascorso. Nelle parole dell’abstract, «PoH is used to encode trustless passage of time into a ledger», ovvero la PoH serve a codificare nel registro il passare del tempo senza bisogno di fidarsi di nessuno.
Sequenziale da produrre, parallela da verificare
Il meccanismo sta in una riga. Si prende un valore, lo si passa in SHA-256, si rimette l’output come input successivo e si tiene accanto un contatore. Ogni passo richiede l’output del precedente, quindi nessuno può calcolare l’hash numero un milione senza aver calcolato prima i 999.999 che lo precedono, e aggiungere processori non serve: il lavoro non si può dividere. Una catena lunga è dunque la prova che è passata una quantità nota di calcolo e, su hardware noto, più o meno una quantità nota di tempo.
Controllarla è un’altra faccenda. Chi riceve la catena con alcuni punti di controllo intermedi, per esempio gli output ai conteggi 200, 300 e 400, può affidare ogni segmento a un core diverso e confermarli tutti insieme, perché ogni segmento parte da un hash pubblicato. L’esempio del white paper distribuisce la sequenza su una scheda grafica da 4.000 core. La produzione gira su un core, la verifica su migliaia, e questa asimmetria è l’idea intera: quello che i crittografi chiamano ritardo verificabile.
È facile confonderla con la proof of work, che pure brucia hash. Un miner di Bitcoin cerca in parallelo un hash fortunato sotto una soglia, e più macchine significano più probabilità; la lezione precedente di questo percorso su hashrate e difficoltà di mining mostra come si misura quella corsa. Il generatore PoH non cerca niente. Non c’è lotteria e non c’è premio per chi fa girare un secondo generatore, c’è solo un contatore che deve continuare a contare.
Come si timbrano le transazioni nella sequenza
Per registrare un evento, il generatore inserisce nella catena l’hash del dato: l’output successivo diventa l’hash dell’output precedente combinato con l’hash del dato. Da quel momento chiunque può dimostrare due cose. Il dato esisteva prima delle voci seguenti, perché sono state calcolate a partire da esso. E fu aggiunto dopo la voce precedente, perché inserirlo prima avrebbe cambiato ogni hash a valle. L’ordine è fissato senza alcun messaggio tra i nodi.
Ciò che la catena offre è ordine e distanza, non date. Un intervallo di due milioni di hash dice che tra due eventi c’è quel tanto di lavoro sequenziale; non dice se sono passati 200 o 300 millisecondi, perché la velocità di calcolo dipende dal chip. Gli orari dei blocchi che mostrano gli explorer non sono mai usciti dalla catena di hash. Con Tower BFT i validatori allegavano ai propri voti un timestamp dell’orologio di sistema, e le note di progetto di Anza sull’oracolo dei timestamp descrivono una media di quelle segnalazioni pesata per stake.
Che cosa prometteva il white paper
Il documento abbinava l’orologio a un algoritmo di consenso; non ha mai preteso di sostituirne uno. L’abstract dice che la PoH può ridurre il carico di messaggi se usata insieme alla proof of work o alla proof of stake, portando a una finalità sotto il secondo. Include anche un’analisi di throughput su una rete da 1 gigabit al secondo: dividendo quella banda per transazioni da 176 byte si ottengono le celebri 710.000 transazioni al secondo, un tetto teorico fissato dalla banda, non una cifra mai misurata sulla mainnet.
Due nomi che ogni spiegazione di Solana cita, Tower BFT e Turbine, non compaiono nella versione 0.8.14 del documento. Il protocollo di voto abbozzato lì era un altro progetto di proof of stake, pensato per riprendersi dalle partizioni di rete. Quello che nel 2020 è andato in produzione su Solana discende dal documento ma ne differisce, ed è una delle ragioni per cui tante descrizioni di «come funziona Solana» confondono i pezzi.
Solana è proof of stake o proof of history? Non è consenso, e non è un servizio di timestamp
L’errore più diffuso su Solana sta nella domanda «è proof of stake o proof of history?», come se la rete avesse scelto una delle due. Solana è sempre stata una catena proof of stake. I SOL delegati a un validatore stabiliscono quanto spesso quello guida la rete, quanto pesa il suo voto e quanto guadagna; la nostra lezione sulla proof of stake in dettaglio spiega questi meccanismi su Ethereum, e la lezione su validatori, slashing e ricompense racconta come gli operatori vengono pagati e penalizzati. La PoH rispondeva a un’altra domanda: in quale ordine sono successe le cose, ed è davvero il tuo turno? A decidere quali blocchi contano è sempre stato un voto separato.
Il secondo errore è trattare la catena di hash come prova del tempo reale. Nessuno confronta la PoH con l’UTC. Un leader con un chip più veloce hasha semplicemente più in fretta, e il protocollo risolveva il problema fissando il numero di hash per tick e cambiandolo quando serviva. Per questo SIMD-0525, la proposta dietro gli slot più rapidi del 2026, ha abbassato gli hash per tick da 62.500 con slot da 400 millisecondi a 31.250 con slot da 200: il conteggio era tarato su una durata attesa, mai verificato contro una durata reale.
Slot, leader ed epoche: un calendario che tutti sanno calcolare
Il leader schedule
Solana divide il tempo in slot e gli slot in epoche da 432.000. Per ogni epoca ogni validatore calcola lo stesso leader schedule a partire dalla distribuzione dello stake, quindi la guida della rete è ripartita in proporzione allo stake. La documentazione di Anza descrive il calendario come calcolato con un’epoca di anticipo e, nel progetto in uso prima di Alpenglow, generato dall’altezza dei tick PoH. Ogni leader riceve quattro slot consecutivi. Un campione di 24 slot letto dalla RPC pubblica della mainnet l’8 novembre 2026 mostrava proprio questo schema, con un leader a quota otto slot perché il sorteggio gli aveva assegnato due finestre di fila.
Qui la PoH faceva il lavoro di ogni giorno. Ogni slot era di 64 tick, ogni tick un numero fisso di hash. Un leader non poteva partire in anticipo, perché il suo primo blocco doveva proseguire la catena di hash dalla fine dello slot precedente. Se il leader prima restava in silenzio, il successivo doveva calcolare hash lungo lo slot vuoto per dimostrare che il tempo era trascorso, prima di subentrare. L’orologio imponeva i turni senza alcun giro di messaggi in cui chiedere il permesso.
Da 400 a 200 ms: il tempo di slot dimezzato in quattro passi
Per gran parte della sua vita Solana ha puntato a slot da 400 millisecondi, e molte spiegazioni lo ripetono ancora. Quella cifra è superata. SIMD-0525, scritta da Brennan Watt di Anza, ha ridotto l’obiettivo in quattro passi con feature gate, tra agosto e ottobre 2026, mantenendo 64 tick per slot, finestre di leader da quattro slot ed epoche da 432.000 slot. Ogni gate entra in vigore un’epoca dopo l’attivazione, e i tempi di blocco della catena mostrano ogni passo: lo slot medio è sceso da circa 416 a circa 366 millisecondi nell’epoca iniziata il 21 agosto, e lo stesso calo si vede a ogni passo successivo. I limiti per slot, come le compute unit per blocco, sono stati ridotti in proporzione, in modo che la capacità per secondo resti più o meno la stessa.
| Slot obiettivo | In vigore da (2026, primo slot dell’epoca) | Epoca nominale | Finestra del leader | Hash per tick prima di Alpenglow | Slot medio misurato |
|---|---|---|---|---|---|
| 400 ms | fino al 21 agosto | 48 ore | 1,6 s | 62.500 | circa 416 ms (epoche 1016-1019) |
| 350 ms | 21 agosto, 07:45 UTC (epoca 1020) | 42 ore | 1,4 s | 54.687 | circa 365-367 ms (epoche 1020-1023) |
| 300 ms | 28 agosto, 15:25 UTC (epoca 1024) | 36 ore | 1,2 s | 46.875 | circa 315-317 ms (epoche 1024-1036) |
| 250 ms | 18 settembre, 05:06 UTC (epoca 1037) | 30 ore | 1,0 s | 39.062 | circa 266-269 ms (epoche 1037-1052) |
| 200 ms | 9 ottobre, 14:40 UTC (epoca 1053) | 24 ore | 0,8 s | 31.250 | circa 212-218 ms (epoche 1053-1079) |
Gli slot girano un poco più lenti dell’obiettivo, come è sempre stato. I campioni di prestazioni della RPC pubblica dell’8 novembre 2026 indicavano da 277 a 284 slot al minuto, circa da 211 a 217 millisecondi ciascuno. SIMD-0525 spiega il motivo senza giri di parole: slot più brevi riducono i tempi di conferma, e una finestra di leader di 0,8 secondi invece di 1,6 dimezza il tempo in cui un leader può ritardare o riordinare le transazioni prima che subentri il successivo. Un effetto collaterale per chi usa la rete: un recent blockhash, a cui ogni transazione deve fare riferimento, scade dopo 150 blocchi, quindi una transazione firmata diventa vecchia in circa 30 secondi invece che in circa un minuto.
Tower BFT: come un blocco diventava definitivo
Voti con lockout che raddoppiano
Tower BFT era l’adattamento di Solana della practical Byzantine fault tolerance all’orologio PoH. I validatori votavano i blocchi che vedevano, con normali transazioni on chain, e ogni voto portava un lockout: la promessa di non votare per un fork in conflitto per un certo numero di slot. Secondo la documentazione di Anza su Tower BFT, ogni nuovo voto raddoppiava i lockout dei voti precedenti nella torre del validatore, così l’impegno di un voto cresceva di 2, 4, 8, 16 slot e oltre man mano che altri voti si impilavano sopra. Dopo 32 voti il più vecchio arrivava a un lockout di 2 elevato alla 32 slot, usciva dalla torre e il suo blocco diventava la radice di quel validatore.
Due protezioni impedivano ai validatori di incatenarsi a un fork perdente. Prima di impegnarsi più a fondo, un validatore controllava che il suo voto otto posizioni più in basso nella torre fosse sostenuto dai due terzi dello stake. Per passare a un altro fork serviva la prova che più del 38% dello stake fosse già altrove. La PoH è ciò che rendeva applicabili i lockout: erano contati in slot, gli slot in tick, e nessuno poteva accorciare un lockout sostenendo che il tempo fosse passato senza mostrare gli hash.
Conferma ottimistica e il divario di 12,8 secondi
I wallet non aspettavano le radici. Un blocco votato dai due terzi dello stake contava come confermato in circa un secondo, mentre la finalità piena richiedeva 32 slot. La proposta di Alpenglow, SIMD-0326, è franca sul predecessore: Tower BFT «does not have a security proof, which is concerning», cioè non ha una dimostrazione di sicurezza, il che preoccupa. Era anche costoso. Secondo lo stesso documento, i validatori pagavano circa 1 SOL al giorno ciascuno in commissioni per le transazioni di voto, e quei voti si contendevano lo spazio con le transazioni degli utenti in ogni blocco.
Turbine e Gulf Stream: far viaggiare blocchi e transazioni
Un leader che produce un blocco ogni poche centinaia di millisecondi non può inviarlo a ciascuno di qualche centinaio di validatori, uno per volta. Turbine, il livello di propagazione dei blocchi di Solana, taglia ogni blocco in piccoli pacchetti chiamati shred, aggiunge shred di recupero con codifica a cancellazione così che il blocco si possa ricostruire anche se alcuni pacchetti si perdono, e spinge ogni shred lungo un albero di validatori in cui i nodi con più stake stanno più vicini al leader. La documentazione di Anza precisa che l’albero viene rimescolato per ogni shred. Turbine porta ancora i blocchi oggi: il suo sostituto previsto, Rotor, non è in produzione.
Gulf Stream era il nome originale di una seconda idea: niente sala d’attesa pubblica. Poiché il leader schedule è noto in anticipo, i nodi RPC inoltrano le transazioni direttamente al leader attuale e a quelli successivi invece di farle girare in gossip per la rete, come fanno Bitcoin ed Ethereum con i loro mempool e mercati delle commissioni. Aggiornamenti successivi hanno spostato quelle connessioni sul protocollo QUIC e aggiunto una qualità del servizio pesata per stake, che riserva più capacità in ingresso del leader al traffico inoltrato da validatori con stake. Il nome sopravvive appena nel codice; il modello di inoltro sì.
Alpenglow su Solana: il voto che ha sostituito Tower BFT e l’orologio
Alpenglow è stato ideato da Quentin Kniep, Kobi Sliwinski e Roger Wattenhofer e specificato per Solana in SIMD-0326. Il voto di governance pesato per stake di Solana lo ha approvato all’inizio di settembre 2025 con circa il 98% dei voti espressi a favore, secondo Blockworks. La pagina di Anza, datata 5 novembre 2026, indica l’attivazione su testnet il 24 settembre e su devnet il 25 settembre, prima della mainnet. SIMD-0326 copre la metà che riguarda il voto, Votor. L’altra metà, Rotor, che si occupa di diffondere i blocchi, avrà in seguito una proposta propria.
Votor: un round all’80%, oppure due al 60%
Con Votor ogni validatore tiene un timer locale per lo slot in corso. Se un blocco valido arriva in tempo, vota per notarizzarlo; altrimenti vota per saltare lo slot. I voti non sono più transazioni: viaggiano direttamente tra validatori e vengono aggregati in firme BLS compatte chiamate certificati. Se l’80% dello stake notarizza un blocco già nel primo round, il blocco è definitivo subito, ciò che la specifica chiama fast finalization. Se lo fa soltanto il 60%, i validatori eseguono un secondo round, e il 60% di voti di finalizzazione completa il lavoro.
SIMD-0326 definisce cinque certificati: notarizzazione, skip, finalizzazione, fast finalization e notar-fallback. I voti di fallback permettono alla rete di riprendersi quando il primo round si divide. Non ci sono lockout né una torre da 32 voti: quando un blocco è finalizzato lo sono anche tutti i suoi antenati, e gli slot mancanti nella sua catena sono trattati come saltati.
Il prezzo è un modello di guasto diverso. I protocolli BFT classici, compresa la famiglia Tendermint della lezione precedente, restano sicuri con fino a un terzo di stake bizantino. Gli autori di Alpenglow hanno scelto quello che chiamano modello 20+20: funzionamento corretto con fino al 20% di stake malevolo più un altro 20% semplicemente offline. La proposta dichiara di rinunciare al limite bizantino del 33% in cambio della finalità in un solo round e di una resilienza ai crash del 40%, e sostiene che lo scambio valga la pena.
Che cosa è cambiato per i validatori
Con i voti fuori dalla catena, le commissioni di voto sono sparite. Per tenere l’economia più o meno dov’era, Alpenglow ha aggiunto un Validator Admission Ticket, detratto prima di ogni epoca e bruciato anziché pagato a qualcuno. Equivale all’80% del vecchio costo di voto, circa 0,8 SOL al giorno. SIMD-0525 lo scala con il tempo di slot in modo che il costo giornaliero non cambi: 1,6 SOL per un’epoca da 48 ore con slot da 400 millisecondi, 0,8 SOL per un’epoca da 24 ore a 200. L’insieme attivo è limitato ai 2.000 validatori con più stake, ben oltre il numero attuale. Le ricompense vanno ai voti che un leader include negli aggregati otto slot dopo, e un validatore che non guadagna nulla in un’epoca esce dall’insieme attivo.
Una traccia di tutto questo si vede dall’esterno. In ciascuno dei tre campioni di un minuto restituiti dalla RPC pubblica l’8 novembre 2026, circa 50.000 transazioni, il conteggio delle transazioni non di voto era uguale al totale. Con Tower BFT il totale comprendeva anche le transazioni di voto. È un controllo rapido, non un audit, ma coincide con voti che non viaggiano più dentro i blocchi.
Il passaggio di consegne del 21 ottobre 2026
Cambiare il consenso di una rete in funzione senza annullare i pagamenti già confermati era la parte difficile. SIMD-0384, la proposta di migrazione, ha fissato il confine 5.000 slot dopo l’attivazione della feature, allo slot 459.653.000. Da lì i blocchi contenevano soltanto voti, finché un blocco non otteneva una conferma ottimistica forte dall’82% dello stake. I validatori firmavano poi un genesis vote per l’ultimo blocco Tower BFT prima del confine, e l’82% di quei voti formava il genesis certificate. I blocchi successivi al blocco genesis venivano scartati, cosa sicura perché non contenevano transazioni di utenti, e Alpenglow subentrava.
Sulla mainnet la gate è diventata attiva allo slot 459.648.000, che la catena data alle 13:36:05 UTC del 21 ottobre 2026. Gli slot da 459.653.000 a 459.653.007 non hanno prodotto blocchi; il primo blocco dopo il confine, lo slot 459.653.008, porta l’ora 13:54:03 UTC, circa 18 minuti dopo la gate. La soglia dell’82% è accompagnata nella proposta da una breve dimostrazione: con al massimo il 19% di stake malevolo, due certificati in conflitto non possono raggiungere entrambi l’82%, e il 63% di stake onesto che resta basta a far girare Alpenglow.
Che cosa resta della proof of history
La pagina di Anza riassume la sostituzione in una riga: «Every node runs its own timers and independently identifies a silent leader» (ogni nodo usa i propri timer e individua da solo un leader silenzioso). Uno slot il cui leader tace si chiude con un certificato di skip. Di questi timeout SIMD-0326 dice: «Their purpose is akin to Proof-of-History, but without any notion of synchronized time», ossia hanno uno scopo affine alla PoH, ma senza alcuna nozione di tempo sincronizzato. La deriva degli orologi non conta più: la proposta osserva che tollerare il 5% di deriva significa solo allungare i timeout del 5%.
Il residuo esatto è scritto in SIMD-0384 (la pagina del repository la mostrava ancora in revisione l’8 novembre 2026, quindi va letta come specifica, non come audit del codice). Quando sono cominciati i blocchi Alpenglow, il produttore di tick è stato messo in modalità a basso consumo di un hash per tick, l’altezza di tick della bank viene portata appena sotto il massimo prima della fine di ogni blocco, e un ultimo tick chiude ogni blocco, così il software che impacchetta le transazioni e trasmette gli shred sa che il blocco è finito. La verifica dei tick è stata disattivata. SIMD-0525 aggiunge che gli hash per tick non vanno abbassati finché gira Alpenglow, perché il suo percorso a basso consumo è «currently expected to be one hash per tick», cioè al momento previsto in un hash per tick.
Così uno slot da 200 millisecondi che a metà ottobre portava 2 milioni di hash sequenziali ora termina con un solo hash che non prova nulla sul tempo. I nomi delle funzioni sopravvivono nel codice; l’orologio no. I leader sono ancora assegnati in anticipo in base allo stake, in finestre da quattro slot, come mostra il campione RPC; quale seme usi il calendario dopo il passaggio non è indicato nella documentazione pubblica di Anza.
Obiettivi che restano obiettivi
Due numeri da titolo richiedono cautela. L’annuncio di Anza del maggio 2025 indicava per Alpenglow una finalità mediana di circa 150 millisecondi, a volte 100, in simulazioni sulla distribuzione dello stake di allora. All’8 novembre 2026 non era stata pubblicata nessuna misura indipendente della finalità sulla mainnet dopo il 21 ottobre, quindi i 150 millisecondi sono l’obiettivo di progetto, non un risultato osservato. Rotor, che secondo Anza sostituirà l’albero a più livelli di Turbine con un solo salto di relay, è tra le cose in arrivo.
| Tower BFT (fino al 21 ottobre 2026) | Alpenglow Votor (da allora) | |
|---|---|---|
| Voti | transazioni on chain con lockout | inviati direttamente tra validatori, aggregati come certificati BLS |
| Definitivo quando | 32 voti di profondità (radice); confermato ai due terzi dello stake | 80% notarizza in un round, oppure 60% in due round |
| Tempo tipico | circa 12,8 s con slot da 400 ms | circa 150 ms mediani, obiettivo di progetto |
| Modello di guasto | meno di un terzo bizantino | 20% bizantino più 20% offline |
| Tempo | catena di hash PoH, 64 tick per slot | timeout locali; un tick di chiusura da un solo hash |
| Costo del voto | circa 1 SOL al giorno in commissioni | ticket di ammissione di circa 0,8 SOL al giorno, bruciato |
| Tetto ai validatori | nessuno | 2.000 con più stake |
| Diffusione dei blocchi | Turbine | Turbine (Rotor previsto) |
Blackout di Solana: perché i fermi hanno pesato più dell’orologio
Il problema di reputazione di Solana non è mai stata la velocità dell’orologio. È stato il fermarsi della rete. Sei blocchi totali tra settembre 2021 e febbraio 2024 sono durati da circa quattro ore e mezza a circa 20 ore ciascuno, e aiutano a spiegare perché i validatori abbiano accettato sia un secondo client sia la sostituzione completa del consenso.
| Data (UTC) | Durata approssimativa | Che cosa è successo |
|---|---|---|
| 14-15 settembre 2021 | circa 17 ore | le transazioni dei bot che inondavano la vendita di token Grape Protocol su Raydium hanno esaurito la memoria dei validatori; riavvio coordinato dagli operatori |
| 30 aprile-1 maggio 2022 | circa 7 ore | bot in gara per coniare NFT tramite la Candy Machine di Metaplex hanno saturato i leader; i validatori hanno finito la memoria; riavvio completato verso le 03:00 UTC |
| 1 giugno 2022 | circa 4,5 ore | un bug nella gestione delle transazioni con durable nonce ha diviso i validatori; fermo verso le 16:30 UTC, ripartenza alle 21:00 UTC |
| 30 settembre-1 ottobre 2022 | circa 8 ore | un nodo hot-spare mal configurato ha prodotto blocchi duplicati e un bug nella scelta del fork ha fermato la produzione di blocchi; stop alle 22:41 UTC, ripartenza verso le 07:00 UTC |
| 25-26 febbraio 2023 | quasi 20 ore (stime della stampa) | la finalizzazione si è degradata durante l’aggiornamento dalla versione 1.13 alla 1.14; riavvio sulla 1.13.6, primo tentativo abbandonato |
| 6 febbraio 2024 | circa 5 ore | ciclo infinito di ricompilazione nella cache dei programmi della v1.17; finalizzazione ferma alle 09:53 UTC, ripresa alle 14:55 UTC |
6 febbraio 2024, l’ultimo fermo totale
Il report di Anza sul blackout di febbraio 2024 lo riconduce alla cache che conserva i programmi compilati just in time. Un programma che usava un loader legacy, distribuito in una sequenza particolare, mandava i validatori in un ciclo infinito di ricompilazione. Oltre il 95% dello stake eseguiva la stessa release v1.17, quindi quasi tutti i validatori si sono bloccati sullo stesso blocco, nessuno ha votato e la finalizzazione si è fermata alle 09:53 UTC. Gli ingegneri hanno rilasciato la v1.17.20 con una correzione mirata verso le 12:34 UTC, e il consenso è ripreso alle 14:55 UTC dopo un riavvio coordinato. Un bug simile aveva colpito la devnet una settimana prima.
Il fermo del 2021 era diverso per natura. La prima ricostruzione della Solana Foundation descriveva bot che inondavano una vendita di token finché i validatori non hanno esaurito la memoria, e gli ingegneri hanno impiegato circa 14 ore per scrivere una correzione e coordinare il riavvio. Il fattore scatenante era il carico, non un singolo percorso di codice. Lo stesso schema è tornato il 30 aprile 2022, quando i bot per il minting di NFT hanno sommerso la rete per circa sette ore, e gli aggiornamenti successivi al modo in cui i leader accettano le transazioni, i cambiamenti QUIC e pesati per stake descritti sopra, hanno puntato proprio a quella debolezza.
1.000 giorni senza fermi, e un client di troppo
Da allora non è stato segnalato alcun fermo totale. Crypto Briefing ha contato 1.000 giorni consecutivi senza fermi di rete intorno al 2 novembre 2026, e ha scritto che la pagina di stato di Solana aveva mostrato un uptime del 100% nei mesi precedenti. La pagina di stato stessa non elencava incidenti sulla mainnet nelle due settimane fino all’8 novembre. L’episodio di febbraio 2024 mostra il rischio che resta: quando quasi tutto lo stake esegue lo stesso codice, un solo bug ferma tutti insieme. Secondo la sua specifica, Alpenglow continua a finalizzare con fino al 40% di stake in crash, e non oltre; software identico tende a cadere insieme.
È la ragione di Firedancer, un client validatore indipendente scritto da zero da un team di Jump Crypto. La sua pagina delle release su GitHub elenca la v26.10.6 come release pronta per la mainnet il 5 novembre 2026; il supporto ad Alpenglow ha raggiunto per la prima volta una release pronta per la mainnet con la v26.10.2 il 14 ottobre. All’8 novembre 2026 non era disponibile alcun tracker neutrale e pubblicato delle quote dei client. La lettura Coindaro dell’elenco pubblico dei nodi di quel giorno ha trovato 92 nodi votanti con circa il 15,6% dello stake attivo su stringhe di versione che iniziano per «26.», in linea con la numerazione anno-mese di Firedancer, mentre i nodi con versioni «4.», la linea Agave e i fork come il client di Jito, ne detenevano circa l’83,5%. Altri sei eseguivano versioni «0.», la numerazione di Frankendancer, un ibrido che affianca la rete di Firedancer al runtime di Agave, per circa lo 0,6%. Questa ripartizione è un’inferenza di Coindaro dalle etichette di versione, non una cifra pubblicata dagli sviluppatori.
Chi governa Solana all’8 novembre 2026
Le soglie di Alpenglow rendono leggibile la concentrazione dello stake: il 20% è il budget malevolo del suo modello di guasto, il 40% il budget di crash, l’80% il percorso veloce. La tabella conta i vote account, dal più grande in giù, necessari per raggiungere ogni soglia.
| Misura (RPC pubblica, 8 novembre 2026, circa 10:00 UTC) | Valore |
|---|---|
| Vote account con stake attivo | 697 (662 che votano, 35 delinquent) |
| Stake attivo | circa 434,8 milioni di SOL |
| Vote account più grandi che detengono il 20% dello stake | 8 |
| Che detengono un terzo | 18 |
| Che detengono metà | 40 |
| Che detengono due terzi | 78 |
| Necessari per l’80% (fast finalization) | 141 |
| Quota dei 10 più grandi | 24,6% |
| Nodi visibili nel gossip (include RPC e nodi non votanti) | 3.843 |
Un vote account non è un’azienda. Un operatore può farne girare diversi, e lo stake delegato tramite exchange e servizi di staking può dipendere da meno mani di quanto la tabella lasci intendere, quindi la concentrazione reale può essere soltanto più alta di questi conteggi. Letti con questa avvertenza, otto vote account detengono già il 20% che il modello di Alpenglow tratta come massimo malevolo, e il percorso veloce richiede 141 account per rispondere nello stesso round. Chainspect, che pubblica i coefficienti di Nakamoto di molte catene, mostrava lo stesso giorno 17 per Solana su 664 validatori, vicino ai 18 vote account della tabella. Su come la delega plasmi questi numeri in altre reti, si veda la nostra lezione sulla delegated proof of stake.
Che cosa lascia la proof of history
La proof of history di Solana ha fatto bene un lavoro solo: ha trasformato una funzione di hash in un metronomo che ogni validatore poteva controllare, e ha permesso ai leader di darsi il turno senza chiedere. Non ha mai deciso quali blocchi fossero definitivi e, dal 21 ottobre 2026, non scandisce più nemmeno il tempo. Se ne occupano timer locali, e i voti viaggiano fuori dalla catena come certificati.
Restano due cose da vedere. Rotor dovrebbe sostituire Turbine con una proposta propria, e l’obiettivo di finalità di 150 millisecondi attende ancora una misura indipendente sulla mainnet. La prossima lezione di questo percorso, i meccanismi di consenso a confronto, mette la proof of history, Alpenglow e le altre famiglie fianco a fianco in un’unica tabella.
