Solana porta gli slot a 250 ms, blocchi più rapidi ma capacità invariata

🪙 In Sintesi

• Solana riduce il target degli slot da 300 a 250 ms, passando da circa 3,3 a quattro slot al secondo.
• La capacità teorica non cresce del 17%: SIMD-0525 riduce proporzionalmente compute unit e dati ammessi in ogni slot.
• Epoch, finestre dei leader e scadenza dei blockhash diventano più brevi in tempo reale, con effetti concreti su validator e applicazioni.

Solana ha portato sulla mainnet-beta gli slot da 300 a 250 millisecondi, aumentando di quasi il 17% la frequenza con cui la rete produce nuovi slot. Il cambiamento migliora la granularità temporale e riduce la finestra nella quale un singolo validator controlla l’ordinamento delle transazioni, ma non aumenta nella stessa misura la capacità complessiva della blockchain. È questo il dettaglio tecnico che distingue l’upgrade da una semplice corsa ai TPS: SIMD-0525 riduce insieme alla durata dello slot anche il lavoro massimo consentito all’interno di ciascun blocco, mantenendo pressoché invariato il budget computazionale per secondo. Solana diventa quindi più reattiva, non automaticamente più capiente.

Solana passa da 300 a 250 millisecondi per slot sulla mainnet

Anza ha confermato l’attivazione attraverso il post originale che annunciava il passaggio a 250 ms sulla mainnet-beta. La nuova configurazione è entrata in funzione al confine dell’epoch 1037 dopo il meccanismo di attivazione ritardata previsto dal protocollo. La progressione parte dai precedenti 400 millisecondi e attraversa gli step da 350, 300 e ora 250 ms, lasciando come obiettivo finale i 200 millisecondi. Con il nuovo target la rete può produrre teoricamente quattro slot al secondo invece dei circa 3,3 precedenti.

Poiché ogni validator mantiene quattro slot consecutivi come leader, la sua finestra nominale si riduce da 1,2 secondi a un secondo. È un cambiamento particolarmente rilevante per market maker, oracle e applicazioni finanziarie che dipendono da informazioni di prezzo molto recenti. La rete sta accelerando proprio mentre Solana ha appena triplicato lo spazio disponibile per le singole transazioni, mostrando che latenza e complessità delle operazioni vengono affrontate attraverso upgrade separati.

Leggi anche: Europa stringe sulle crypto mentre XRP Ledger e Solana aumentano la capacità dei pagamenti

Più blocchi non significano il 17% di capacità in più

La specifica tecnica SIMD-0525 pubblicata dalla Solana Foundation chiarisce perché l’aumento della frequenza non deve essere tradotto automaticamente in maggiore throughput. A ogni riduzione della durata degli slot vengono abbassati proporzionalmente anche i limiti di elaborazione. Nel modello base il massimo passa da 45 milioni di compute unit con slot da 300 ms a 37,5 milioni con 250 ms; il limite per gli account scrivibili scende da 18 a 15 milioni di CU, mentre data e coding shreds vengono ridotti da 24.576 a 20.480 per slot. Arrivano quindi più blocchi nello stesso secondo, ma ciascuno può contenere meno lavoro. Il risultato previsto è un throughput computazionale per unità di tempo sostanzialmente stabile. È una scelta deliberata per non ottenere una latenza più bassa caricando contemporaneamente validator, networking e storage di un aumento equivalente del lavoro. La distinzione è importante anche rispetto al recente Transaction V1: portare una transazione fino a 4.096 byte permette operazioni atomiche più complesse, ma non significa moltiplicare i TPS.

Epoch da 30 ore e blockhash più veloci cambiano le assunzioni delle applicazioni

La riduzione degli slot modifica anche tutto ciò che sulla rete utilizza il numero degli slot come approssimazione del tempo. Un epoch Solana resta composto da 432.000 slot, ma con 250 millisecondi la sua durata teorica scende da circa 36 a 30 ore. La proposta mantiene inoltre invariato il numero massimo di entry nella blockhash queue e nelle status cache: un blockhash misurato in un certo numero di slot scade quindi prima in termini di tempo reale. Questo restringe la finestra disponibile per firme offline, approvazioni manuali e workflow nei quali una transazione viene preparata e inviata soltanto in un secondo momento. Anche SDK, RPC client, explorer e applicazioni che utilizzano costanti statiche per trasformare slot in secondi possono iniziare a produrre stime errate. Il problema diventerà ancora più evidente se Solana arriverà ai 200 ms, quando un epoch teorico scenderebbe a circa 24 ore. La trasformazione va letta insieme alla più ampia revisione del protocollo che ha già coinvolto inflazione e incentivi dei validator attraverso SIMD-0550.

Validator e infrastruttura devono processare più eventi nello stesso tempo

Mantenere invariato il throughput teorico non significa che l’upgrade sia gratuito per l’infrastruttura. Con slot più brevi, validator e servizi RPC devono gestire più blocchi individuali, più eventi di voto e maggiore attività di gossip per unità di tempo. La specifica evidenzia inoltre che i validator dispongono di meno tempo per ricevere, effettuare replay e costruire sul blocco prodotto dal leader precedente. Proprio per questo SIMD-0525 procede per step invece di passare direttamente da 400 a 200 millisecondi: ogni fase serve a verificare che block skip, propagazione, replay e sincronizzazione restino entro valori sostenibili. La strategia si collega alla lunga ricerca di maggiore resilienza della rete e alla diversificazione dei client, iniziata anni fa con Firedancer sviluppato da Jump Crypto per ridurre la dipendenza da una singola implementazione. Oggi Agave, Frankendancer e Firedancer devono convergere non soltanto sul contenuto dei blocchi, ma anche su finestre temporali sempre più strette.

Continua con:

• Bitcoin diventa quantum-safe e SWIFT porta la blockchain nel cuore della finanza
• La grande scissione delle crypto: Magic Eden sceglie Solana mentre cambia l’infrastruttura della rete

Il vero obiettivo è abbassare la latenza senza comprare throughput con più carico

Il passaggio a 250 millisecondi mostra una strategia più sofisticata della semplice gara sul numero di transazioni al secondo. Solana sta comprimendo il tempo della rete mantenendo quasi costante il lavoro ammesso per secondo, così da migliorare reattività, freschezza dei dati e rotazione dei leader senza imporre subito un aumento proporzionale del carico computazionale. Per gli utenti l’effetto può tradursi in feedback più rapidi e in una finestra più breve tra variazione del mercato e inclusione di una transazione; per sviluppatori e validator significa invece rivedere assunzioni costruite quando uno slot valeva circa 400 millisecondi. Il prossimo passo previsto da SIMD-0525 è 200 ms, pari a cinque slot al secondo, ma non esiste ancora una data mainnet. La vera misura del successo sarà quindi il comportamento della rete a 250 ms: se block skip e carico operativo resteranno sotto controllo, Solana avrà dimostrato di poter ridurre ulteriormente la latenza senza confondere velocità di produzione dei blocchi con capacità effettiva.