Circa 90 validator Solana che detenevano circa il 29% del SOL in staking hanno perso la connettività durante l'incidente del 12 agosto, e i blocchi hanno impiegato fino a circa 30 minuti per essere finalizzati, rispetto ai consueti 13 secondi, secondo l'analisi dell'incidente di Metrika.

Eppure Solana non è mai andata giù. I blocchi hanno continuato a essere prodotti, e un grafico dell'uptime per la giornata avrebbe mostrato una sessione ordinaria. Mercoledì 21 ottobre la rete è programmata per attivare Alpenglow, un aggiornamento che punta a una finalità di circa 150 millisecondi — ma nulla in esso affronta il problema di hosting alla base del quasi-incidente. Un rapporto di ricerca pubblicato il 16 ottobre dall'unità FCAT di Fidelity, The State of Solana: Network Health and Resilience, stima la più grande rete di hosting a circa il 29% dello stake, vicino alla quota che Metrika ha visto andare offline.

Cosa è successo il 12 agosto

Solana può finalizzare un blocco — il punto in cui una transazione diventa irreversibile — solo mentre più di due terzi del SOL in staking stanno votando, un processo che di norma richiede circa 13 secondi. Il 12 agosto, con circa il 71% dello stake ancora online, la rete è rimasta sopra quella soglia, ma per un soffio. Metrika stima la quota offline al 28,83%, contro un livello del 33,34% al quale la finalizzazione si arresta su tutta la catena.

Grafico: quota di SOL in staking offline il 12 agosto, confrontata con la soglia di arresto della finalità. Fonte: Metrika.

Secondo Metrika, altri quattro o cinque punti percentuali di stake sui percorsi interessati avrebbero significato un arresto dell'intera rete che avrebbe richiesto un ripristino coordinato. Il guasto ha avuto origine nella struttura di TeraSwitch a Miami e si è propagato all'infrastruttura dei validator a Londra, Amsterdam, Francoforte, Singapore e Tokyo, e nella maggior parte dei casi i sistemi di backup dei validator interessati non si sono mai attivati.

TeraSwitch ha risolto il guasto circa dieci minuti dopo la diagnosi, e il traffico è ripreso alle 04:16 UTC, 33 minuti dopo l'inizio. I validator si sono ripresi nei 40 minuti successivi. In quell'intervallo, la quota di slot pianificati senza produzione di blocchi è balzata oltre il 32%, da meno dell'1%. Le transazioni non di voto al secondo sono scese da circa 1.100–1.300 a meno di 300. Per circa mezz'ora nessun blocco è stato finalizzato, e il backlog si è poi svuotato in un picco con una media di circa 1.600 secondi dalla produzione alla finalità.

L'unico numero che non si è mosso è stato l'uptime, rimasto al 100% perché la catena non ha mai smesso di produrrechi. Per circa mezz'ora, però, nessuno poteva dire quando un pagamento sarebbe diventato irreversibile. Metrika, che vende una piattaforma di gestione del rischio per asset digitali e attinge qui ai propri indicatori, considera il ritardo di finalità — non il downtime — l'evento che conta per chi regola fondi su Solana.

Cosa significherebbe — e non significherebbe — una catena bloccata

Il rischio descritto da FCAT è una finalità bloccata e una possibile censura. Una coalizione che detiene più di un terzo dello stake potrebbe impedire al resto di raggiungere i due terzi necessari per la finalizzazione, dice il rapporto, ma non otterrebbe un controllo illimitato sugli asset degli utenti né la capacità di riscrivere transazioni finalizzate. Un guasto di hosting che eliminatesse la stessa quota di stake bloccherebbe la finalità senza che nessuno attacchi nulla.

