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 22. August überschritt das Solana mainnet-beta Cluster die Beteiligungsschranke für den ersten Schritt von SIMD-0525 mit wenig Aufsehen und ohne Ankündigungs-Post. Das Upgrade senkte die Ziel-Slot-Zeit von 400 ms auf 350 ms — der Auftakt eines gestaffelten Fahrplans, der das Netzwerk über 350 → 300 → 250 → 200 ms führen soll. Bis zum folgenden Morgen berichteten Validatoren, die Jito-Solana nutzen, mediane optimistische Bestätigungszeiten von rund 241 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 nicht ein einzelner großer 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.
Update (7. Oktober 2026): 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äuft das mainnet-beta bei 250 ms, mit 200 ms — exakt der Hälfte der ursprünglichen 400 ms — als verbleibendem Endziel. Die Telemetrie Ende August zeigte die mediane optimistische Bestätigung bei 241 ms (von 478 ms, −49,6 %) und die p99 bei 612 ms (von 1.840 ms, −66,7 %).
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 verschiebt es, wer während der Kongestion was verdient. Die Kopfzahl, 241 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
Solana-Clients bieten 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.
SIMD-0525 hat die Architektur dieser Wege nicht geändert. Es hat ihr Tempo verändert. Optimistische Bestätigung tritt ein, sobald eine Supermajorität stake-gewichteter Vote-Credits auf einem Fork landet — und Votes werden pro Slot abgegeben. Verkürzt man die Ziel-Slot-Zeit, tickt die Uhr, an der sich diese Supermajorität akkumuliert, schneller: von 400 ms über 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 beobachtbar war, war, dass die optimistische Bestätigungs-Latenz und ihre Varianz zugleich kollabierten.
Die Zahlen, vor und nach
| Metric | Vor SIMD-0525 | Nach 1. Schritt (Ende Aug. 2026) | Change |
|---|---|---|---|
| Ziel-Slot-Zeit | 400 ms | 350 ms | −12.5% |
| 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 |
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-0525 und die gestaffelte Slot-Zeit-Reduktion
SIMD-0525 wurde von Core-Engineers bei Anza, dem Team, das 2024 aus Solana Labs geforkt ist, erstellt und im solana-improvement-documents Repository als Spec geführt. Die Kernidee ist unspektakulär und genau deshalb wirkungsvoll: Statt einen einzelnen großen Sprung zu wagen, senkt das Proposal die Ziel-Slot-Zeit in kontrollierten Schritten — von 400 ms auf 350, dann 300, dann 250 und schließlich 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älfte der ursprünglichen 400-ms-Slot-Zeit, mit der Solana den Großteil seiner Geschichte lief.
Der interessante Teil ist das Tempo der Governance, nicht nur das der Slots. Solana-Validatoren betreiben mit dem Jito-Auction-Client den Großteil des Stake, und jede Änderung an der Slot-Taktung berührt unmittelbar die Ökonomie von MEV-Capture und Block-Bauzeit: Kürzere Slots bedeuten weniger Wall-Clock-Zeit, Transaktionen pro Block zu ordnen. SIMD-0525 löst das nicht durch einen einmaligen Hard-Fork, sondern durch eine Reihe kleiner, reversibler Feature-Gates — jedes mit einer Telemetrie-Schwelle, die erfüllt sein muss, bevor der nächste Schritt scharf geschaltet wird. 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 über Nacht 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 steht weiterhin für Ende 2026 an; mit Frankendancer — einem Hybrid-Client, der Firedancers Networking-Stack über dem Rust-Executor läuft — ist bereits ein Teil davon 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: Timing-Annahmen, die zuvor als „der einzige Weg, wie Rust mithalten kann” verteidigt wurden, werden schwieriger zu justify, wenn eine parallele C++-Codebase schneller benchmarkt.
Der Druck, die Slot-Zeit überhaupt 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ägt, 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ü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, 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äufiger refreshen können — beim Erreichen des 200-ms-Ziels doppelt so oft wie bei der ursprünglichen 400-ms-Slot-Zeit —, ohne die positional certainty zu verlieren.
- Wallet UX: Phantom und Solflare zeigen nun „confirmed” innerhalb von rund 241 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 in schneller tickenden Slots 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. Kürzere Slots geben jedem Leader weniger Wall-Clock-Zeit, um einen Block zu bauen, zu signieren und über das Netzwerk zu propagieren. Unter Spitzenlast erhöht das den Druck auf langsamere oder geografisch schlecht angebundene Validatoren, deren Blöcke es nicht rechtzeitig schaffen und übersprungen werden. Genau deshalb schaltet SIMD-0525 jeden Schritt einzeln und erst nach einem stabilen Telemetrie-Fenster: Der Sprung von 300 ms auf 250 ms am 18. September — ein Cut der Slot-Dauer um 16,7% — wurde erst freigegeben, nachdem die vorangegangene Stufe ihre Skipped-Slot-Rate gehalten hatte. Dieses Trade-off war der implizite Punkt des gestaffelten Rollouts, und es ist nicht unambiguously gut für alle: es verschiebt Last von der wahrgenommenen Nutzer-Latenz hin zu den Hardware- und Netzwerk-Anforderungen des Validator-Sets.
Die andere stille Konsequenz ist strategischer Natur. Zum ersten Mal behandelt Solana die Slot-Zeit selbst als einstellbaren Parameter, der schrittweise und datengetrieben nachgezogen wird, statt als in Stein gemeißelte Konstante. Das ist eine kleine Zahl in absoluten Termen pro Schritt und eine strukturelle in relativen Termen: Das Netzwerk hat sich ein Verfahren gegeben, seine eigene Grund-Taktung ohne Hard-Fork zu verändern. Wir erwarten, dass die verbleibenden Schritte — zuletzt die 250-ms-Stufe seit dem 18. September, mit 200 ms als Endziel — demselben Muster folgen: ein Feature-Gate, ein Telemetrie-Fenster, der nächste Schritt. 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 Epochen worth tracking. Das erste ist, ob die aktuelle 250-ms-Stufe ihre Latenz-Zahlen durch ein sustained Kongestion-Event von mehr als zwei Stunden hält; die bisherigen Schritte wurden an kurzen Spikes gemessen, nicht an einem echten Stress-Test. Das zweite ist der finale Schritt von 250 ms auf 200 ms, der die Slot-Zeit gegenüber dem Ausgangswert von 400 ms halbiert und das erklärte Endziel von SIMD-0525 markiert; ein Aktivierungsdatum steht zum jetzigen Zeitpunkt noch aus. 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.