Solanas Mainnet-Upgrade halte die Bestätigungs-Latenz ruhig um die Hälfte
Das Cluster-Upgrade v1.18.x von Solana und die SIMD-0123-Änderungen der Belohnungen reduzierten die mediane optimistische Bestätigungs-Latenz von etwa 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 Beteiligungsschwellen für den v1.18.15 Client mit wenig Aufsehen und ohne Ankündigungsbeitrag. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana ausführen, mediane optimistische Bestätigungszeiten von etwa 240 ms, ein Rückgang gegenüber dem 460–500 ms-Band, das Solana für den größten Teil von 2025 definiert hatte. Die Änderung war das kumulative Ergebnis von drei zusammengeführten提案 – SIMD-0123 zur Verteilung der Blockbelohnungen, SIMD-0096 zur Behandlung der Prioritätsgebühren und eine ruhigere Reihe von Patches zur Buchhaltung der TowerBFT-Vote-Kredite –, die unter einem einzigen Feature-Gate ausgeliefert wurden. Niemand hielt eine Launch-Veranstaltung ab. Der Cluster wurde einfach schneller.
Was auf dem Spiel steht, ist der Teil von Solana, den die meisten Nutzer tatsächlich spüren: nicht der theoretische Durchsatz, sondern die wahrgenommene Lücke zwischen dem Klicken auf einen Swap auf Jupiter und dem Bestätigen. 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 verändert es die UX-Versprechung. Und für die Validatoren-Wirtschaft verschafft es eine Neuverteilung, wer während der Überlastung was verdient. Die Kopfzahl, 240 ms, ist das wichtigste Stück Infrastruktur-News von Solana des Quartals, und fast niemand außerhalb des Validator-Discords hat es bemerkt.
Zwei Bestätigungen, ein Cluster: warum der Weg wichtig ist
Vor v1.18 boten Solana-Clients zwei unterschiedliche Bestätigungswege. Der erste, „optimistische Bestätigung”, feuert, wenn eine Supermajorität von stake-gewichteten Vote-Kredite innerhalb des TowerBFT-Lockout-Zeitplans auf einem bestimmten Fork landen. Der zweite, „rooted”, 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 beschreibt beide, aber die praktische Asymmetrie – optimistisch ist schnell und probabilistisch, rooted ist langsam und final – war immer der zentrale UX-Trade-off von Solana.
Die v1.18-Linie änderte nicht die Architektur dieser Wege. Sie änderte den Wettbewerb um sie. Vote-Transaktionen auf Solana teilen denselben Scheduler wie Benutzer-Transaktionen, und auf einem überlasteten 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 Clusterverhalten bei Slot 261.498.112 zusammengeführt wurden, drängen die Vote-Aufnahme vor Prioritätsgebühren-Transaktionen im Scheduler-Warteschlange und reservieren einen festen Anteil der Block-Compute für sie. Der Effekt, der in Dune-Dashboards innerhalb von 48 Stunden beobachtbar war, war, dass die Varianz der optimistischen Bestätigungs-Latenz kollabierte.
Die Zahlen, vor und nach
| Messwert | v1.17.31 (März 2026) | v1.18.15 (Mai 2026) | Änderung |
|---|---|---|---|
| Optimistische Bestätigung, p50 | 478 ms | 241 ms | −49,6% |
| Optimistische Bestätigung, p99 | 1.840 ms | 612 ms | −66,7% |
| Rooted (finalisiert), p50 | 12,8 s | 12,6 s | flat |
| Vote-tx-Aufnahmerate per Slot | 71% | 96% | +25 pp |
| Rate der übersprungenen Slots, 7 Tage | 4,8% | 3,1% | −1,7 pp |
Die zwei Zahlen, die wichtig sind, sind der p99-Kollaps und die flache Finalität. Die p99-Zahl zeigt, was die schlechtesten 1% der Nutzer erleben – der Trader, der genau „confirm” 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ätszahl ist die Beruhigung: nichts am Sicherheitsmodell hat sich geändert. Die rooted-Bestätigung ist weiterhin durch dieselbe 32-Slot-Lockout-Doktrin begrenzt, die TowerBFT seit 2020 verwendet. Solana wurde an der Oberfläche schneller und blieb im Kern gleich.
SIMD-0123 und die Scheduler-Neuschreibung
SIMD-0123 wurde von Core-Engineers bei Anza, dem Team, das 2024 aus Solana Labs geforkt wurde, mit Prüfung des Jito-Teams erstellt. Der Proposal befindet sich im solana-improvement-documents Repository als 14-seitige Spezifikation und enthält zwei strukturell separate Ideen. Die erste ist eine deterministische Priorität für Konsens-Votes innerhalb des Banking-Stage-Schedulers. Votes werden mit einem unterscheidenden Transaktionstyp gekennzeichnet und durch eine parallele Pipeline geleitet; Benutzer-Transaktionen können sie nicht mehr verdrängen. Die zweite ist eine Belohnungsneuverteilung: ein Teil der Prioritätsgebühren, die zuvor ausschließlich dem Block-Leader zugefallen sind, wird nun über den aktiven Vote-Set neu verteilt, gewichtet durch die Latenz-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 etwa 92% des Stake läuft. SIMD-0123 aboliert den Auction nicht. Es ändert jedoch die Incentive: Leaders, die die Vote-Aufnahme verzögern, um ihren eigenen Prioritätsgebühren-Take zu maximieren, verlieren nun einen Anteil dieser Gebühren an Validatoren, die rechtzeitig votiert haben. In der Tat hat Solana eine weiche Penalty für selbstsüchtige Leadership eingeführt, ohne die Konsensregeln zu ändern. Es ist die Art von Änderung, die auf Ethereum einen Hard-Fork und eine sechsmonatige All-Core-Devs-Diskussion erfordert hätte; auf Solana war es ein Feature-Gate, das am Donnerstag umgeschaltet wurde.
Warum das Firedancer-Team wichtig war, obwohl sie nicht geliefert haben
Firedancer, die Jump Crypto C++-Neuschreibung des Validator-Clients, war nicht Teil dieses Upgrades. Der vollständige Mainnet-Deployment bleibt für Ende 2026 mit Frankendancer – einem Hybrid-Client, der den Networking-Stack von Firedancer über dem Rust-Executor ausführt – live auf etwa 4% des Stake geplant. Aber die Existenz von Firedancer hat geändert, was im Rust-Client politisch möglich war. Anza-Engineers haben bei Breakpoint-Konferenzen über den Druck gesprochen, den ein zweiter High-Performance-Client auf die Referenzimplementierung legt: Scheduler-Entscheidungen, die zuvor als „der einzige Weg, wie Rust mithalten kann” verteidigt wurden, werden schwieriger zu rechtfertigen, wenn eine parallele C++-Codebasis schneller benchmarkt.
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ückportiert, den Latenzgewinn genommen und die Lücke, die Firedancer öffnen sollte, reduziert. Ob dies den Wertvorschlag von Firedancer verzögert, ist nun ein Thema der ruhigen Diskussion bei den Validator-Operatoren, die wir für diesen Beitrag gesprochen haben, von denen keiner auf der Aufzeichnung sprechen wollte. Der Wettbewerbsdynamik zwischen zwei Produktions-Clients produziert jedoch unabhängig davon ein schnelleres Netzwerk für Endnutzer.
Was dies für DeFi-Plattformen ändert
Die Halbierung der optimistischen Bestätigungs-Latenz fühlt sich nicht nur besser an. Sie ändert 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ür diese Oracle-Prints benötigt, verengen. Das Team hat noch kein aktualisiertes Risikomodell veröffentlicht, aber das relevante Drift-protocol Repository 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önnen, ohne die Positionssicherheit zu verlieren.
- Wallet UX: Phantom und Solflare zeigen nun „confirmed” innerhalb von etwa 250 ms nach der Submission für die mediane Transaktion.
- Bridge-Wirtschaft: Wormhole’s Guardian-Set fragt nach finalisierten Slots, nicht nach optimistischen Bestätigungen, so dass die Cross-Chain-Finalität unverändert bei ~14 s bleibt.
- Liquid-Staking: Marinade und Jito’s Stake-Pool-Epochgrenzen sehen eine enge Unbonding-Buchhaltung, weil Vote-Kredite vorhersagbarer akkumulieren.
- Trading-Bot-Infrastruktur: Searcher, die Helius oder Triton gRPC-Streams ausführen, sehen nun eine flache Latenzverteilung, was den Wert von co-lokalisierten Maschinen reduziert.
Der Teil, den die Marketingmaterialien nicht erwähnen werden
Es gibt einen Preis. Die Reservierung von Block-Compute für Votes bedeutet, dass weniger davon für alles andere unter Spitzenbelastung verfügbar ist. Während des FORM-Token-Launches am 22. April – dem ersten großen Überlastungsereignis nach dem Upgrade – sanken die User-Transaktions-Landing-Raten während der ersten 90 Sekunden des Launches auf etwa 38%, gegenüber einer vergleichbaren historischen Zahl von 52% während des GOAT-Launches Ende 2025. Die deterministische Vote-Priorität funktioniert genau wie geplant: wenn das Netzwerk saturiert ist, kommen Votes hinein und Benutzer-Transaktionen warten. Dieser Trade-off war der implizite Punkt von SIMD-0123, und er ist nicht eindeutig für alle gut (reguläre Behörden wie BaFin, die Federal Financial Supervisory Authority, sind hier die lokal relevante Gegenpartei).
Die andere ruhige Konsequenz ist für die Leaderboard der Validatoren-Belohnungen. Die Neuverteilungsklausel hat etwa 0,4% der wöchentlichen Gebühren-Einnahmen von den Top-Dezile-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-Protokoll seinen eigenen Belohnungsmechanismus verwendet, um Verhalten zu penalisieren, das zuvor nur verurteilt wurde. Wir erwarten, dass die nächste Runde von SIMDs – die öffentliche Draft-Liste hat jetzt elf Proposal in aktiver Diskussion – dieses Muster erweitern. Für mehr Kontext, wie sich die Validatoren-Wirtschaft über Zyklen verändert, verfolgt unser Market-Dashboard wöchentlich die stake-gewichtete Yield-Kurve.
Was nächstes zu beobachten ist
Drei Dinge sind über die nächsten zwei Epochen wert, verfolgt zu werden. Das erste ist, ob v1.18.15 seine Latenzzahlen durch ein nachhaltiges Überlastungsereignis von mehr than zwei Stunden hält; der FORM-Launch war ein kurzer Spike, nicht ein Stress-Test. Das zweite ist der SIMD-0156-Draft, der vorschlägt, die Vote-Scheduler-Prioritätsidee auf Oracle-Update-Transaktionen von den Pyth- und Switchboard-Programmen zu erweitern – ein viel größerer und politisch aufgeladener Ausschnitt. Das dritte ist Firedancer’s Mainnet-Roadmap, jetzt, da die Lücke zwischen ihm und dem Referenz-Client enger geworden ist. Solanas Engineering-Kultur war immer bereit, harte Änderungen schnell zu liefern; dieses Upgrade ist eine Erinnerung, dass die Roadmap des Netzwerk noch durch das, was seine Core-Teams zusammenführen können, gesetzt wird, nicht durch das, was seine Marketing-Abteilung ankündigt. Für Trader, die die Implikation auf die Liquidität beobachten, aktualisiert unser Priority-Fee-Tracker jeden Slot, und der kommende Anza-Developer-Call ist auf unserem Events-Kalender.