{"id":40,"date":"2026-06-25T13:46:27","date_gmt":"2026-06-25T13:46:27","guid":{"rendered":"https:\/\/hoge.gg\/at\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-06-25T13:46:27","modified_gmt":"2026-06-25T13:46:27","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/at\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"Solanas Mainnet-Upgrade halte die Best\u00e4tigungs-Latenz stillschweigend um die H\u00e4lfte"},"content":{"rendered":"\r\n

In der Nacht des 18. April \u00fcberschritt das Solana mainnet-beta Cluster die Beteiligungsschranke f\u00fcr den v1.18.15 Client<\/a> mit wenig Aufsehen und ohne Ank\u00fcndigungs-Post. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana<\/a> nutzen, mediane optimistische Best\u00e4tigungszeiten von rund 240 ms, ein R\u00fcckgang gegen\u00fcber dem 460\u2013500 ms-Band, das Solana f\u00fcr den Gro\u00dfteil von 2025 definiert hatte. Die \u00c4nderung war das kumulative Ergebnis von drei zusammengef\u00fchrten Proposals — SIMD-0123 zur Block-Reward-Verteilung, SIMD-0096 zur Priority-Fee-Verarbeitung und eine ruhigere Reihe von Patches zur TowerBFT-Vote-Credit-Abrechnung —, die unter einem einzigen Feature-Gate ausgerollt wurden. Niemand hielt eine Launch-Veranstaltung. Das Cluster wurde einfach schneller.<\/p>\r\n\r\n\r\n\r\n

Was auf dem Spiel steht, ist der Teil von Solana, den die meisten Nutzer tats\u00e4chlich sp\u00fcren: nicht theoretische Durchsatzraten, sondern die wahrgenommene L\u00fccke zwischen dem Klicken eines Swaps auf Jupiter und der Best\u00e4tigung. F\u00fcr DeFi-Plattformen, die auf dem Netzwerk laufen — Perps auf Drift, das Orderbuch auf Phoenix, die strukturierten Produkt-Vaults auf Adrastea — ver\u00e4ndert die Halbierung des optimistischen Best\u00e4tigungszeitraums die Wirtschaftlichkeit des Market-Making. F\u00fcr Wallets \u00e4ndert es die UX-Versprechung. Und f\u00fcr die Validator-Economy verschafft es eine Neuverteilung, wer w\u00e4hrend der Kongestion was verdient. Die Kopfzahl, 240 ms, ist das wichtigste St\u00fcck Solana-Infrastruktur-News des Quartals, und fast niemand au\u00dferhalb des Validator-Discords hat es bemerkt (die FMA, die \u00f6sterreichische Finanzmarktaufsicht, w\u00e4re hier die lokal relevante counterpart zu den Regulatoren).<\/p>\r\n\r\n\r\n\r\n

Zwei Best\u00e4tigungen, ein Cluster: warum der Weg z\u00e4hlt<\/h2>\r\n\r\n\r\n\r\n

Vor v1.18 boten Solana-Clients zwei unterschiedliche Best\u00e4tigungswege. Der erste, \u201eoptimistische Best\u00e4tigung”, feuert, wenn eine Supermajorit\u00e4t von stake-gewichteten Vote-Credits innerhalb des TowerBFT-Lockout-Schemas auf einem bestimmten Fork landet. Der zweite, \u201erooted”, feuert erst, wenn dieser Fork mindestens 32 Slots tief ist und durch die Konsens-Pipeline finalisiert wurde. Die optimistische Latenz ist das, was Wallets den Nutzern zeigen; die rooted-Latenz ist das, was Bridges und Exchanges warten. Die Konsens-Dokumentation<\/a> beschreibt beide, aber die praktische Asymmetrie — optimistisch ist schnell und probabilistisch, rooted ist langsam und final — war stets Solanas zentrales UX-Trade-off.<\/p>\r\n\r\n\r\n\r\n

Die v1.18-Linie hat die Architektur dieser Wege nicht ge\u00e4ndert. Sie hat den Wettbewerb um sie ver\u00e4ndert. Vote-Transaktionen auf Solana teilen denselben Scheduler wie User-Transaktionen, und auf einem konzentrierten Block musste der Leader historisch gesehen harte Entscheidungen \u00fcber die Aufnahme von Votes machen. Sp\u00e4te Votes bedeuten verz\u00f6gerte optimistische Best\u00e4tigung. Die SIMD-0123-\u00c4nderungen, die im Cluster-Verhalten bei Slot 261.498.112 zusammengef\u00fchrt wurden, dr\u00e4ngen die Vote-Aufnahme vor Priority-Fee-Transaktionen im Scheduler-Queue und reservieren einen festen Anteil der Block-Compute f\u00fcr sie. Der Effekt, der innerhalb von 48 Stunden in Dune-Dashboards<\/a> beobachtbar war, war, dass die Varianz der optimistischen Best\u00e4tigungs-Latenz kollabiert.<\/p>\r\n\r\n\r\n\r\n

Die Zahlen, vor und nach<\/h2>\r\n\r\n\r\n\r\n
Metric<\/th>v1.17.31 (M\u00e4rz 2026)<\/th>v1.18.15 (Mai 2026)<\/th>Change<\/th><\/tr><\/thead>
Optimistic confirmation, p50<\/td>478 ms<\/td>241 ms<\/td>−49.6%<\/td><\/tr>
Optimistic confirmation, 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 inclusion rate per slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Skipped-slot rate, 7-day<\/td>4.8%<\/td>3.1%<\/td>−1.7 pp<\/td><\/tr><\/tbody><\/table>
Medianmessungen aus einer Stichprobe von 200 mainnet-beta-Validatoren, w\u00f6chentliche Fenster. Quellen: solana.com Cluster-Metriken, jito.network Telemetrie.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

Die zwei Zahlen, die z\u00e4hlen, sind der p99-Kollaps und die flache Finalit\u00e4t. Die p99-Zahl zeigt, was die worst 1% der Nutzer erleben — der Trader, der genau \u201econfirm” geklickt hat, als ein Pump.fun-Launch den Queue des Leaders saturiert hat. Die Reduktion von 1,8 Sekunden auf unter 700 ms entfernt die worst Kategorie von UX-Failure auf dem Netzwerk. Die flache Finalit\u00e4tszahl ist die Beruhigung: nichts am Sicherheitsmodell hat sich ge\u00e4ndert. Die rooted-Best\u00e4tigung ist weiterhin durch dieselbe 32-Slot-Lockout-Disziplin gesperrt, die TowerBFT seit 2020 verwendet. Solana wurde an der Oberfl\u00e4che schneller und blieb im Kern gleich.<\/p>\r\n\r\n\r\n\r\n

SIMD-0123 und der Scheduler-Rewrite<\/h2>\r\n\r\n\r\n\r\n

SIMD-0123 wurde von Core-Engineers bei Anza, dem Team, das 2024 aus Solana Labs geforkt ist, mit Review des Jito-Teams erstellt. Das Proposal liegt im solana-improvement-documents Repository<\/a> als 14-seitiges Spec und enth\u00e4lt zwei strukturell separate Ideen. Die erste ist eine deterministische Priorit\u00e4t f\u00fcr Konsens-Votes im Banking-Stage-Scheduler. Votes werden mit einem unterscheidenden Transaktionstyp gekennzeichnet und durch eine parallele Pipeline geroutet; User-Transaktionen k\u00f6nnen sie nicht mehr verdr\u00e4ngen. Die zweite ist eine Reward-Redistribution: ein Anteil der Priority-Fees, der zuvor ausschlie\u00dflich dem Block-Leader accruiert ist, wird nun \u00fcber den aktiven Vote-Set verteilt, gewichtet nach der Lateness-Penalty, die jeder Validator vermieden hat.<\/p>\r\n\r\n\r\n\r\n

Dieser zweite Teil ist der politisch interessante. Solana-Validatoren haben zwei Jahre \u00fcber MEV-Capture und die Rolle des Jito-Auction-Clients<\/a> diskutiert, der nun auf rund 92% des Stake l\u00e4uft. SIMD-0123 aboliert die Auction nicht. Es \u00e4ndert das Incentive: Leaders, die die Vote-Aufnahme verz\u00f6gern, um ihren eigenen Priority-Fee-Take zu maximieren, verlieren nun einen Anteil dieser Fees an Validatoren, die rechtzeitig votiert haben. Im Effekt hat Solana eine soft-Penalty f\u00fcr selbstische Leadership eingef\u00fchrt, ohne die Konsens-Regeln zu touchieren. Es ist die Art von \u00c4nderung, die auf Ethereum einen Hard-Fork und eine sechsmonatige All-Core-Devs-Debatte erfordert h\u00e4tte; auf Solana war es ein Feature-Gate, das am Donnerstag umgeschaltet wurde.<\/p>\r\n\r\n\r\n\r\n

Warum das Firedancer-Team wichtig war, obwohl sie nicht shipped haben<\/h2>\r\n\r\n\r\n\r\n

Firedancer, der Jump Crypto C++-Rewrite des Validator-Clients, war nicht Teil dieses Upgrades. Der vollst\u00e4ndige Mainnet-Deployment bleibt f\u00fcr Ende 2026 mit Frankendancer — einem Hybrid-Client, der Firedancers Networking-Stack \u00fcber dem Rust-Executor l\u00e4uft — live auf rund 4% des Stake. Aber die Existenz von Firedancer hat ge\u00e4ndert, was im Rust-Client politisch m\u00f6glich war. Anza-Engineers haben auf Breakpoint-Konferenzen<\/a> \u00fcber den Druck gesprochen, den ein zweiter High-Performance-Client auf die Referenz-Implementierung legt: Scheduler-Entscheidungen, die zuvor als \u201eder einzige Weg, wie Rust mithalten kann” verteidigt wurden, werden schwieriger zu justify, wenn eine parallele C++-Codebase schneller benchmarkt.<\/p>\r\n\r\n\r\n\r\n

Der Vote-Scheduler-Rewrite, der in 1.18.15 gelandet ist, \u00fcbernimmt direkt Firedancers Banking-Stage-Architektur, wo Vote- und User-Transaktions-Pipelines von Anfang an nie coupled waren. Anza hat im Wesentlichen das sauberere Design in den Rust-Client backported, den Latenz-Win genommen und die L\u00fccke reduziert, die Firedancer \u00f6ffnen sollte. Ob das Firedancers Value Proposition verz\u00f6gert, ist nun ein Thema des stillen Debatten bei den Validator-Operatoren, die wir f\u00fcr diesen Artikel gesprochen haben, von denen keiner on the record sprechen wollte. Der competitive dynamic zwischen zwei Production-Clients produziert jedoch unabh\u00e4ngig davon ein schnelleres Netzwerk f\u00fcr End-Nutzer.<\/p>\r\n\r\n\r\n\r\n

Was das f\u00fcr DeFi-Plattformen \u00e4ndert<\/h2>\r\n\r\n\r\n\r\n

Die Halbierung der optimistischen Best\u00e4tigungs-Latenz f\u00fchlt sich nicht nur nicer an. Es \u00e4ndert die Parameter, die Market-Makers in ihre Quotes price. Ein Perpetuals-Venue wie Drift, das auf Oracle-Updates innerhalb eines engen Zeitraums vor Liquidationen angewiesen ist, kann nun die Sicherheitsmarge, die es f\u00fcr diese Oracle-Prints ben\u00f6tigt, verengen. Das Team hat noch kein aktualisiertes Risk-Model ver\u00f6ffentlicht, aber das relevante Drift-protocol Repository<\/a> zeigt Commits in der letzten Fortnight, die den default Oracle-Staleness-Threshold von 25 Slots auf 12 reduziert. Phoenixs CLOB, das Orders innerhalb eines einzigen Slots crossiert, wenn beide Seiten im selben Banking-Stage ankommen, sieht niedrigere Spreads, weil seine Makers Quotes doppelt so oft refreshen k\u00f6nnen, ohne die positional certainty zu verlieren.<\/p>\r\n\r\n\r\n\r\n