Quella quota non è difficile da raggiungere. FCAT conta circa 20 identità di validator (18 in un altro passaggio) che detengono più di un terzo dello stake, e dice che quel terzo si trova in due paesi, su due reti di hosting e su due implementazioni client di base. Si tratta di vote account, non di organizzazioni indipendenti: Figment, tra gli altri, gestisce due dei cinque principali validator di quel gruppo. Il giudizio complessivo di FCAT è positivo, citando più di due anni senza grandi interruzioni del mainnet, un successo medio di voto di circa il 99,7% nel 2026 e uno stack software che si sta lentamente diversificando. Indica la concentrazione come il punto da continuare a monitorare. FCAT è l'unità di ricerca tecnologica applicata di Fidelity e gestisce essa stessa un piccolo validator Solana.

A due mesi di distanza, la quota è ancora circa il 29%

Lo snapshot di ottobre di FCAT colloca la più grande rete di hosting a circa il 29% dello stake. Le due cifre misurano cose diverse — lo stake offline durante un guasto e la quota di rete sul totale dello stake — ma convergono nello stesso punto. FCAT dice che la Solana Foundation stava già lavorando per ridurre il predominio di TeraSwitch. Ecco come si articolano i suoi numeri, dalle persone che gestiscono i validator al codice che eseguono:

• 18–20 operatori — identità di validator che detengono oltre un terzo dello stake. Si tratta di vote account, non di organizzazioni indipendenti; Figment gestisce due dei primi cinque del gruppo.
• ~40% localizzazione — quota di stake a Francoforte e Amsterdam. È una stima per geolocalizzazione IP che FCAT dice poter essere imprecisa; circa il 59% si trova in Germania, Paesi Bassi e USA.
• ~29% provider di rete — quota di stake su una sola rete di hosting, secondo lo snapshot di ottobre. Validator in città diverse possono condividere uno stesso provider, e validator nella stessa città possono usarne diversi.
• ~63% software — quota di stake che nel terzo trimestre girava su software basato su Jito, con un altro 26% su Harmonic. La maggior parte delle configurazioni condivide comunque il codice Agave sottostante, quindi un singolo bug lì potrebbe colpirle insieme.

Fonte: FCAT, The State of Solana: Network Health and Resilience (ottobre 2026).

I validator si raggruppano per un motivo. La latenza premia la vicinanza ad altri nodi, nota FCAT, e host specializzati come TeraSwitch e Latitude costruiscono hardware per il carico di lavoro di Solana. Gli operatori hanno protezioni: failover, alimentazione di riserva e reti private come DoubleZero che riducono la dipendenza da internet pubblico. La Foundation ha anche istituito una rete di risposta agli incidenti, SIRN, all'inizio del 2026. Il 12 agosto, però, la maggior parte dei backup non si è mai attivata.

Il limite della Foundation copre circa il 4% dello stake

Il programma di delega della Solana Foundationhttps://solana.org/delegation-criteria) stabilisce la regola principale. Dal 1° maggio 2026, i validator che vogliono lo stake della Foundation devono trovarsi su una rete di hosting sotto un tetto del 25% e in un data center sotto il 15%. Un validator che non rispetta i limiti perde la delega della Foundation finché non li rispetta di nuovo.

I limiti sono entrati in vigore tre mesi prima del guasto di agosto, e secondo lo snapshot di ottobre di FCAT la più grande rete era ancora sopra il tetto. La portata del programma è l'altra metà del problema. Al terzo trimestre aveva delegato a circa il 51% dei validator, ma tali deleghe ammontavano a circa il 4% dello stake attivo. La regola dà ai validator un motivo per diversificare, ma non governa il resto dello stake.

I dati di ottobre di FCAT collocano la più grande rete di hosting a circa il 29% dello stake — sopra il tetto del 25% della Foundation — mentre il programma della Foundation ha delegato circa il 4% dello stake attivo al terzo trimestre.

Cosa risolve Alpenglow — e cosa no

