Solanas mainnet-opgradering halvede diskret konfirmationslatensen
Solanas v1.18.x-cluster-opgradering og SIMD-0123-udbyringsændringer reducerede den mediane optimistiske konfirmationslatens fra cirka 480 ms til 240 ms. Her er hvad der ændrede sig under dækket.
Om natten den 18. april krydsede Solana mainnet-beta-clusteret deltagelsestærsklen for v1.18.15-klienten med lidt fanfarer og ingen annoncepost. Om morgenen den følgende dag rapporterede validerere, der kørte Jito-Solana, mediane optimistiske konfirmationstider omkring 240 ms, ned fra 460–500 ms-båndet, som havde defineret Solana i det meste af 2025. Ændringen var det kumulative resultat af tre mergede forslag — SIMD-0123 om blokudbyringsfordeling, SIMD-0096 om prioriteringsgebyr-håndtering, og en mere stille sæt af patches til TowerBFT-vote-kreditregnskabet — som udfoldede sig under en enkelt feature gate. Ingen holdt en lanceringsevent. Clusteret blev simpelthen hurtigere.
Hvad der er på spil, er den del af Solana, som de fleste brugere faktisk mærker: ikke teoretisk throughput, men den oplevede afstand mellem at klikke på et swap på Jupiter og se det konfirmere. For DeFi-venue, der kører på netværket — perps på Drift, orderbook på Phoenix, strukturerede produkt-vaults på Adrastea — halvering af optimistiske konfirmationsvinduer ændrer økonomien for markedsmaking. For wallets ændrer det UX-tilbudet. Og for validererøkonomien genfordeler det, hvem hvad får under congestion. Det overskriftsnummer, 240 ms, er den vigtigste del af Solana-infrastrukturnyheder i kvartalet, og næsten ingen udenfor validerer-Discord bemærkede det.
To konfirmationer, et cluster: hvorfor vejen betyder noget
Før v1.18 viste Solana-klienter to forskellige konfirmationsveje. Den første, “optimistisk konfirmation”, affyres når en supermajoritet af stake-weighted vote-kreditter lander på en bestemt fork inden for TowerBFT-lockout-tidsplanen. Den anden, “rooted”, affyres kun når den fork er mindst 32 slots dyb og finaliseret gennem consensus-pipelinen. Optimistisk latens er hvad wallets viser brugere; rooted latens er hvad bridges og exchanges venter på. consensus-dokumentationen beskriver begge, men den praktiske asymmetri — optimistisk er hurtig og probabilistisk, rooted er lang og final — har altid været Solanas centrale UX-handel.
v1.18-linjen ændrede ikke arkitekturen af disse veje. Det ændrede konkurrencen omkring dem. Vote-transaktioner på Solana deler samme scheduler som brugertransaktioner, og på et congested blok har lederen historisk været nødt til at tage hårde valg om hvilke votes at inkludere. Late votes betyder forsinket optimistisk konfirmation. SIMD-0123-ændringerne, mergede i cluster-behandlingen ved slot 261.498.112, skyder vote-inklusion frem for prioriteringsgebyr-transaktioner i scheduler-queue og reserverer et fast stykke af blokcompute for dem. Effekten, observeret i Dune dashboards inden for 48 timer, var at variansen i optimistisk konfirmationslatens kollapserede.
Numrene, før og efter
| Metric | v1.17.31 (marts 2026) | v1.18.15 (maj 2026) | Ændring |
|---|---|---|---|
| Optimistisk konfirmation, p50 | 478 ms | 241 ms | −49,6% |
| Optimistisk konfirmation, p99 | 1.840 ms | 612 ms | −66,7% |
| Rooted (finalized), p50 | 12,8 s | 12,6 s | flat |
| Vote-tx-inklusionsrate per slot | 71% | 96% | +25 pp |
| Skipped-slot-rate, 7-dage | 4,8% | 3,1% | −1,7 pp |
De to numre, der betyder noget, er p99-kollapsen og den flade finalitet. p99-nummeret fortæller dig hvad de worst 1% af brugere oplever — traderen, der klikkede “confirm” præcis når en Pump.fun-lancering saturerede lederens queue. At reducere det fra 1,8 sekunder til under 700 ms fjerner den worst kategori af UX-fejl på netværket. Den flade finalitet er den forsikring: intet om sikkerhedsmodellen ændrede sig. Rooted konfirmation er stadig gated af samme 32-slot-lockout-disciplin, som TowerBFT har brugt siden 2020. Solana blev hurtigere på overfladen og blev den samme i kernen.
SIMD-0123 og scheduler-genomskrivning
SIMD-0123 blev skrevet af core-ingeniører på Anza, teamet, som forkede ud af Solana Labs i 2024, med review fra Jito-teamet. Forslaget sidder i solana-improvement-documents-repositoriet som en 14-siders spec og indeholder to strukturelt separate idéer. Den første er en deterministisk prioritet for consensus-votes inde i banking-stage-scheduler. Votes er mærkede med en distinktiv transaktionstype og routed gennem en parallel pipeline; brugertransaktioner kan ikke evicte dem. Den anden er en udbyringsgenfordeling: en del af prioriteringsgebyrer, som tidligere akkumulerede eksklusivt til bloklederen, er nu genfordelt over det aktive vote-set, weighted af lateness-penaliteten, som hver validerer undgik.
Den anden del er den politisk interessante. Solana-validerere har brugt to år på at diskutere MEV-capture og rollen af Jito’s auction-klient, som nu kører på cirka 92% af stake. SIMD-0123 afskaffer ikke auction. Det ændrer incitamentet: ledere, som forsinkes vote-inklusion for at maksimere deres eget prioriteringsgebyr-take, nu forfeiter en del af disse gebyrer til validerere, som voted på tid. I virkeligheden introducerede Solana en soft penalty for selvskiftende lederskab uden at røre consensus-regler. Det er den type ændring, som ville have krævet en hard fork på Ethereum og en seks-måneders all-core-devs-debat; på Solana var det en feature gate, som flippede på en torsdag.
Hvorfor Firedancer-teamet betød noget, selvom de ikke leverede
Firedancer, Jump Crypto C++-genomskrivning af validererklienten, var ikke en del af denne opgradering. Dens fulde mainnet-deployment er stadig planlagt til slut 2026 med Frankendancer — en hybrid-klient, som kører Firedancer’s networking-stack oven på Rust-executor — live på cirka 4% af stake. Men eksistensen af Firedancer ændrede hvad der var politisk muligt i Rust-klienten. Anza-ingeniører har talte på Breakpoint-konferencer om pressen, som en anden high-performance-klient lægger på reference-implementeringen: scheduler-valg, som tidligere blev forsvarret som “den eneste måde Rust kan holde op”, bliver sværere at forsvare når en parallel C++-kodebase benchmarkere hurtigere.
Vote-scheduler-genomskrivningen, som landede i 1.18.15, låner direkte fra Firedancer’s banking-stage-arkitektur, hvor vote- og brugertransaktions-pipelines aldrig var coupled i første omgang. Anza backported simpelthen den renere design til Rust-klienten, tog latens-vinduet og reducerede gapet, som Firedancer skulle åbne. Om det forsinkes Firedancer’s value proposition er nu et tema af stille debat blandt validerer-operatører, vi talte til denne del, som ingen ville tale på rekord. Den competitive dynamik mellem to production-klienter producerer dog en hurtigere netværk for end-brugere uanset.
Hvad dette ændrer for DeFi-venue
Halvering af optimistisk konfirmationslatens føles ikke bare bedre. Det ændrer parametre, som markedsmakere priser ind i deres quotes. En perpetuals-venue som Drift, som afhænger af oracle-opdateringer, som lander inden for et tight window før liquidations er triggered, kan nu stramme sikkerhedsmarginen, som det kræver på disse oracle-prints. Teamet har ikke endnu publiceret en opdateret risikomodell, men den relevante Drift-protocol-repositoriet viser commits i de sidste to uger, som reducerer default oracle-staleness-tærsklen fra 25 slots til 12. Phoenix’s CLOB, som krydser orders inde i en enkelt slot når begge sider ankommer i samme banking stage, ser lavere spreads fordi dens makere kan refresh quotes dobbelt så ofte uden at miste positional certainty.
- Wallet UX: Phantom og Solflare viser nu “confirmed” inden for cirka 250 ms af submission for median-transaktionen.
- Bridge-økonomi: Wormhole’s guardian-set poller for finalized slots, ikke optimistiske konfirmationer, så cross-chain finality er unchanged ved ~14 s.
- Liquid-staking: Marinade og Jito’s stake-pool-epoch-boundaries ser tighter unbonding-regnskab fordi vote-kreditter akkumulerer mere predictably.
- Trading-bot-infrastruktur: searchers, som kører Helius eller Triton gRPC-streams, ser nu en fladere latens-distribution, hvilket reducerer værdien af co-located maskiner.
Den del, som marketingmateriel vil lade ude
Der er en pris. At reservere blokcompute for votes betyder at der er mindre af det tilgængelig for alt andet under peak load. Under FORM-token-lanceringen den 22. april — den første store congestion-event efter opgraderingen landede — faldt brugertransaktions-landing-rates til cirka 38% under lanceringen første 90 sekunder, mod en comparable historisk figur af 52% under GOAT-lanceringen i slut 2025. Den deterministiske vote-prioritet virker præcis som designet: når netværket er satureret, kommer votes ind og brugertransaktioner venter. Denne handel var den implicitte pointe af SIMD-0123, og det er ikke unambiguously godt for alle.
Den anden stille konsekvens er for leaderboard af validererudbyringer. Genfordeling-klausulen har flyttet cirka 0,4% af weekly fee-revenue fra top-decile-ledere (largely Jito-aligned, largely kører optimerede banking-stage-forks) mod median-validereren. Det er et lille nummer i absolutte termer og et strukturelt i relative termer: det er første tid, Solana-protokollen har brugt sin egen udbyringsmekanisme til at penalisere behavior, som tidligere blot var misbilliget. Vi forventer næste runde af SIMDs — den public draft-liste har nu 11 forslag i aktiv diskussion — at udvide denne pattern. For mere kontekst om hvordan validererøkonomi skifter over cycles, vores market dashboard tracker stake-weighted yield curve weekly.
Hvad du skal se næste
Tre ting er værd at tracke over de næste to epochs. Den første er om v1.18.15 holder sine latens-numre gennem en sustained congestion-event af mere to timer; FORM-lanceringen var en kort spike, ikke en stress test. Den anden er SIMD-0156-draften, som foreslår at udvide vote-scheduler-prioritet-idéen til oracle-opdatering-transaktioner, som oprinder fra Pyth og Switchboard-programmer — en meget større og mere politisk charged carve-out. Den tredje er Firedancer’s mainnet-roadmap, nu at gapet mellem det og reference-klienten har narrowed. Solana’s engineering-kultur har altid været villig til at ship hard changes hurtigt; denne opgradering er en reminder, at netværkets roadmap stadig er sat af hvad dens core teams kan merge, ikke af hvad dens marketingdepartment annoncerer. For traders, som ser implikationen på liquidity, vores priority-fee tracker updates hver slot, og den kommende Anza-developer-call er på vores events calendar.