Solanas Mainnet-Upgrade senkt die Bestätigungs-Latenz leise 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.
Oktober 2026 Update (24. Oktober 2026): Dieser Beitrag wurde auf die jüngsten Mainnet-Änderungen aktualisiert. Am 9. Oktober 2026 wurde die Slot-Zeit auf 200 ms gesenkt – laut Solana eine Halbierung gegenüber 400 ms, die Bestätigungen ungefähr doppelt so schnell machen soll. Am 16. Oktober 2026 folgte das Firedancer Mainnet Release v26.10.2 inklusive einer Funktion, die die Slot-Zeit von 250 auf 200 ms senkt. Am 21. Oktober 2026 aktivierte Solana mit Epoch 1064 den Alpenglow-Konsens auf dem Mainnet, der eine Finalität von etwa 150 ms statt 12,8 Sekunden anpeilt. Wichtig: Die 150 ms sind bislang ein Zielwert, kein nachgewiesener Messwert – ein öffentliches Dashboard zeigte nach der Aktivierung weiterhin rund 6,6 Sekunden Finalität und 4.721 Transaktionen pro Sekunde.
Im Oktober 2026 wurde das Solana mainnet-beta-Cluster in mehreren Schritten und weitgehend ohne großen Ankündigungsbeitrag spürbar schneller. Am 9. Oktober senkten die Clients die Slot-Zeit auf 200 ms – nach Angaben von Solana eine Halbierung gegenüber den zuvor üblichen 400 ms, die Bestätigungen ungefähr doppelt so schnell machen soll. Grundlage waren die Releases Agave v4.3.0 und Firedancer v26.09.4 vom 24. September, die unter anderem Vorbereitungen für 4.096-Byte-Transaktionen, deterministisches Ordering und BN254-Unterstützung enthielten. 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 eine Slot-Zeit von 200 ms die Wirtschaftlichkeit des Market-Making. Für Wallets verändert es die UX-Versprechung. Und mit dem am 21. Oktober aktivierten Alpenglow-Konsens kommt eine noch tiefergehende Veränderung des Finalitätspfads hinzu. Die wichtigste Infrastruktur-News von Solana des Quartals kam in kleinen, ruhigen Schritten, und fast niemand außerhalb des Validator-Discords hat sie Schritt für Schritt mitverfolgt.
Zwei Bestätigungen, ein Cluster: warum der Weg wichtig ist
Solana-Clients bieten historisch zwei unterschiedliche Bestätigungswege. Der erste, „optimistische Bestätigung”, feuert, wenn eine Supermajorität von stake-gewichteten Vote-Krediten innerhalb des TowerBFT-Lockout-Zeitplans auf einem bestimmten Fork landen. Der zweite, „rooted”, feuert nur, wenn dieser Fork tief genug in der 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 Oktober-Änderungen setzten an zwei Stellen an. Die Senkung der Slot-Zeit auf 200 ms wirkt auf die wahrgenommene, optimistische Geschwindigkeit: Wenn Slots schneller aufeinanderfolgen, erreichen Bestätigungen die Nutzer früher. Der am 21. Oktober mit Epoch 1064 aktivierte Alpenglow-Konsens zielt dagegen auf den langsamen, finalen Weg und peilt eine Finalität von etwa 150 ms statt der bisherigen 12,8 Sekunden an. Der Effekt, der in Dune-Dashboards und öffentlichen Monitoren beobachtbar ist, war zunächst uneinheitlich: Die Slot-Zeit halbierte sich wie angekündigt, während die gemessene Finalität den 150-ms-Zielwert bislang nicht erreicht.
Die Zahlen, vor und nach
| Messwert | Vor Oktober 2026 | Nach Oktober 2026 | Hinweis |
|---|---|---|---|
| Slot-Zeit | 400 ms | 200 ms | Halbierung, seit 9. Oktober 2026 |
| Angepeilte Finalität (Alpenglow) | ~12,8 s | ~150 ms | Zielwert, nicht nachgewiesen |
| Gemessene Finalität laut Dashboard | — | ~6,6 s | nach Aktivierung am 21. Oktober |
| Durchsatz laut Dashboard | — | 4.721 TPS | nach Alpenglow-Aktivierung |
| Aktive Client-Releases | — | Agave v4.3.0, Firedancer v26.09.4 / v26.10.2 | Stand Oktober 2026 |
Die zwei Dinge, die wichtig sind, sind die bestätigte Halbierung der Slot-Zeit und die Lücke zwischen Ziel und Messung bei der Finalität. Dass die Slot-Zeit tatsächlich von 400 ms auf 200 ms gefallen ist, entfernt einen Teil der schlechtesten UX-Erlebnisse auf dem Netzwerk – den Trader, der genau „confirm” geklickt hat, als ein Launch die Queue des Leaders saturierte. Die Finalitätszahl ist dagegen die nötige Beruhigung gegen Überoptimismus: Alpenglow peilt zwar 150 ms an, doch ein öffentliches Dashboard zeigte nach der Aktivierung weiterhin rund 6,6 Sekunden und 4.721 Transaktionen pro Sekunde. Der 150-ms-Wert sollte derzeit nicht als tatsächliche Nutzer-Latenz interpretiert werden.
Alpenglow und die Konsens-Neuausrichtung
Alpenglow ist die bislang tiefgreifendste Änderung am Konsensweg und wurde am 21. Oktober 2026 mit Epoch 1064 auf dem Mainnet aktiviert. Der Entwurf stammt aus dem Umfeld der Core-Engineers bei Anza, dem Team, das 2024 aus Solana Labs geforkt wurde, und lässt sich im solana-improvement-documents Repository nachverfolgen. Das erklärte Ziel: eine Finalität von etwa 150 ms statt der bisherigen 12,8 Sekunden. Vorbereitet wurde der Schritt bereits mit Agave v4.3.0 und Firedancer v26.09.4 vom 24. September, die unter anderem 4.096-Byte-Transaktionen, deterministisches Ordering und BN254-Unterstützung mitbrachten.
Der politisch interessante Teil ist das Verhältnis von Anspruch und bisheriger Realität. Solana-Validatoren haben zwei Jahre über MEV-Capture und die Rolle des Jito-Auction-Clients diskutiert, der weiterhin auf einem großen Teil des Stake läuft. Alpenglow ändert den Finalitätsmechanismus, nicht das Auction-Modell. Dass die gemessene Finalität trotz 150-ms-Ziel kurz nach der Aktivierung noch bei rund 6,6 Sekunden lag, zeigt, wie groß der Abstand zwischen einer auf Mainnet aktivierten Spezifikation und einem im Alltag nachweisbaren End-to-End-Wert sein kann. Es ist die Art von Änderung, die auf Ethereum einen Hard-Fork und eine lange All-Core-Devs-Diskussion erfordert hätte; auf Solana war es eine Epoch-Grenze.
Firedancer ist auf dem Mainnet angekommen
Firedancer, die Jump Crypto C++-Neuschreibung des Validator-Clients, ist nicht länger nur ein Versprechen für die Zukunft. Am 16. Oktober 2026 veröffentlichte das Projekt das Firedancer Mainnet Release v26.10.2; parallel wurde eine Funktion angekündigt, die die Slot-Zeit von 250 auf 200 ms senkt. Schon am 24. September war mit Firedancer v26.09.4 ein Release erschienen, das gemeinsam mit Agave v4.3.0 die Grundlagen für die Oktober-Upgrades legte. Die Existenz eines zweiten High-Performance-Clients hat über Jahre geändert, was im Rust-Client politisch möglich war.
Anza-Engineers haben bei Breakpoint-Konferenzen über den Druck gesprochen, den ein zweiter 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. Mit den Firedancer-Mainnet-Releases und der gemeinsamen Vorbereitung der Slot-Zeit-Senkung ist aus dem Wettbewerb zwischen zwei Produktions-Clients ein konkreter, für Endnutzer spürbarer Geschwindigkeitsgewinn geworden.
Was dies für DeFi-Plattformen ändert
Eine Slot-Zeit von 200 ms 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 die Sicherheitsmarge für diese Oracle-Prints enger ziehen, wenn Slots doppelt so schnell aufeinanderfolgen. Das Team hat zwar noch kein vollständig aktualisiertes Risikomodell veröffentlicht, doch das relevante Drift-protocol Repository zeigt entsprechende Arbeiten an den Oracle-Staleness-Schwellen. Phoenix’s CLOB, das Orders innerhalb eines einzigen Slots kreuzt, wenn beide Seiten im gleichen Banking-Stage ankommen, profitiert ebenfalls, weil seine Makers Quotes häufiger aktualisieren können, ohne die Positionssicherheit zu verlieren.
- Wallet UX: Phantom und Solflare profitieren von der halbierten Slot-Zeit von 200 ms, sodass „confirmed” für die mediane Transaktion spürbar früher erscheint.
- Bridge-Wirtschaft: Wormhole’s Guardian-Set fragt nach finalisierten Slots; weil Alpenglow den Finalitätspfad verändert, hängt die Cross-Chain-Finalität an der tatsächlich gemessenen Finalität – die nach der Aktivierung noch bei rund 6,6 Sekunden lag, nicht beim 150-ms-Ziel.
- Liquid-Staking: Marinade und Jito’s Stake-Pool-Epochgrenzen sehen eine engere Unbonding-Buchhaltung, weil Vote-Kredite vorhersagbarer akkumulieren.
- Trading-Bot-Infrastruktur: Searcher, die Helius oder Triton gRPC-Streams ausführen, rechnen die kürzere Slot-Zeit und den veränderten Finalitätspfad in ihre Co-Location-Strategien ein.
Der Teil, den die Marketingmaterialien nicht erwähnen werden
Es gibt einen wichtigen Vorbehalt. Die angepeilten 150 ms Finalität sind bislang ein Zielwert, kein nachgewiesener End-to-End-Messwert. Nach der Alpenglow-Aktivierung am 21. Oktober zeigte ein öffentliches Dashboard weiterhin etwa 6,6 Sekunden Transaktionsfinalität und 4.721 Transaktionen pro Sekunde – ein deutlicher Hinweis, dass der 150-ms-Wert derzeit nicht als tatsächliche Nutzer-Latenz interpretiert werden sollte. Verlässlich halbiert hat sich bislang die Slot-Zeit von 400 auf 200 ms; die große Finalitäts-Verbesserung muss sich im Alltag erst noch zeigen. Dieser Unterschied zwischen Spezifikation und gemessener Realität ist nicht eindeutig für alle gleich zu bewerten (regulatorische Behörden wie BaFin, die Federal Financial Supervisory Authority, sind hier die lokal relevante Gegenpartei).
Die andere ruhige Konsequenz betrifft die Erwartungshaltung an der Validatoren-Seite. Ein Netzwerk, das seine Slot-Zeit halbiert und einen neuen Konsens aktiviert, verschiebt, wer unter Last wie schnell bestätigt bekommt – und wie belastbar die kommunizierten Zielwerte tatsächlich sind. Wir erwarten, dass die nächste Runde von Proposals und Client-Releases dieses Muster weiter ausbaut und insbesondere daran gemessen wird, ob die Alpenglow-Finalität im Live-Betrieb näher an den Zielwert heranrückt. 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 Epochen wert, verfolgt zu werden. Das erste ist, ob Alpenglow seinen 150-ms-Finalitätszielwert im Live-Betrieb einlöst; bislang zeigte ein öffentliches Dashboard nach der Aktivierung am 21. Oktober weiterhin rund 6,6 Sekunden. Das zweite ist, ob die halbierte Slot-Zeit von 200 ms auch durch nachhaltige Überlastungsereignisse stabil bleibt und ob weitere Senkungen folgen. Das dritte ist die Adoption der Firedancer-Mainnet-Releases v26.09.4 und v26.10.2, jetzt, da Firedancer vom Versprechen zur ausgelieferten Software geworden ist. Solanas Engineering-Kultur war immer bereit, harte Änderungen schnell zu liefern; dieses Quartal ist eine Erinnerung, dass die Roadmap des Netzwerks durch das gesetzt wird, was seine Core-Teams zusammenführen können – und daran gemessen werden muss, was am Ende wirklich messbar ist, nicht nur angekü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.