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

In der Nacht des 18. April \u00fcberschritt das Solana mainnet-beta-Cluster die Beteiligungsschwellen f\u00fcr den v1.18.15 Client<\/a> mit wenig Aufsehen und ohne Ank\u00fcndigungsbeitrag. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana<\/a> ausf\u00fchren, mediane optimistische Best\u00e4tigungszeiten von etwa 240 ms, ein R\u00fcckgang gegen\u00fcber dem 460\u2013500 ms-Band, das Solana f\u00fcr den gr\u00f6\u00dften Teil von 2025 definiert hatte. Die \u00c4nderung war das kumulative Ergebnis von drei zusammengef\u00fchrten\u63d0\u6848 \u2013 SIMD-0123 zur Verteilung der Blockbelohnungen, SIMD-0096 zur Behandlung der Priorit\u00e4tsgeb\u00fchren und eine ruhigere Reihe von Patches zur Buchhaltung der TowerBFT-Vote-Kredite \u2013, die unter einem einzigen Feature-Gate ausgeliefert wurden. Niemand hielt eine Launch-Veranstaltung ab. Der 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 der theoretische Durchsatz, sondern die wahrgenommene L\u00fccke zwischen dem Klicken auf einen Swap auf Jupiter und dem Best\u00e4tigen. F\u00fcr DeFi-Plattformen, die auf dem Netzwerk laufen \u2013 Perps auf Drift, das Orderbuch auf Phoenix, die strukturierten Produkt-Vaults auf Adrastea \u2013 ver\u00e4ndert die Halbierung des optimistischen Best\u00e4tigungszeitraums die Wirtschaftlichkeit des Market-Making. F\u00fcr Wallets ver\u00e4ndert es die UX-Versprechung. Und f\u00fcr die Validatoren-Wirtschaft verschafft es eine Neuverteilung, wer w\u00e4hrend der \u00dcberlastung was verdient. Die Kopfzahl, 240 ms, ist das wichtigste St\u00fcck Infrastruktur-News von Solana des Quartals, und fast niemand au\u00dferhalb des Validator-Discords hat es bemerkt.<\/p>\r\n\r\n\r\n\r\n

Zwei Best\u00e4tigungen, ein Cluster: warum der Weg wichtig ist<\/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-Kredite innerhalb des TowerBFT-Lockout-Zeitplans auf einem bestimmten Fork landen. Der zweite, \u201erooted”, feuert nur, wenn dieser Fork mindestens 32 Slots tief ist und durch die Konsenspipeline finalisiert wurde. Die optimistische Latenz ist das, was Wallets den Nutzern zeigen; die rooted-Latenz ist das, was Bridges und Exchanges warten. Die Konsensdokumentation<\/a> beschreibt beide, aber die praktische Asymmetrie \u2013 optimistisch ist schnell und probabilistisch, rooted ist langsam und final \u2013 war immer der zentrale UX-Trade-off von Solana.<\/p>\r\n\r\n\r\n\r\n

Die v1.18-Linie \u00e4nderte nicht die Architektur dieser Wege. Sie \u00e4nderte den Wettbewerb um sie. Vote-Transaktionen auf Solana teilen denselben Scheduler wie Benutzer-Transaktionen, und auf einem \u00fcberlasteten 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 Clusterverhalten bei Slot 261.498.112 zusammengef\u00fchrt wurden, dr\u00e4ngen die Vote-Aufnahme vor Priorit\u00e4tsgeb\u00fchren-Transaktionen im Scheduler-Warteschlange und reservieren einen festen Anteil der Block-Compute f\u00fcr sie. Der Effekt, der in Dune-Dashboards<\/a> innerhalb von 48 Stunden beobachtbar war, war, dass die Varianz der optimistischen Best\u00e4tigungs-Latenz kollabierte.<\/p>\r\n\r\n\r\n\r\n

