Solana News: il tempo di blocco da 350 ms arriverà nell'epoch 1020
Punti chiave
- •La riduzione del tempo di slot del mainnet da 400 millisecondi a 350 millisecondi è prevista per l'epoch 1020.
- •Il changelog di Solana del 6 agosto indica che il feature gate a 350 millisecondi era già attivo su Devnet e Testnet.
- •La proposta è collegata a SIMD-0525, che delinea una sequenza di future riduzioni del target di slot fino a 200 millisecondi.
- •La modifica accorcia l'intervallo target di produzione senza aumentare il limite teorico di calcolo per secondo.
- •Il changelog segnala inoltre aggiornamenti in corso per Agave e Firedancer, lavoro di conformità e miglioramenti legati a Turbine.
Il tempo target di slot del mainnet di Solana dovrebbe passare da 400 millisecondi a 350 millisecondi nell'epoch 1020, dopo un ritardo di un epoch seguito all'attivazione avvenuta all'inizio dell'epoch 1019. La modifica effettiva è prevista per l'epoch 1020.
Il changelog ingegneristico del 6 agosto di Solana conferma che il feature gate per ridurre i tempi di slot da 400 ms a 350 ms era attivo su Devnet e Testnet. Il changelog rimanda inoltre a un imminente calendario dei feature gate e elenca release e lavoro ingegneristico in tutto l'ecosistema Solana.
Il timing target non è lo stesso della produzione effettiva dei blocchi, della latenza di conferma delle transazioni o della finalità economica. La modifica riduce l'intervallo target di produzione senza aumentare l'allocazione di calcolo per secondo.
EXPLORE: Best Memecoins Presales to Watch in 2026
Cosa cambia con il target da 350 ms
Ridurre l'intervallo target da 400 ms a 350 ms lo accorcia di 50 millisecondi. L'aumento teorico della frequenza di schedulazione è di circa il 14,3%, calcolato come 400 diviso 350 meno 1. Questo calcolo descrive solo la cadenza target e non è una previsione del throughput delle transazioni o della velocità di conferma.
La riduzione graduale è collegata alla bozza di proposta SIMD-0525. Secondo la descrizione della proposta riportata nell'articolo, l'account della feature sul mainnet è stato attivato nell'epoch 1019, mentre il target effettivo di 350 ms è rinviato all'epoch 1020.
we're activating 1st slot time reduction on mainnet
help ensure devs are ready because the transition period is wonky…
- We have NOT updated some sdk constants like
DEFAULT_MS_PER_SLOTto reflect new values. Note we will push a release with updated values post activation… — Brennan Watt (@bw_solana) August 18, 2026
Lo stesso report afferma che il budget massimo di calcolo per blocco, nell'esempio, si riduce man mano che gli slot target diventano più brevi. Indica 100 milioni di compute unit a un target di 400 ms e 87,5 milioni di compute unit a 350 ms. Entrambe le cifre corrispondono a un massimo teorico di circa 250 milioni di compute unit al secondo: 100 milioni diviso 0,4 secondi e 87,5 milioni diviso 0,35 secondi.
Quel limite teorico non è una previsione del throughput delle transazioni. L'attività effettiva dipende dal carico di lavoro e dalle condizioni della rete, e un limite massimo di compute per blocco non significa che ogni blocco contenga tale quantità di lavoro.
Solana continuerebbe ad assegnare quattro slot consecutivi a ciascun leader. Con un target di 400 ms, ciò corrisponde a una finestra nominale del leader di 1,6 secondi; con 350 ms, corrisponde a 1,4 secondi. L'intervallo più breve lascia meno tempo ai validatori per ricevere un blocco precedente, riprodurlo, costruirci sopra e registrare i voti prima che la rete passi allo slot successivo.
EXPLORE: Best Memecoins Presales to Watch in 2026
Il percorso graduale verso 200 ms
La sequenza proposta delle riduzioni del target di slot passa da 400 ms a 350 ms, poi a 300 ms, 250 ms e 200 ms. Il report di Solana afferma che Testnet operava con un target effettivo di 200 ms, mentre Devnet era a 300 ms e aveva attivato un gate a 250 ms che non era ancora effettivo.
La modifica a 350 ms sul mainnet va quindi considerata come una fase all'interno di una sequenza proposta più ampia, e non come conferma che ogni obiettivo successivo entrerà in vigore con la stessa tempistica. SIMD-0525 rimane una bozza, e l'attivazione di una feature su un cluster non rende il progetto completo da 200 ms uno standard finale accettato.
The first slot time reduction feature is now live on Solana testnet. SIMD-0525 is active on testnet, reducing slot time from 400ms to 350ms as the first of four feature-gated steps toward 200ms slot time. pic.twitter.com/8XnTu4Byqs — Solana Developers (@solana_devs) August 5, 2026
Il changelog del 6 agosto fornisce anche ulteriore contesto sul lavoro relativo ai client validator. Elenca release per Agave e Firedancer, descrive ulteriore lavoro di conformità su Agave e afferma che Mithril sta mantenendo l'allineamento con la suite di conformità di Agave. Il changelog dice che Mithril è una nuova implementazione di validator scritta in Go che parteciperà presto al consenso, e che il suo lavoro con la suite di conformità è pensato per aiutarla a tenere il passo con Agave.
Il changelog descrive inoltre miglioramenti alla cache di broadcasting del leader Turbine di Agave e alla ricostruzione della routing table. Secondo il changelog, i leader creano blocchi dalle transazioni inviate dalla rete, suddividono i blocchi in shard e li distribuiscono ai validator tramite Turbine.
EXPLORE: Best Crypto Presales to Watch in 2026
The post Solana News: 350ms Block Time Is Coming in Epoch 1020 appeared first on icobench.com .
