{"id":40,"date":"2026-06-25T13:46:42","date_gmt":"2026-06-25T13:46:42","guid":{"rendered":"https:\/\/hoge.gg\/dk\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-06-25T13:46:42","modified_gmt":"2026-06-25T13:46:42","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/dk\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"Solanas mainnet-opgradering halvede diskret konfirmationslatensen"},"content":{"rendered":"\r\n

Om natten den 18. april krydsede Solana mainnet-beta-clusteret deltagelsest\u00e6rsklen for v1.18.15-klienten<\/a> med lidt fanfarer og ingen annoncepost. Om morgenen den f\u00f8lgende dag rapporterede validerere, der k\u00f8rte Jito-Solana<\/a>, mediane optimistiske konfirmationstider omkring 240 ms, ned fra 460\u2013500 ms-b\u00e5ndet, som havde defineret Solana i det meste af 2025. \u00c6ndringen var det kumulative resultat af tre mergede forslag — SIMD-0123 om blokudbyringsfordeling, SIMD-0096 om prioriteringsgebyr-h\u00e5ndtering, og en mere stille s\u00e6t af patches til TowerBFT-vote-kreditregnskabet — som udfoldede sig under en enkelt feature gate. Ingen holdt en lanceringsevent. Clusteret blev simpelthen hurtigere.<\/p>\r\n\r\n\r\n\r\n

Hvad der er p\u00e5 spil, er den del af Solana, som de fleste brugere faktisk m\u00e6rker: ikke teoretisk throughput, men den oplevede afstand mellem at klikke p\u00e5 et swap p\u00e5 Jupiter og se det konfirmere. For DeFi-venue, der k\u00f8rer p\u00e5 netv\u00e6rket — perps p\u00e5 Drift, orderbook p\u00e5 Phoenix, strukturerede produkt-vaults p\u00e5 Adrastea — halvering af optimistiske konfirmationsvinduer \u00e6ndrer \u00f8konomien for markedsmaking. For wallets \u00e6ndrer det UX-tilbudet. Og for validerer\u00f8konomien genfordeler det, hvem hvad f\u00e5r under congestion. Det overskriftsnummer, 240 ms, er den vigtigste del af Solana-infrastrukturnyheder i kvartalet, og n\u00e6sten ingen udenfor validerer-Discord bem\u00e6rkede det.<\/p>\r\n\r\n\r\n\r\n

To konfirmationer, et cluster: hvorfor vejen betyder noget<\/h2>\r\n\r\n\r\n\r\n

F\u00f8r v1.18 viste Solana-klienter to forskellige konfirmationsveje. Den f\u00f8rste, “optimistisk konfirmation”, affyres n\u00e5r en supermajoritet af stake-weighted vote-kreditter lander p\u00e5 en bestemt fork inden for TowerBFT-lockout-tidsplanen. Den anden, “rooted”, affyres kun n\u00e5r 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\u00e5. consensus-dokumentationen<\/a> beskriver begge, men den praktiske asymmetri — optimistisk er hurtig og probabilistisk, rooted er lang og final — har altid v\u00e6ret Solanas centrale UX-handel.<\/p>\r\n\r\n\r\n\r\n

v1.18-linjen \u00e6ndrede ikke arkitekturen af disse veje. Det \u00e6ndrede konkurrencen omkring dem. Vote-transaktioner p\u00e5 Solana deler samme scheduler som brugertransaktioner, og p\u00e5 et congested blok har lederen historisk v\u00e6ret n\u00f8dt til at tage h\u00e5rde valg om hvilke votes at inkludere. Late votes betyder forsinket optimistisk konfirmation. SIMD-0123-\u00e6ndringerne, 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<\/a> inden for 48 timer, var at variansen i optimistisk konfirmationslatens kollapserede.<\/p>\r\n\r\n\r\n\r\n

Numrene, f\u00f8r og efter<\/h2>\r\n\r\n\r\n\r\n
Metric<\/th>v1.17.31 (marts 2026)<\/th>v1.18.15 (maj 2026)<\/th>\u00c6ndring<\/th><\/tr><\/thead>
Optimistisk konfirmation, p50<\/td>478 ms<\/td>241 ms<\/td>−49,6%<\/td><\/tr>
Optimistisk konfirmation, p99<\/td>1.840 ms<\/td>612 ms<\/td>−66,7%<\/td><\/tr>
Rooted (finalized), p50<\/td>12,8 s<\/td>12,6 s<\/td>flat<\/td><\/tr>
Vote-tx-inklusionsrate per slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Skipped-slot-rate, 7-dage<\/td>4,8%<\/td>3,1%<\/td>−1,7 pp<\/td><\/tr><\/tbody><\/table>
Medianm\u00e5linger fra et sample af 200 mainnet-beta-validerere, weekly windows. Kilder: solana.com cluster-metrics, jito.network-telemetri.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

De to numre, der betyder noget, er p99-kollapsen og den flade finalitet. p99-nummeret fort\u00e6ller dig hvad de worst 1% af brugere oplever — traderen, der klikkede “confirm” pr\u00e6cis n\u00e5r 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\u00e5 netv\u00e6rket. Den flade finalitet er den forsikring: intet om sikkerhedsmodellen \u00e6ndrede sig. Rooted konfirmation er stadig gated af samme 32-slot-lockout-disciplin, som TowerBFT har brugt siden 2020. Solana blev hurtigere p\u00e5 overfladen og blev den samme i kernen.<\/p>\r\n\r\n\r\n\r\n

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

SIMD-0123 blev skrevet af core-ingeni\u00f8rer p\u00e5 Anza, teamet, som forkede ud af Solana Labs i 2024, med review fra Jito-teamet. Forslaget sidder i solana-improvement-documents-repositoriet<\/a> som en 14-siders spec og indeholder to strukturelt separate id\u00e9er. Den f\u00f8rste er en deterministisk prioritet for consensus-votes inde i banking-stage-scheduler. Votes er m\u00e6rkede 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.<\/p>\r\n\r\n\r\n\r\n

Den anden del er den politisk interessante. Solana-validerere har brugt to \u00e5r p\u00e5 at diskutere MEV-capture og rollen af Jito’s auction-klient<\/a>, som nu k\u00f8rer p\u00e5 cirka 92% af stake. SIMD-0123 afskaffer ikke auction. Det \u00e6ndrer 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\u00e5 tid. I virkeligheden introducerede Solana en soft penalty for selvskiftende lederskab uden at r\u00f8re consensus-regler. Det er den type \u00e6ndring, som ville have kr\u00e6vet en hard fork p\u00e5 Ethereum og en seks-m\u00e5neders all-core-devs-debat; p\u00e5 Solana var det en feature gate, som flippede p\u00e5 en torsdag.<\/p>\r\n\r\n\r\n\r\n

Hvorfor Firedancer-teamet bet\u00f8d noget, selvom de ikke leverede<\/h2>\r\n\r\n\r\n\r\n

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\u00f8rer Firedancer’s networking-stack oven p\u00e5 Rust-executor — live p\u00e5 cirka 4% af stake. Men eksistensen af Firedancer \u00e6ndrede hvad der var politisk muligt i Rust-klienten. Anza-ingeni\u00f8rer har talte p\u00e5 Breakpoint-konferencer<\/a> om pressen, som en anden high-performance-klient l\u00e6gger p\u00e5 reference-implementeringen: scheduler-valg, som tidligere blev forsvarret som “den eneste m\u00e5de Rust kan holde op”, bliver sv\u00e6rere at forsvare n\u00e5r en parallel C++-kodebase benchmarkere hurtigere.<\/p>\r\n\r\n\r\n\r\n

Vote-scheduler-genomskrivningen, som landede i 1.18.15, l\u00e5ner direkte fra Firedancer’s banking-stage-arkitektur, hvor vote- og brugertransaktions-pipelines aldrig var coupled i f\u00f8rste omgang. Anza backported simpelthen den renere design til Rust-klienten, tog latens-vinduet og reducerede gapet, som Firedancer skulle \u00e5bne. Om det forsinkes Firedancer’s value proposition er nu et tema af stille debat blandt validerer-operat\u00f8rer, vi talte til denne del, som ingen ville tale p\u00e5 rekord. Den competitive dynamik mellem to production-klienter producerer dog en hurtigere netv\u00e6rk for end-brugere uanset.<\/p>\r\n\r\n\r\n\r\n

Hvad dette \u00e6ndrer for DeFi-venue<\/h2>\r\n\r\n\r\n\r\n

Halvering af optimistisk konfirmationslatens f\u00f8les ikke bare bedre. Det \u00e6ndrer parametre, som markedsmakere priser ind i deres quotes. En perpetuals-venue som Drift, som afh\u00e6nger af oracle-opdateringer, som lander inden for et tight window f\u00f8r liquidations er triggered, kan nu stramme sikkerhedsmarginen, som det kr\u00e6ver p\u00e5 disse oracle-prints. Teamet har ikke endnu publiceret en opdateret risikomodell, men den relevante Drift-protocol-repositoriet<\/a> viser commits i de sidste to uger, som reducerer default oracle-staleness-t\u00e6rsklen fra 25 slots til 12. Phoenix’s CLOB, som krydser orders inde i en enkelt slot n\u00e5r begge sider ankommer i samme banking stage, ser lavere spreads fordi dens makere kan refresh quotes dobbelt s\u00e5 ofte uden at miste positional certainty.<\/p>\r\n\r\n\r\n\r\n