Die Zahlen, vor und nach<\/h2>\r\n\r\n\r\n\r\n
Messwert<\/th>v1.17.31 (M\u00e4rz 2026)<\/th>v1.18.15 (Mai 2026)<\/th>\u00c4nderung<\/th><\/tr><\/thead>
Optimistische Best\u00e4tigung, p50<\/td>478 ms<\/td>241 ms<\/td>−49,6%<\/td><\/tr>
Optimistische Best\u00e4tigung, p99<\/td>1.840 ms<\/td>612 ms<\/td>−66,7%<\/td><\/tr>
Rooted (finalisiert), p50<\/td>12,8 s<\/td>12,6 s<\/td>flat<\/td><\/tr>
Vote-tx-Aufnahmerate per Slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Rate der \u00fcbersprungenen Slots, 7 Tage<\/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 wichtig sind, sind der p99-Kollaps und die flache Finalit\u00e4t. Die p99-Zahl zeigt, was die schlechtesten 1% der Nutzer erleben \u2013 der Trader, der genau \u201econfirm” geklickt hat, als ein Pump.fun-Launch die Queue des Leaders saturierte. Die Reduzierung von 1,8 Sekunden auf unter 700 ms entfernt die schlechteste Kategorie von UX-Fehlern 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-Doktrin begrenzt, 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 die Scheduler-Neuschreibung<\/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 wurde, mit Pr\u00fcfung des Jito-Teams erstellt. Der Proposal befindet sich im solana-improvement-documents Repository<\/a> als 14-seitige Spezifikation und enth\u00e4lt zwei strukturell separate Ideen. Die erste ist eine deterministische Priorit\u00e4t f\u00fcr Konsens-Votes innerhalb des Banking-Stage-Schedulers. Votes werden mit einem unterscheidenden Transaktionstyp gekennzeichnet und durch eine parallele Pipeline geleitet; Benutzer-Transaktionen k\u00f6nnen sie nicht mehr verdr\u00e4ngen. Die zweite ist eine Belohnungsneuverteilung: ein Teil der Priorit\u00e4tsgeb\u00fchren, die zuvor ausschlie\u00dflich dem Block-Leader zugefallen sind, wird nun \u00fcber den aktiven Vote-Set neu verteilt, gewichtet durch die Latenz-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 etwa 92% des Stake l\u00e4uft. SIMD-0123 aboliert den Auction nicht. Es \u00e4ndert jedoch die Incentive: Leaders, die die Vote-Aufnahme verz\u00f6gern, um ihren eigenen Priorit\u00e4tsgeb\u00fchren-Take zu maximieren, verlieren nun einen Anteil dieser Geb\u00fchren an Validatoren, die rechtzeitig votiert haben. In der Tat hat Solana eine weiche Penalty f\u00fcr selbsts\u00fcchtige Leadership eingef\u00fchrt, ohne die Konsensregeln zu \u00e4ndern. Es ist die Art von \u00c4nderung, die auf Ethereum einen Hard-Fork und eine sechsmonatige All-Core-Devs-Diskussion 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 geliefert haben<\/h2>\r\n\r\n\r\n\r\n

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

Die Vote-Scheduler-Neuschreibung, die in 1.18.15 gelandet ist, leitet sich direkt von der Banking-Stage-Architektur von Firedancer ab, wo Vote- und Benutzer-Transaktionspipelines von Anfang an nie gekoppelt waren. Anza hat im Wesentlichen das sauberere Design in den Rust-Client zur\u00fcckportiert, den Latenzgewinn genommen und die L\u00fccke, die Firedancer \u00f6ffnen sollte, reduziert. Ob dies den Wertvorschlag von Firedancer verz\u00f6gert, ist nun ein Thema der ruhigen Diskussion bei den Validator-Operatoren, die wir f\u00fcr diesen Beitrag gesprochen haben, von denen keiner auf der Aufzeichnung sprechen wollte. Der Wettbewerbsdynamik zwischen zwei Produktions-Clients produziert jedoch unabh\u00e4ngig davon ein schnelleres Netzwerk f\u00fcr Endnutzer.<\/p>\r\n\r\n\r\n\r\n

Was dies 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 besser an. Sie \u00e4ndert die Parameter, die Market-Maker in ihre Quotes einrechnen. Eine Perpetuals-Plattform wie Drift, die auf Oracle-Updates innerhalb eines engen Zeitraums vor Liquidationen angewiesen ist, kann nun die Sicherheitsmarge, die sie f\u00fcr diese Oracle-Prints ben\u00f6tigt, verengen. Das Team hat noch kein aktualisiertes Risikomodell ver\u00f6ffentlicht, aber das relevante Drift-protocol Repository<\/a> zeigt Commits in den letzten zwei Wochen, die die Standard-Oracle-Staleness-Schwellen von 25 Slots auf 12 reduziert. Phoenix’s CLOB, das Orders innerhalb eines einzigen Slots kreuzt, wenn beide Seiten im gleichen Banking-Stage ankommen, sieht niedrigere Spreads, weil seine Makers Quotes doppelt so oft aktualisieren k\u00f6nnen, ohne die Positionssicherheit zu verlieren.<\/p>\r\n\r\n\r\n\r\n