Solana riduce i tempi di blocco del 17%, portandoli a 250 millisecondi
Punti chiave
- •Solana ha ridotto il tempo target di slot da 300 a 250 millisecondi il 18 settembre 2026, con l'attivazione della quarta fase di SIMD-0525 all'inizio dell'epoca 1037.
- •La produzione di blocchi è salita a quattro slot al secondo da circa 3,3, ma la throughput delle transazioni non è aumentata, poiché i limiti di calcolo per slot sono stati ridotti da 60 a 37,5 milioni e i limiti di data shred sono stati diminuiti.
- •Il principale beneficio pratico è una maggiore freschezza dei dati, con prezzi, stati degli account e finestre dei blockhash che si aggiornano più frequentemente, anziché una maggiore capacità grezza.
- •La durata dell'epoca si è compressa da circa 36 ore a circa 30 ore, con effetti su validatori, distribuzione delle ricompense di staking e protocolli legati ai confini di epoca.
- •L'obiettivo finale di 200isecondi, già sperimentato su devnet e testnet, dipende dal mantenimento del tasso di blocco saltato sul mainnet entro limiti accettabili, con le finestre di controllo dei leader ridotte da 1,2 a 1 secondo.

Solana ha inasprito la propria cadenza di produzione dei blocchi, attivando il 18 settembre 2026 la riduzione del tempo target di slot da 300 a 250 millisecondi, in coincidenza con l'inizio dell'epoca 1037. La modifica porta la produzione di blocchi a quattro slot al secondo, rispetto ai circa 3,3 slot al secondo precedenti — una riduzione di circa il 17% del tempo di slot. Il tempo di slot è l'intervallo di cui ogni validatore dispone per produrre un blocco, e costituisce quindi la misura più diretta della rapidità con cui il nuovo stato della rete diventa disponibile.
L'attivazione segna la quarta fase di SIMD-0525, una proposta graduale intesa a inasprire progressivamente la cadenza dei blocchi di Solana, con l'obiettivo finale di 200 millisecondi per slot.
Blocchi più veloci, non più capacità
Controintuitivamente, blocchi più veloci non si traducono in un numero maggiore di transazioni al secondo. Per mantenere la rete stabile, Solana ha ridotto proporzionalmente i limiti di calcolo e di dati per slot a fianco della modifica dei tempi. Le unità di calcolo massime per slot sono scese a 37,5 milioni da una base di 60 milioni, e i limiti di data shred sono stati adeguati nella stessa direzione.
Tempo di blocco e throughput vengono spesso confusi nei confronti del settore, ma misurano cose diverse — la frequenza con cui arrivano nuovi blocchi rispetto a quanto ccuno può trasportare. Il beneficio pratico in questo caso non risiede nella throughput grezza, ma nella freschezza dei dati. Prezzi, stati degli account e finestre dei blockhash si aggiornano tutti più frequentemente — un cambiamento di enorme importanza per le applicazioni che dipendono da informazioni aggiornate, poiché si passa meno tempo ad agire su uno stato obsoleto.
Anche la durata dell'epoca si è contratta. Poiché le epoche sono definite dal numero di slot e non dal tempo calendario, lo slot più corto comprime tutto ciò che è ancorato ai confini di epoca. Con 250 millisecondi per slot, l'epoca di Solana dura ora circa 30 ore, rispetto alle circa 36 precedenti. Ciò riguarda i validatori, la distribuzione delle ricompense di staking e qualsiasi protocollo che agganci la tempistica ai confini di epoca.
Un rilascio graduale con una roadmap chiara
SIMD-0525 è avanzata attraverso passi deliberati rather che un unico salto. La prima riduzione sul mainnet ha portato i tempi di slot a 350 millisecondi il 19 agosto 2026. La seconda li ha abbassati a 300 millisecondi il 25 agosto 2026. L'attivazione del 18 settembre è la quarta fase, il che significa che un terzo passo è avvenuto tra fine agosto e metà settembre.
L'obiettivo finale di 200 millisecondi è già stato sperimentato sia su devnet che su testnet. Tra questo traguardo e l'attivazione sul mainnet c'è il tasso di blocco saltato: i validatori di Solana occasionalmente non riescono a produrre lo slot assegnato, e finestre temporali più ristrette riducono la tolleranza per tali mancate produzioni. La comunità di sviluppo centrale vuole confermare che il tasso di blocco saltato resti entro limiti accettabili prima di rendere operativa la riduzione finale.
Anche le finestre di controllo dei leader si sono inasprite con questa modifica, passando da 1,2 a 1 secondo — quattro slot consecutivi per leader alla nuova cadenza. I validatori ora hanno meno tempo per trasmettere i propri blocchi — una delle variabili che influenzano il tasso di blocco saltato. Con le finestre più ristrette ormai attive, il comportamento del tasso di blocco saltato sul mainnet è la metrica da osservare mentre la comunità valuta l'ultimo passo verso i 200 millisecondi.