L’aggiornamento del mainnet di Solana ha ridotto silenziosamente la latenza di conferma
L’aggiornamento del cluster v1.18.x di Solana e le modifiche ai reward SIMD-0123 hanno tagliato la latenza di conferma ottimistica mediana da circa 480 ms a 240 ms. Ecco cosa è cambiato sotto il cofano.
La notte del 18 aprile, il cluster mainnet-beta di Solana ha superato la soglia di partecipazione per il client v1.18.15 con poco clamore e senza un post di annuncio. Entro la mattina successiva, i validatori che eseguono Jito-Solana hanno segnalato tempi di conferma ottimistica mediana intorno a 240 ms, in calo rispetto alla fascia 460–500 ms che aveva definito Solana per la maggior parte del 2025. Il cambiamento è il risultato cumulativo di tre proposte merged — SIMD-0123 sulla distribuzione dei reward per blocco, SIMD-0096 sulla gestione delle fee di priorità e un insieme più silenzioso di patch per la contabilità dei crediti di voto TowerBFT — implementate sotto un singolo feature gate. Nessuno ha organizzato un evento di lancio. Il cluster è semplicemente diventato più veloce.
Quello che è in gioco è la parte di Solana che la maggior parte degli utenti percepisce effettivamente: non la capacità teorica, ma il divario percepito tra l’click su uno swap su Jupiter e la sua conferma. Per le piattaforme DeFi che operano sulla rete — perps su Drift, l’orderbook su Phoenix, i vault di prodotti strutturati su Adrastea — ridurre la finestra di conferma ottimistica cambia l’economia del market-making. Per i wallet, cambia la promessa UX. E per l’economia dei validatori, ridistribuisce chi guadagna cosa durante la congestione. Il numero principale, 240 ms, è il pezzo più importante delle notizie infrastrutturali di Solana del trimestre, e quasi nessuno, fuori dal Discord dei validatori (e di Consob, l’ente di vigilanza italiano sui mercati finanziari), ha notato.
Due conferme, un cluster: perché il percorso è importante
Prima di v1.18, i client di Solana esponivano due percorsi di conferma distinti. Il primo, “conferma ottimistica”, si attiva quando una supermaggioranza di crediti di voto ponderati per stake arriva su un particolare fork entro la tabella di lockout TowerBFT. Il secondo, “rooted”, si attiva solo quando quel fork è almeno 32 slot profondo e finalizzato attraverso il pipeline di consenso. La latenza ottimistica è quella mostrata ai utenti dai wallet; la latenza rooted è quella attesa da bridge e exchange. La documentazione sul consenso descrive entrambi, ma l’asimmetria pratica — l’ottimistica è veloce e probabilistica, la rooted è lenta e definitiva — è sempre stato il trade-off UX centrale di Solana.
La linea v1.18 non ha cambiato l’architettura di quei percorsi. Ha cambiato la contenzione intorno a loro. Le transazioni di voto su Solana condividono lo stesso scheduler delle transazioni utente e, in un blocco congestionato, il leader ha dovuto historicamente fare scelte difficili su quali voti includere. Voti tardivi significano conferma ottimistica rallentata. Le modifiche SIMD-0123, merged nel comportamento del cluster allo slot 261.498.112, spingono l’inclusione dei voti prima delle transazioni con fee di priorità nel queue dello scheduler e riservano una porzione fissa di compute del blocco per loro. L’effetto, osservabile nei dashboards di Dune entro 48 ore, è che la varianza nella latenza di conferma ottimistica è collassata.
I numeri, prima e dopo
| Metrica | v1.17.31 (marzo 2026) | v1.18.15 (maggio 2026) | Cambiamento |
|---|---|---|---|
| Conferma ottimistica, p50 | 478 ms | 241 ms | −49,6% |
| Conferma ottimistica, p99 | 1.840 ms | 612 ms | −66,7% |
| Rooted (finalizzata), p50 | 12,8 s | 12,6 s | flat |
| Tasso di inclusione vote-tx per slot | 71% | 96% | +25 pp |
| Tasso di slot saltati, 7 giorni | 4,8% | 3,1% | −1,7 pp |
Le due cifre che contano sono il collasso del p99 e la finalità flat. La cifra p99 ti dice cosa sperimenta l’1% peggiore degli utenti — il trader che ha clickato “conferma” esattamente quando un lancio di Pump.fun ha saturato il queue del leader. Ridurla da 1,8 secondi a meno di 700 ms elimina la categoria peggiore di fallimento UX sulla rete. La cifra di finalità flat è la rassicurazione: nulla è cambiato nel modello di sicurezza. La conferma rooted è ancora gestita dalla stessa disciplina di lockout di 32 slot che TowerBFT ha usato dal 2020. Solana è diventata più veloce in superficie e è rimasta la stessa nel cuore.
SIMD-0123 e la riscrittura dello scheduler
SIMD-0123 è stato scritto da ingegneri core di Anza, il team che si è forkato da Solana Labs nel 2024, con revisione del team Jito. La proposta si trova nel repository solana-improvement-documents come una spec di 14 pagine e contiene due idee strutturalmente separate. La prima è una priorità deterministica per i voti di consenso dentro lo scheduler dello banking-stage. I voti sono etichettati con un tipo di transazione distintivo e instradati attraverso un pipeline parallelo; le transazioni utente non possono più espellerli. La seconda è una redistribuzione dei reward: una porzione delle fee di priorità che prima accresceva esclusivamente al leader del blocco è ora redistribuita tra il set di voti attivo, ponderata per la penalità di ritardo che ogni validator ha evitato.
Questa seconda parte è quella politicamente interessante. I validatori di Solana hanno speso due anni a discutere sulla cattura di MEV e sul ruolo del client di auction di Jito, che ora opera su circa 92% dello stake. SIMD-0123 non abolisce l’auction. Cambia l’incentivo: i leader che rallentano l’inclusione dei voti per massimizzare la propria presa di fee di priorità ora rinunciano a una parte di quelle fee per i validatori che hanno votato in tempo. In effetti, Solana ha introdotto una penalità soft per la leadership egoista senza toccare le regole di consenso. È il tipo di cambiamento che avrebbe richiesto un hard fork su Ethereum e un dibattito di sei mesi tra tutti gli all-core-devs; su Solana è stato un feature gate che è attivato un giovedì.
Perché il team Firedancer è stato importante, anche se non ha consegnato
Firedancer, la riscrittura C++ di Jump Crypto del client validator, non è parte di questo aggiornamento. Il suo pieno deployment mainnet rimane programmato per la fine del 2026 con Frankendancer — un client ibrido che esegue lo stack di networking di Firedancer sopra l’executor Rust — attivo su circa 4% dello stake. Ma l’esistenza di Firedancer ha cambiato ciò che era politicamente possibile nel client Rust. Gli ingegneri di Anza hanno parlato ai congressi Breakpoint sulla pressione che un secondo client ad alte prestazioni mette sull’implementazione di riferimento: le decisioni dello scheduler che prima erano difese come “il solo modo in cui Rust può tenere il passo” diventano più difficili a giustificare quando un codice parallelo C++ è benchmarkato più veloce.
La riscrittura dello scheduler di voti che è arrivata in 1.18.15 prende direttamente dall’architettura dello banking-stage di Firedancer, dove i pipeline delle transazioni di voto e utente non erano mai accoppiati in primo luogo. Anza ha essenzialmente backportato il design più pulito nel client Rust, ha preso il vantaggio di latenza e ha ridotto il gap che Firedancer doveva aprire. Se questo rallenta la proposta di valore di Firedancer è ora un tema di dibattito silenzioso tra gli operatori di validatori che abbiamo intervistato per questo pezzo, nessuno dei quali ha voluto parlare pubblicamente. La dinamica competitiva tra due client di produzione, tuttavia, sta producendo una rete più veloce per gli utenti finali indipendentemente.
Cosa cambia per le piattaforme DeFi
Ridurre la latenza di conferma ottimistica non è solo più piacevole. Cambia i parametri che i market-makers inseriscono nei loro prezzi. Una piattaforma di perpetuals come Drift, che si basa sugli aggiornamenti dell’oracle che arrivano entro una finestra stretta prima che siano attivati i liquidations, può ora stringere il margine di sicurezza che richiede su quelle stampa dell’oracle. Il team non ha ancora pubblicato un modello di rischio aggiornato, ma il repository Drift-protocol rilevante mostra commit nella scorsa fortnight che riducono la soglia di staleness dell’oracle da 25 slot a 12. Il CLOB di Phoenix, che attraversa gli ordini dentro un singolo slot quando entrambi i lati arrivano nello stesso banking-stage, vede spread più bassi perché i suoi makers possono aggiornare i prezzi due volte più spesso senza perdere la certezza posizionale.
- UX Wallet: Phantom e Solflare ora mostrano “confermato” entro circa 250 ms dalla submission per la transazione mediana.
- Economia dei bridge: il set di guardian di Wormhole interroga per slot finalizzati, non per conferme ottimistiche, quindi la finalità cross-chain è invariata a ~14 s.
- Liquid-staking: i confini di epoch dei pool di stake di Marinade e Jito vedono una contabilità di unbonding più stretta perché i crediti di voto accrescono più prevedibilmente.
- Infrastruttura trading-bot: i searchers che eseguono stream gRPC di Helius o Triton ora vedono una distribuzione di latenza più piatta, riducendo il valore delle macchine co-locate.
La parte che i materiali di marketing non includeranno
Ci è un costo. Riservare compute del blocco per i voti significa che c’è meno disponibile per tutto il resto sotto carico di picco. Durante il lancio del token FORM il 22 aprile — il primo evento di congestione importante dopo l’aggiornamento — i tassi di landing delle transazioni utente sono scesi a circa 38% durante i primi 90 secondi del lancio, contro una cifra storica comparabile di 52% durante il lancio GOAT alla fine del 2025. La priorità deterministica dei voti funziona esattamente come progettato: quando la rete è saturata, i voti arrivano e le transazioni utente attendono. Questo trade-off era il punto implicito di SIMD-0123 e non è inequivocabilmente buono per tutti.
L’altra conseguenza silenziosa è per la leaderboard dei reward dei validatori. La clausola di redistribuzione ha spostato circa 0,4% delle fee settimanali dai leader del decile superiore (principalmente allineati a Jito, principalmente che eseguono fork ottimizzati dello banking-stage) verso il validator mediano. È un numero piccolo in termini assoluti e strutturale in termini relativi: è la prima volta che il protocollo Solana ha usato il suo meccanismo di reward per penalizzare un comportamento che prima era solo sconsigliato. Prevediamo che la prossima ronda di SIMDs — la lista pubblica dei draft ora ha undici proposte in discussione attiva — estenderà questo pattern. Per più contesto su come l’economia dei validatori cambia tra i cicli, il nostro dashboard di mercato traccia la curva di rendimento ponderata per stake settimanalmente.
Cosa guardare prossimo
Tre cose sono utili a monitorare nelle prossime due epoche. La prima è se v1.18.15 mantiene i suoi numeri di latenza attraverso un evento di congestione sostenuto di più di due ore; il lancio FORM è stato un picco breve, non un test di stress. La seconda è il draft SIMD-0156, che propone di estendere l’idea di priorità dello scheduler di voti alle transazioni di aggiornamento dell’oracle originarie dai programmi Pyth e Switchboard — un carve-out molto più grande e politicamente carico. La terza è la roadmap mainnet di Firedancer, ora che il gap tra esso e il client di riferimento si è ridotto. La cultura ingegneristica di Solana è sempre stata pronta a consegnare cambiamenti difficili rapidamente; questo aggiornamento è un reminder che la roadmap della rete è ancora definita da ciò che i suoi team core possono merged, non da ciò che il suo dipartimento di marketing annuncia. Per i trader che osservano l’impatto sulla liquidità, il nostro tracker delle fee di priorità si aggiornano ogni slot, e il prossimo call degli sviluppatori di Anza è sul nostro calendario eventi.