{"id":40,"date":"2026-06-25T13:47:14","date_gmt":"2026-06-25T13:47:14","guid":{"rendered":"https:\/\/hoge.gg\/no\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-06-25T13:47:14","modified_gmt":"2026-06-25T13:47:14","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"Solanas mainnet-oppdatering halverte fors\u00f8ksvis bekreftelseslatensiteten uten at det skapte st\u00f8y"},"content":{"rendered":"\r\n

P\u00e5 natten av 18. april krydde Solana mainnet-beta-klusteren delingstresholden for v1.18.15-klienten<\/a> med liten fanfare og ingen annonseside. Ved morgenen dagen etter rapporterte validerere som kj\u00f8rte Jito-Solana<\/a> median fors\u00f8ksvis bekreftelseslatensitet rundt 240 ms, ned fra 460\u2013500 ms-b\u00e5ndet som hadde definert Solana i mesteparten av 2025. Endringen var resultatet av tre sammensl\u00e5tte proposjoner — SIMD-0123 om blokkutbyttefordeling, SIMD-0096 om prioriteringsgebyrh\u00e5ndtering, og en mer stille sett av rettinger til TowerBFT-valideringskredittregnskap — som ble lansert under \u00e9n funksjonsgate. Ingen holdt lanseringsevent. Klusteren ble bare raskere.<\/p>\r\n\r\n\r\n\r\n

Hva som er p\u00e5 spill er den delen av Solana som brukere faktisk merker: ikke teoretisk gjennomstr\u00f8mning, men den opplevde gapet mellom \u00e5 klikke p\u00e5 en swap p\u00e5 Jupiter og se den bekreftes. For DeFi-arenaer som kj\u00f8rer p\u00e5 nettverket — perps p\u00e5 Drift, orderbook p\u00e5 Phoenix, strukturerte produktvault p\u00e5 Adrastea — halvering av fors\u00f8ksvis bekreftelsesvinduer endrer \u00f8konomien for markedsmaking. For lommer endrer det UX-p\u00e5standen. Og for validerere\u00f8konomien endrer det hvem som f\u00e5r hva under belastning. Hovedtallet, 240 ms, er den viktigste delen av Solanas infrastrukturnytt for kvartalet, og nesten ingen utenom validerere-Discord merket det.<\/p>\r\n\r\n\r\n\r\n

To bekreftelser, \u00e9n kluster: hvorfor veien er viktig<\/h2>\r\n\r\n\r\n\r\n

F\u00f8r v1.18 viste Solana-klientene to distinkte bekreftelsesveier. Den f\u00f8rste, “fors\u00f8ksvis bekreftelse”, aktiveres n\u00e5r en supermajoritet av stake-vektede valideringskreditter lander p\u00e5 en bestemt fork innen TowerBFT-lockout-tidsrammen. Den andre, “rotert”, aktiveres bare n\u00e5r den fork er minst 32 slots dyp og finalisert gjennom konsensuspipeline. Fors\u00f8ksvis latensitet er det lommer viser brukere; rotert latensitet er det broer og eksperter venter p\u00e5. Konsensusdokumentasjonen<\/a> beskriver begge, men den praktiske asymmetrien — fors\u00f8ksvis er rask og probabilistisk, rotert er lang og final — har alltid v\u00e6rt Solanas sentrale UX-handling.<\/p>\r\n\r\n\r\n\r\n

v1.18-linjen endret ikke arkitekturen til disse veier. Den endret konkurransen rundt dem. Valideringstransaksjoner p\u00e5 Solana deler samme scheduler som brukertansaksjoner, og p\u00e5 en belastet blokk har lederen historisk m\u00e5ttet gj\u00f8re harde valg om hvilke valideringer \u00e5 inkludere. Siste valideringer betyr forsinket fors\u00f8ksvis bekreftelse. SIMD-0123-endringer, sammensl\u00e5tt i klusteroppf\u00f8rsel ved slot 261 498 112, skyver valideringsinkludering f\u00f8r prioriteringsgebyransaksjoner i scheduler-k\u00f8en og reserverer en fast del av blokkkompute for dem. Effekten, observerbar i Dune-dashboards<\/a> innen 48 timer, var at variasjonen i fors\u00f8ksvis bekreftelseslatensitet kollapset.<\/p>\r\n\r\n\r\n\r\n

Tallene, f\u00f8r og etter<\/h2>\r\n\r\n\r\n\r\n
M\u00e5te<\/th>v1.17.31 (mars 2026)<\/th>v1.18.15 (mai 2026)<\/th>Endring<\/th><\/tr><\/thead>
Fors\u00f8ksvis bekreftelse, p50<\/td>478 ms<\/td>241 ms<\/td>−49,6%<\/td><\/tr>
Fors\u00f8ksvis bekreftelse, p99<\/td>1 840 ms<\/td>612 ms<\/td>−66,7%<\/td><\/tr>
Rotert (finalisert), p50<\/td>12,8 s<\/td>12,6 s<\/td>flat<\/td><\/tr>
Validering-tx-inkluderingrate per slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Utslittet-slot-rate, 7-dager<\/td>4,8%<\/td>3,1%<\/td>−1,7 pp<\/td><\/tr><\/tbody><\/table>
Medianm\u00e5linger fra et utvalg av 200 mainnet-beta-validerere, ukentlige vinduer. Kilder: solana.com-klusterm\u00e5linger, jito.network-telemetri.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

De to tallene som er viktige er p99-kollapsen og den flate finaliteten. p99-tallet forteller deg hva de 1 % av brukere med d\u00e5rligst opplevelse opplever — handelsmannen som klikket “bekreft” akkurat n\u00e5r en Pump.fun-lansering saturerte lederens k\u00f8. \u00c5 kutte dette fra 1,8 sekunder til under 700 ms fjerner den d\u00e5rligste kategorien av UX-feil p\u00e5 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\u00e5 overflaten og holdt seg samme i kjernen.<\/p>\r\n\r\n\r\n\r\n

SIMD-0123 og scheduler-omskrivning<\/h2>\r\n\r\n\r\n\r\n

SIMD-0123 ble skrevet av kjerneingeni\u00f8rer i Anza, teamet som forket ut av Solana Labs i 2024, med gjennomgang fra Jito-teamet. Proposisjonen ligger i solana-improvement-documents-repositoriet<\/a> som en 14-siders spes og inneholder to strukturelt separate ideer. Den f\u00f8rste 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\u00e5 fordelt over det aktive valideringssettet, vektet med latensitetspenaliteten hver validerer unngikk.<\/p>\r\n\r\n\r\n\r\n

Den andre delen er den politisk interessante. Solana-validerere har brukt to \u00e5r p\u00e5 \u00e5 diskutere MEV-kapring og rollen til Jito’s auction-klient<\/a>, som n\u00e5 kj\u00f8rer p\u00e5 cirka 92 % av stake. SIMD-0123 aboliserer ikke auctionen. Den endrer imidlertid incentivet: ledere som forsinket valideringsinkludering for \u00e5 maksimere sitt eget prioriteringsgebyrtak, n\u00e5 mister en del av disse gebyrer til validerere som validerede p\u00e5 tid. I praksis introduserte Solana en svak penalitet for selvledelse uten \u00e5 endre konsensusregler. Det er typen endring som ville ha krevd en hard fork p\u00e5 Ethereum og en seks m\u00e5neders all-core-devs-debatt; p\u00e5 Solana var det en funksjonsgate som flippet p\u00e5 en torsdag.<\/p>\r\n\r\n\r\n\r\n

Hvorfor Firedancer-teamet var viktig, selv om de ikke leverte<\/h2>\r\n\r\n\r\n\r\n

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\u00f8rer Firedancer’s nettverksstack over Rust-executor — live p\u00e5 cirka 4 % av stake. Men eksistensen av Firedancer endret hva som var politisk mulig i Rust-klienten. Anza-ingeni\u00f8rer har snakket ved Breakpoint-konferanser<\/a> om pressen som en annen h\u00f8y-performansklient legger p\u00e5 referanseimplementasjonen: scheduler-valg som tidligere ble forsvarert som “den eneste m\u00e5ten Rust kan holde opp” blir vanskeligere \u00e5 forklare n\u00e5r en parallell C++-kodebase benchmarkr raskere.<\/p>\r\n\r\n\r\n\r\n

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 \u00e5pne. Om dette forsinket Firedancer’s verdiproposisjon er n\u00e5 et tema for stille debatt blant validerereoperat\u00f8rer vi snakket med for denne artikkelen, ingen av dem ville snakke p\u00e5 rekord. Den konkurransedyktige dynamikken mellom to produksjonsklienter, men, produserer en raskere nettverk for endbrukere uansett.<\/p>\r\n\r\n\r\n\r\n

Hva dette endrer for DeFi-arenaer<\/h2>\r\n\r\n\r\n\r\n

Halvering av fors\u00f8ksvis bekreftelseslatensitet f\u00f8les 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\u00f8r liquidasjoner aktiveres, kan n\u00e5 stramme sikkerhetsmarginen som kreves p\u00e5 disse oracle-printene. Teamet har enn\u00e5 ikke publisert en oppdatert risikomodell, men den relevante Drift-protocol-repositoriet<\/a> 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 \u00e9n slot n\u00e5r begge sider kommer i samme banking-stage, ser lavere spreads fordi markedsmakere kan oppdatere tilbud dobbelt s\u00e5 ofte uten \u00e5 miste posisjonskonstans.<\/p>\r\n\r\n\r\n\r\n