{"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-10-07T03:36:36","modified_gmt":"2026-10-07T03:36:36","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":"\n

In der Nacht des 22. August \u00fcberschritt das Solana mainnet-beta Cluster die Beteiligungsschranke f\u00fcr den ersten Schritt von SIMD-0525<\/a> mit wenig Aufsehen und ohne Ank\u00fcndigungs-Post. Das Upgrade senkte die Ziel-Slot-Zeit von 400 ms auf 350 ms — der Auftakt eines gestaffelten Fahrplans, der das Netzwerk \u00fcber 350 → 300 → 250 → 200 ms f\u00fchren soll. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana<\/a> nutzen, mediane optimistische Best\u00e4tigungszeiten von rund 241 ms, ein R\u00fcckgang gegen\u00fcber dem 460–500 ms-Band, das Solana f\u00fcr den Gro\u00dfteil von 2025 definiert hatte. Die \u00c4nderung war nicht ein einzelner gro\u00dfer Sprung, sondern eine Reihe kleiner Feature-Gates, von denen jedes erst scharf geschaltet wird, wenn die Telemetrie des vorherigen Schritts stabil bleibt. Niemand hielt eine Launch-Veranstaltung. Das Cluster wurde einfach schneller.<\/p>\n\n\n\n

Update (7. Oktober 2026):<\/strong> Dieser Artikel wurde aktualisiert, um den gestaffelten SIMD-0525-Fahrplan abzubilden. Der erste Schritt am 22. August 2026 senkte die Ziel-Slot-Zeit von 400 ms auf 350 ms; ein weiterer Schritt am 18. September 2026 brachte sie von 300 ms auf 250 ms (−16,7 %). Aktuell l\u00e4uft das mainnet-beta bei 250 ms, mit 200 ms — exakt der H\u00e4lfte der urspr\u00fcnglichen 400 ms — als verbleibendem Endziel. Die Telemetrie Ende August zeigte die mediane optimistische Best\u00e4tigung bei 241 ms (von 478 ms, −49,6 %) und die p99 bei 612 ms (von 1.840 ms, −66,7 %).<\/p>\n\n\n\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 verschiebt es, wer w\u00e4hrend der Kongestion was verdient. Die Kopfzahl, 241 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>\n\n\n\n

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

Solana-Clients bieten 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>\n\n\n\n

SIMD-0525 hat die Architektur dieser Wege nicht ge\u00e4ndert. Es hat ihr Tempo ver\u00e4ndert. Optimistische Best\u00e4tigung tritt ein, sobald eine Supermajorit\u00e4t stake-gewichteter Vote-Credits auf einem Fork landet — und Votes werden pro Slot abgegeben. Verk\u00fcrzt man die Ziel-Slot-Zeit, tickt die Uhr, an der sich diese Supermajorit\u00e4t akkumuliert, schneller: von 400 ms \u00fcber die am 22. August aktivierten 350 ms hin zu den seit dem 18. September aktiven 250 ms. Der Effekt, der innerhalb von 48 Stunden nach dem ersten Schritt in Dune-Dashboards<\/a> beobachtbar war, war, dass die optimistische Best\u00e4tigungs-Latenz und ihre Varianz zugleich kollabierten.<\/p>\n\n\n\n

Die Zahlen, vor und nach<\/h2>\n\n\n\n
Metric<\/th>Vor SIMD-0525<\/th>Nach 1. Schritt (Ende Aug. 2026)<\/th>Change<\/th><\/tr><\/thead>
Ziel-Slot-Zeit<\/td>400 ms<\/td>350 ms<\/td>−12.5%<\/td><\/tr>
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><\/tbody><\/table>
Medianmessungen aus einer Stichprobe von mainnet-beta-Validatoren, w\u00f6chentliche Fenster, erhoben nach dem ersten Slot-Zeit-Schritt. Quellen: solana.com Cluster-Metriken, jito.network Telemetrie.<\/figcaption><\/figure>\n\n\n\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>\n\n\n\n

SIMD-0525 und die gestaffelte Slot-Zeit-Reduktion<\/h2>\n\n\n\n

SIMD-0525 wurde von Core-Engineers bei Anza, dem Team, das 2024 aus Solana Labs geforkt ist, erstellt und im solana-improvement-documents Repository<\/a> als Spec gef\u00fchrt. Die Kernidee ist unspektakul\u00e4r und genau deshalb wirkungsvoll: Statt einen einzelnen gro\u00dfen Sprung zu wagen, senkt das Proposal die Ziel-Slot-Zeit in kontrollierten Schritten — von 400 ms auf 350, dann 300, dann 250 und schlie\u00dflich 200 ms. Jeder Schritt ist ein eigenes Feature-Gate, das erst aktiviert wird, wenn die Telemetrie des vorherigen Schritts stabil bleibt. Das Endziel von 200 ms ist exakt die H\u00e4lfte der urspr\u00fcnglichen 400-ms-Slot-Zeit, mit der Solana den Gro\u00dfteil seiner Geschichte lief.<\/p>\n\n\n\n

Der interessante Teil ist das Tempo der Governance, nicht nur das der Slots. Solana-Validatoren betreiben mit dem Jito-Auction-Client<\/a> den Gro\u00dfteil des Stake, und jede \u00c4nderung an der Slot-Taktung ber\u00fchrt unmittelbar die \u00d6konomie von MEV-Capture und Block-Bauzeit: K\u00fcrzere Slots bedeuten weniger Wall-Clock-Zeit, Transaktionen pro Block zu ordnen. SIMD-0525 l\u00f6st das nicht durch einen einmaligen Hard-Fork, sondern durch eine Reihe kleiner, reversibler Feature-Gates — jedes mit einer Telemetrie-Schwelle, die erf\u00fcllt sein muss, bevor der n\u00e4chste Schritt scharf geschaltet wird. 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 \u00fcber Nacht umgeschaltet wurde.<\/p>\n\n\n\n

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

Firedancer, der Jump Crypto C++-Rewrite des Validator-Clients, war nicht Teil dieses Upgrades. Der vollst\u00e4ndige Mainnet-Deployment steht weiterhin f\u00fcr Ende 2026 an; mit Frankendancer — einem Hybrid-Client, der Firedancers Networking-Stack \u00fcber dem Rust-Executor l\u00e4uft — ist bereits ein Teil davon 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: Timing-Annahmen, die zuvor als \u201eder einzige Weg, wie Rust mithalten kann” verteidigt wurden, werden schwieriger zu justify, wenn eine parallele C++-Codebase schneller benchmarkt.<\/p>\n\n\n\n

Der Druck, die Slot-Zeit \u00fcberhaupt anzugehen, kam zu einem nicht geringen Teil von der Existenz dieses zweiten, schnelleren Clients. Firedancers Networking- und Scheduling-Stack hat gezeigt, dass das Netzwerk deutlich engere Taktungen vertr\u00e4gt, als die Referenz-Implementierung sich lange zugetraut hatte. Anza hat mit der gestaffelten Slot-Zeit-Reduktion einen Performance-Win in den Rust-Client geholt 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>\n\n\n\n

Was das f\u00fcr DeFi-Plattformen \u00e4ndert<\/h2>\n\n\n\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, die den default Oracle-Staleness-Threshold in Slots reduzieren — sinnvoll, da jeder Slot nun weniger Wall-Clock-Zeit umfasst. Phoenixs CLOB, das Orders innerhalb eines einzigen Slots crossiert, wenn beide Seiten im selben Banking-Stage ankommen, sieht niedrigere Spreads, weil seine Makers Quotes h\u00e4ufiger refreshen k\u00f6nnen — beim Erreichen des 200-ms-Ziels doppelt so oft wie bei der urspr\u00fcnglichen 400-ms-Slot-Zeit —, ohne die positional certainty zu verlieren.<\/p>\n\n\n\n