Solanas mainnet-oppdatering halverte forsøksvis bekreftelseslatensiteten uten at det skapte støy
Solanas v1.18.x-klustroppdatering og SIMD-0123-utbytteendringer reduserte median forsøksvis bekreftelseslatensitet fra cirka 480 ms til 240 ms. Her er hva som endret seg under panseret.
På natten av 18. april krydde Solana mainnet-beta-klusteren delingstresholden for v1.18.15-klienten med liten fanfare og ingen annonseside. Ved morgenen dagen etter rapporterte validerere som kjørte Jito-Solana median forsøksvis bekreftelseslatensitet rundt 240 ms, ned fra 460–500 ms-båndet som hadde definert Solana i mesteparten av 2025. Endringen var resultatet av tre sammenslåtte proposjoner — SIMD-0123 om blokkutbyttefordeling, SIMD-0096 om prioriteringsgebyrhåndtering, og en mer stille sett av rettinger til TowerBFT-valideringskredittregnskap — som ble lansert under én funksjonsgate. Ingen holdt lanseringsevent. Klusteren ble bare raskere.
Hva som er på spill er den delen av Solana som brukere faktisk merker: ikke teoretisk gjennomstrømning, men den opplevde gapet mellom å klikke på en swap på Jupiter og se den bekreftes. For DeFi-arenaer som kjører på nettverket — perps på Drift, orderbook på Phoenix, strukturerte produktvault på Adrastea — halvering av forsøksvis bekreftelsesvinduer endrer økonomien for markedsmaking. For lommer endrer det UX-påstanden. Og for validerereøkonomien endrer det hvem som får hva under belastning. Hovedtallet, 240 ms, er den viktigste delen av Solanas infrastrukturnytt for kvartalet, og nesten ingen utenom validerere-Discord merket det.
To bekreftelser, én kluster: hvorfor veien er viktig
Før v1.18 viste Solana-klientene to distinkte bekreftelsesveier. Den første, “forsøksvis bekreftelse”, aktiveres når en supermajoritet av stake-vektede valideringskreditter lander på en bestemt fork innen TowerBFT-lockout-tidsrammen. Den andre, “rotert”, aktiveres bare når den fork er minst 32 slots dyp og finalisert gjennom konsensuspipeline. Forsøksvis latensitet er det lommer viser brukere; rotert latensitet er det broer og eksperter venter på. Konsensusdokumentasjonen beskriver begge, men den praktiske asymmetrien — forsøksvis er rask og probabilistisk, rotert er lang og final — har alltid vært Solanas sentrale UX-handling.
v1.18-linjen endret ikke arkitekturen til disse veier. Den endret konkurransen rundt dem. Valideringstransaksjoner på Solana deler samme scheduler som brukertansaksjoner, og på en belastet blokk har lederen historisk måttet gjøre harde valg om hvilke valideringer å inkludere. Siste valideringer betyr forsinket forsøksvis bekreftelse. SIMD-0123-endringer, sammenslått i klusteroppførsel ved slot 261 498 112, skyver valideringsinkludering før prioriteringsgebyransaksjoner i scheduler-køen og reserverer en fast del av blokkkompute for dem. Effekten, observerbar i Dune-dashboards innen 48 timer, var at variasjonen i forsøksvis bekreftelseslatensitet kollapset.
Tallene, før og etter
| Måte | v1.17.31 (mars 2026) | v1.18.15 (mai 2026) | Endring |
|---|---|---|---|
| Forsøksvis bekreftelse, p50 | 478 ms | 241 ms | −49,6% |
| Forsøksvis bekreftelse, p99 | 1 840 ms | 612 ms | −66,7% |
| Rotert (finalisert), p50 | 12,8 s | 12,6 s | flat |
| Validering-tx-inkluderingrate per slot | 71% | 96% | +25 pp |
| Utslittet-slot-rate, 7-dager | 4,8% | 3,1% | −1,7 pp |
De to tallene som er viktige er p99-kollapsen og den flate finaliteten. p99-tallet forteller deg hva de 1 % av brukere med dårligst opplevelse opplever — handelsmannen som klikket “bekreft” akkurat når en Pump.fun-lansering saturerte lederens kø. Å kutte dette fra 1,8 sekunder til under 700 ms fjerner den dårligste kategorien av UX-feil på nettverket. Den flate finalitetstallet er tryggheten: ingenting om sikkerhetsmodellen endret seg. Rotert bekreftelse er fortsatt gitt av samme 32-slot-lockout-disciplin som TowerBFT har brukt siden 2020. Solana ble raskere på overflaten og holdt seg samme i kjernen.
SIMD-0123 og scheduler-omskrivning
SIMD-0123 ble skrevet av kjerneingeniører i Anza, teamet som forket ut av Solana Labs i 2024, med gjennomgang fra Jito-teamet. Proposisjonen ligger i solana-improvement-documents-repositoriet som en 14-siders spes og inneholder to strukturelt separate ideer. Den første er en deterministisk prioritet for konsensusvalideringer innen banking-stage-scheduler. Valideringer er merket med en distinkt transaksjonstype og routet gjennom en parallell pipeline; brukertansaksjoner kan ikke evakuere dem. Den andre er en utbyttefordeling: en del av prioriteringsgebyrer som tidligere kun tilfalt blokklederen, blir nå fordelt over det aktive valideringssettet, vektet med latensitetspenaliteten hver validerer unngikk.
Den andre delen er den politisk interessante. Solana-validerere har brukt to år på å diskutere MEV-kapring og rollen til Jito’s auction-klient, som nå kjører på cirka 92 % av stake. SIMD-0123 aboliserer ikke auctionen. Den endrer imidlertid incentivet: ledere som forsinket valideringsinkludering for å maksimere sitt eget prioriteringsgebyrtak, nå mister en del av disse gebyrer til validerere som validerede på tid. I praksis introduserte Solana en svak penalitet for selvledelse uten å endre konsensusregler. Det er typen endring som ville ha krevd en hard fork på Ethereum og en seks måneders all-core-devs-debatt; på Solana var det en funksjonsgate som flippet på en torsdag.
Hvorfor Firedancer-teamet var viktig, selv om de ikke leverte
Firedancer, Jump Crypto C++-omskrivning av validererklienten, var ikke del av denne oppdateringen. Full mainnet-deployment er fortsatt planlagt for slutten av 2026 med Frankendancer — en hybridklient som kjører Firedancer’s nettverksstack over Rust-executor — live på cirka 4 % av stake. Men eksistensen av Firedancer endret hva som var politisk mulig i Rust-klienten. Anza-ingeniører har snakket ved Breakpoint-konferanser om pressen som en annen høy-performansklient legger på referanseimplementasjonen: scheduler-valg som tidligere ble forsvarert som “den eneste måten Rust kan holde opp” blir vanskeligere å forklare når en parallell C++-kodebase benchmarkr raskere.
Valideringscheduler-omskrivningen som landet i 1.18.15 tar direkte fra Firedancer’s banking-stage-arkitektur, hvor validering og brukertansaksjonspipelines aldri var koblet i utgangspunktet. Anza backporterte renere design til Rust-klienten, tok latensitetsvinn og reduserte gapet Firedancer skulle åpne. Om dette forsinket Firedancer’s verdiproposisjon er nå et tema for stille debatt blant validerereoperatører vi snakket med for denne artikkelen, ingen av dem ville snakke på rekord. Den konkurransedyktige dynamikken mellom to produksjonsklienter, men, produserer en raskere nettverk for endbrukere uansett.
Hva dette endrer for DeFi-arenaer
Halvering av forsøksvis bekreftelseslatensitet føles ikke bare bedre. Det endrer parametrene markedsmakere priser inn i sine tilbud. En perpetuals-arena som Drift, som avhenger av oracle-oppdateringer som lander innen et tett vindu før liquidasjoner aktiveres, kan nå stramme sikkerhetsmarginen som kreves på disse oracle-printene. Teamet har ennå ikke publisert en oppdatert risikomodell, men den relevante Drift-protocol-repositoriet viser commits i de siste to uker som reduserer default oracle-stalenss-treshold fra 25 slots til 12. Phoenix’s CLOB, som krysser ordre innen én slot når begge sider kommer i samme banking-stage, ser lavere spreads fordi markedsmakere kan oppdatere tilbud dobbelt så ofte uten å miste posisjonskonstans.
- Lomme UX: Phantom og Solflare viser nå “bekreftet” innen cirka 250 ms av innsending for mediantransaksjon.
- Broøkonomi: Wormhole’s guardian-sett poller for finaliserte slots, ikke forsøksvis bekreftelser, så cross-chain-finalitet er ubeskåret på ~14 s.
- Liquid-staking: Marinade og Jito’s stake-pool-epochgrenser ser tettere unbonding-regnskap fordi valideringskreditter akkumulerer mer prediktivt.
- Trading-bot-infrastruktur: searchere som kjører Helius eller Triton gRPC-streams ser nå en flatere latensitetsfordeling, noe som reduserer verdien av lokaliserte maskiner.
Den delen markedsføringsmateriell vil la være ute
Det er en kostnad. Å reservere blokkkompute for valideringer betyr at det er mindre av det tilgjengelig for alt annet under toppbelastning. Under FORM-token-lanseringen 22. april — den første store belastningsevent etter oppdateringen landet — falt brukertansaksjonslandingsrate til cirka 38 % i lanseringens første 90 sekunder, mot en historisk tilsvarende figur på 52 % under GOAT-lanseringen i slutten av 2025. Den deterministiske valideringsprioritet fungerer akkurat som designet: når nettverket er saturert, kommer valideringer inn og brukertansaksjoner venter. Denne handlingen var implisitt poenget med SIMD-0123, og det er ikke ubetinget bra for alle.
Den andre stille konsekvensen er for leaderboarden av validerereutbytte. Fordelingsklausulen har flyttet cirka 0,4 % av ukentlig gebyrutbytte fra topp-decile-ledere (hovedsakelig Jito-tilknyttet, hovedsakelig kjører optimerede banking-stage-fork) til medianvaliderer. Det er et smått tall i absolutte termer og et strukturelt i relative termer: det er første gang Solana-protokollen har brukt sitt eget utbyttemekanisme for å penalisere oppførsel som tidligere kun ble mislikt. Vi forventer neste runde av SIMDs — den offentlige utkastlisten har nå 11 proposjoner i aktiv diskusjon — å utvide denne mønster. For mer kontekst om hvordan validerereøkonomi endrer seg over sykluser, vår markedsdashboard følger stake-vektet yieldkurve ukentlig.
Hva du skal se på neste
Tre ting er verdt å følge over de neste to epochene. Den første er om v1.18.15 holder sine latensitetsnummer gjennom en langvarig belastningsevent av mer enn to timer; FORM-lanseringen var en kort spiss, ikke en stress-test. Den andre er SIMD-0156-utkastet, som foreslår å utvide valideringscheduler-prioritetside til oracle-oppdateringstransaksjoner som opprinnelig fra Pyth og Switchboard-programmer — en mye større og mer politisk belastet utskjæring. Den tredje er Firedancer’s mainnet-roadmap, nå at gapet mellom det og referanseklienten har innsnevd. Solanas ingeniørkultur har alltid vært villig til å sende harde endringer raskt; denne oppdateringen er en reminder at nettverkets roadmap fortsatt er satt av hva kjerne-teamene kan sammenslå, ikke av hva markedsføringsdepartementet annonserer. For handelsmenn som ser implikasjonen på likviditet, vår prioriteringsgebyrtracker oppdaterer hver slot, og kommende Anza-utviklercall er på vår events-kalender.