Alpenglow va in produzione sul mainnet nell'epoch 1064, che secondo Solana inizia alle 15:00 UTC circa di mercoledì 21 ottobre; Anza, il team dietro il client Agave, ha indicato le 14:50 circa. Il vecchio sistema di voto continua a girare per i primi 5.000 slot, circa 18 minuti, e il nuovo subentra allo slot 459.653.000. La finalità dovrebbe scendere da circa 12,8 secondi a circa 150 millisecondi, una cifra che Solana descrive come un'aspettativa, non una costante. Wallet e app continuano a funzionare come oggi.

L'aggiornamento non fa nulla per il problema di hosting. Un voto più veloce accorcia il tempo necessario per l'accordo, ma nulla nella [pagina degli aggiornamenti di Solana cambia dove girano i validator o quale provider li connette.

Per ora restringe anche la diversità software. I validator devono eseguire Agave, Jito-Solana o Harmonic Salsa su una release basata su Agave 4.3.0. Firedancer e Frankendancer non sono supportati durante la migrazione, e la pagina di Solana non indica una data per il loro supporto. Firedancer è il codebase indipendente che FCAT definisce la mossa più significativa di Solana verso una diversità di client indipendente. I validator devono inoltre detenere almeno 0,8 SOL oltre al minimo esentato dalla rent nel loro vote account, altrimenti non voteranno né produrranno blocchi nel prossimo epoch.

• Prima — da ora alle 14:50–15:00 UTC circa del 21 ottobre: gli operatori di Firedancer e Frankendancer migrano a un client basato su Agave, e ogni validator votante detiene 0,8 SOL oltre l'esenzione da rent nel proprio vote account.
• Al passaggio — inizia l'epoch 1064: il vecchio sistema di voto gira per i primi 5.000 slot, circa 18 minuti, e Alpenglow subentra allo slot 459.653.000.
• Dopo — cosa cambia per i dati: le transazioni di voto escono dai blocchi, quindi i conteggi delle transazioni scendono; confirmed e finalized diventano lo stesso stato; e i dati di partecipazione si spostano nei certificati nel footer dei blocchi.

Cambia anche il monitoring. L'analisi di Metrika considera i voti per blocco l'indicatore più vicino alla distanza della rete dalla soglia di finalità, perché i voti sono transazioni ordinarie trasportate nei blocchi. Alpenglow toglie i voti dai blocchi, e le note di migrazione di Solana dicono che tutto ciò che misura la partecipazione dei validator analizzando le transazioni di voto avrà bisogno di una nuova fonte, perché quei dati si spostano nei certificati nel footer dei blocchi. Anche i conteggi di transazioni riportati scenderanno senza alcun calo dell'attività reale.

Cosa controllare questa settimana

Se fai staking di SOL: verifica dove è ospitato il tuo validator prima di delegare. Validators.app, la fonte usata da FCAT che dalla Foundation, traccia lo stake per rete di hosting e data center. Un validator sulla più grande rete condivide il rischio di agosto.

Se sviluppi su Solana: aspettati che i dashboard di conteggio transazioni e TPS scendano mercoledì senza variazioni dell'attività reale. Continua a leggere lo stato confirmed finché Alpenglow non è attivo, poi passa a finalized, come consigliano le note di migrazione di Solana. Prima dell'attivazione, finalized significa comunque un'attesa di circa 12,8 secondi. Ricontrolla eventuali timeout o retry calibrati su quel ritardo, e monitora il tempo di finalità insieme all'uptime.

Se gestisci un validator: se usi Firedancer o Frankendancer, passa a un client basato su Agave prima dell'epoch 1064, e verifica che il vote account detenga i 0,8 SOL.

Dopo mercoledì, due numeri valgono la pena di essere osservati: se la quota della più grande rete di hosting scende sotto il tetto del 25% della Foundation, e quando Firedancer sarà di nuovo supportato. Nessuno dei due è in programma per mercoledì.

Questo articolo è fornito a solo scopo informativo e non costituisce consulenza finanziaria o di investimento.