Solanas Mainnet-Upgrade halte die Bestätigungs-Latenz stillschweigend um die Hälfte
Solanas v1.18.x Cluster-Upgrade und die SIMD-0123-Reward-Änderungen reduzierten die mediane optimistische Bestätigungs-Latenz von rund 480 ms auf 240 ms. Hier ist, was sich unter der Haube verschob.
In der Nacht des 18. April überschritt das Solana mainnet-beta Cluster die Beteiligungsschranke für den v1.18.15 Client mit wenig Aufsehen und ohne Ankündigungs-Post. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana nutzen, mediane optimistische Bestätigungszeiten von rund 240 ms, ein Rückgang gegenüber dem 460–500 ms-Band, das Solana für den Großteil von 2025 definiert hatte. Die Änderung war das kumulative Ergebnis von drei zusammengeführten 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.
Was auf dem Spiel steht, ist der Teil von Solana, den die meisten Nutzer tatsächlich spüren: nicht theoretische Durchsatzraten, sondern die wahrgenommene Lücke zwischen dem Klicken eines Swaps auf Jupiter und der Bestätigung. Für DeFi-Plattformen, die auf dem Netzwerk laufen — Perps auf Drift, das Orderbuch auf Phoenix, die strukturierten Produkt-Vaults auf Adrastea — verändert die Halbierung des optimistischen Bestätigungszeitraums die Wirtschaftlichkeit des Market-Making. Für Wallets ändert es die UX-Versprechung. Und für die Validator-Economy verschafft es eine Neuverteilung, wer während der Kongestion was verdient. Die Kopfzahl, 240 ms, ist das wichtigste Stück Solana-Infrastruktur-News des Quartals, und fast niemand außerhalb des Validator-Discords hat es bemerkt (die FMA, die österreichische Finanzmarktaufsicht, wäre hier die lokal relevante counterpart zu den Regulatoren).
Zwei Bestätigungen, ein Cluster: warum der Weg zählt
Vor v1.18 boten Solana-Clients zwei unterschiedliche Bestätigungswege. Der erste, „optimistische Bestätigung”, feuert, wenn eine Supermajorität von stake-gewichteten Vote-Credits innerhalb des TowerBFT-Lockout-Schemas auf einem bestimmten Fork landet. Der zweite, „rooted”, 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 beschreibt beide, aber die praktische Asymmetrie — optimistisch ist schnell und probabilistisch, rooted ist langsam und final — war stets Solanas zentrales UX-Trade-off.
Die v1.18-Linie hat die Architektur dieser Wege nicht geändert. Sie hat den Wettbewerb um sie verändert. Vote-Transaktionen auf Solana teilen denselben Scheduler wie User-Transaktionen, und auf einem konzentrierten Block musste der Leader historisch gesehen harte Entscheidungen über die Aufnahme von Votes machen. Späte Votes bedeuten verzögerte optimistische Bestätigung. Die SIMD-0123-Änderungen, die im Cluster-Verhalten bei Slot 261.498.112 zusammengeführt wurden, drängen die Vote-Aufnahme vor Priority-Fee-Transaktionen im Scheduler-Queue und reservieren einen festen Anteil der Block-Compute für sie. Der Effekt, der innerhalb von 48 Stunden in Dune-Dashboards beobachtbar war, war, dass die Varianz der optimistischen Bestätigungs-Latenz kollabiert.
Die Zahlen, vor und nach
| Metric | v1.17.31 (März 2026) | v1.18.15 (Mai 2026) | Change |
|---|---|---|---|
| Optimistic confirmation, p50 | 478 ms | 241 ms | −49.6% |
| Optimistic confirmation, p99 | 1.840 ms | 612 ms | −66.7% |
| Rooted (finalized), p50 | 12.8 s | 12.6 s | flat |
| Vote-tx inclusion rate per slot | 71% | 96% | +25 pp |
| Skipped-slot rate, 7-day | 4.8% | 3.1% | −1.7 pp |
Die zwei Zahlen, die zählen, sind der p99-Kollaps und die flache Finalität. Die p99-Zahl zeigt, was die worst 1% der Nutzer erleben — der Trader, der genau „confirm” 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ätszahl ist die Beruhigung: nichts am Sicherheitsmodell hat sich geändert. Die rooted-Bestätigung ist weiterhin durch dieselbe 32-Slot-Lockout-Disziplin gesperrt, die TowerBFT seit 2020 verwendet. Solana wurde an der Oberfläche schneller und blieb im Kern gleich.
SIMD-0123 und der Scheduler-Rewrite
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 als 14-seitiges Spec und enthält zwei strukturell separate Ideen. Die erste ist eine deterministische Priorität für Konsens-Votes im Banking-Stage-Scheduler. Votes werden mit einem unterscheidenden Transaktionstyp gekennzeichnet und durch eine parallele Pipeline geroutet; User-Transaktionen können sie nicht mehr verdrängen. Die zweite ist eine Reward-Redistribution: ein Anteil der Priority-Fees, der zuvor ausschließlich dem Block-Leader accruiert ist, wird nun über den aktiven Vote-Set verteilt, gewichtet nach der Lateness-Penalty, die jeder Validator vermieden hat.
Dieser zweite Teil ist der politisch interessante. Solana-Validatoren haben zwei Jahre über MEV-Capture und die Rolle des Jito-Auction-Clients diskutiert, der nun auf rund 92% des Stake läuft. SIMD-0123 aboliert die Auction nicht. Es ändert das Incentive: Leaders, die die Vote-Aufnahme verzögern, 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ür selbstische Leadership eingeführt, ohne die Konsens-Regeln zu touchieren. Es ist die Art von Änderung, die auf Ethereum einen Hard-Fork und eine sechsmonatige All-Core-Devs-Debatte erfordert hätte; auf Solana war es ein Feature-Gate, das am Donnerstag umgeschaltet wurde.
Warum das Firedancer-Team wichtig war, obwohl sie nicht shipped haben
Firedancer, der Jump Crypto C++-Rewrite des Validator-Clients, war nicht Teil dieses Upgrades. Der vollständige Mainnet-Deployment bleibt für Ende 2026 mit Frankendancer — einem Hybrid-Client, der Firedancers Networking-Stack über dem Rust-Executor läuft — live auf rund 4% des Stake. Aber die Existenz von Firedancer hat geändert, was im Rust-Client politisch möglich war. Anza-Engineers haben auf Breakpoint-Konferenzen über den Druck gesprochen, den ein zweiter High-Performance-Client auf die Referenz-Implementierung legt: Scheduler-Entscheidungen, die zuvor als „der einzige Weg, wie Rust mithalten kann” verteidigt wurden, werden schwieriger zu justify, wenn eine parallele C++-Codebase schneller benchmarkt.
Der Vote-Scheduler-Rewrite, der in 1.18.15 gelandet ist, übernimmt 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ücke reduziert, die Firedancer öffnen sollte. Ob das Firedancers Value Proposition verzögert, ist nun ein Thema des stillen Debatten bei den Validator-Operatoren, die wir für diesen Artikel gesprochen haben, von denen keiner on the record sprechen wollte. Der competitive dynamic zwischen zwei Production-Clients produziert jedoch unabhängig davon ein schnelleres Netzwerk für End-Nutzer.
Was das für DeFi-Plattformen ändert
Die Halbierung der optimistischen Bestätigungs-Latenz fühlt sich nicht nur nicer an. Es ändert 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ür diese Oracle-Prints benötigt, verengen. Das Team hat noch kein aktualisiertes Risk-Model veröffentlicht, aber das relevante Drift-protocol Repository 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önnen, ohne die positional certainty zu verlieren.
- Wallet UX: Phantom und Solflare zeigen nun „confirmed” innerhalb von rund 250 ms nach Submission für die mediane Transaktion.
- Bridge economics: Wormholes Guardian-Set pollt für finalized Slots, nicht optimistische Bestätigungen, sodass die cross-chain Finalität unverändert bei ~14 s bleibt.
- Liquid-staking: Marinade und Jitos Stake-Pool-Epoch-Grenzen sehen eine tighter unbonding-Abrechnung, weil Vote-Credits vorhersagbarer accruiert werden.
- Trading-bot infrastructure: Searchers, die Helius oder Triton gRPC-Streams nutzen, sehen nun eine flatter Latenz-Distribution, was den Wert von co-located Machines reduziert.
Der Teil, den die Marketing-Materialien auslassen werden
Es gibt einen Cost. Die Reservierung von Block-Compute für Votes bedeutet, dass weniger davon für alles andere unter Peak-Load verfügbar ist. Während des FORM-Token-Launches am 22. April — dem ersten major Kongestion-Event nach dem Upgrade — sanken die User-Transaktions-Landing-Rates während der ersten 90 Sekunden des Launches auf rund 38%, gegenüber einer vergleichbaren historischen Zahl von 52% während des GOAT-Launches Ende 2025. Die deterministische Vote-Priorität funktioniert genau wie designed: wenn das Netzwerk saturiert ist, kommen Votes in und User-Transaktionen warten. Dieses Trade-off war der implizite Punkt von SIMD-0123, und es ist nicht unambiguously gut für alle.
Die andere stille Konsequenz betrifft die Leaderboard der Validator-Rewards. Die Redistribution-Klausel hat rund 0,4% der wöchentlichen Fee-Revenue von den Top-Decile-Leaders (largely Jito-aligned, largely running optimized Banking-Stage-Forks) zum medianen Validator verschoben. Das ist eine kleine Zahl in absoluten Termen und eine strukturelle in relativen Termen: es ist das erste Mal, dass das Solana-Protocol seinen eigenen Reward-Mechanismus verwendet, um Verhalten zu penalisieren, das zuvor lediglich verpönt wurde. Wir erwarten, dass die nächste Runde von SIMDs — die öffentliche Draft-Liste hat jetzt elf Proposals in aktiver Diskussion — dieses Muster erweitern. Für mehr Kontext, wie sich die Validator-Economics über Zyklen verschieben, trackt unser Market-Dashboard wöchentlich die stake-gewichtete Yield Curve.
Was als nächstes zu beobachten ist
Drei Dinge sind über die nächsten zwei Epochen worth tracking. Das erste ist, ob v1.18.15 seine Latenz-Zahlen durch ein sustained Kongestion-Event von mehr als zwei Stunden hält; der FORM-Launch war ein kurzer Spike, nicht ein Stress-Test. Das zweite ist das SIMD-0156-Draft, das vorschlägt, die Vote-Scheduler-Priorität-Idee auf Oracle-Update-Transaktionen von den Pyth- und Switchboard-Programmen zu extend — ein viel größerer und politisch charged Carve-out. Das dritte ist Firedancers Mainnet-Roadmap, jetzt dass die Lücke zwischen ihm und dem Referenz-Client enger geworden ist. Solanas Engineering-Kultur war immer bereit, hard Changes schnell zu shippen; dieses Upgrade ist ein Reminder, dass die Roadmap des Netzwerks noch durch das bestimmt wird, was seine Core-Teams merge können, nicht durch das, was seine Marketing-Department ankündigt. Für Trader, die die Implikation auf Liquidity beobachten, aktualisiert unser Priority-Fee-Tracker jeden Slot, und der kommende Anza Developer Call ist auf unserem Events-Kalender.