{"id":40,"date":"2026-06-25T13:45:59","date_gmt":"2026-06-25T13:45:59","guid":{"rendered":"https:\/\/hoge.gg\/de\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-10-24T03:34:08","modified_gmt":"2026-10-24T03:34:08","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/de\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"Solanas Mainnet-Upgrade senkt die Best\u00e4tigungs-Latenz leise um die H\u00e4lfte"},"content":{"rendered":"\n
\n

Oktober 2026 Update (24. Oktober 2026):<\/strong> Dieser Beitrag wurde auf die j\u00fcngsten Mainnet-\u00c4nderungen aktualisiert. Am 9. Oktober 2026 wurde die Slot-Zeit auf 200 ms gesenkt \u2013 laut Solana eine Halbierung gegen\u00fcber 400 ms, die Best\u00e4tigungen ungef\u00e4hr 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\u00e4t von etwa 150 ms statt 12,8 Sekunden anpeilt. Wichtig: Die 150 ms sind bislang ein Zielwert, kein nachgewiesener Messwert \u2013 ein \u00f6ffentliches Dashboard zeigte nach der Aktivierung weiterhin rund 6,6 Sekunden Finalit\u00e4t und 4.721 Transaktionen pro Sekunde.<\/p>\n<\/div><\/div>\n\n\n\n

Im Oktober 2026 wurde das Solana mainnet-beta-Cluster in mehreren Schritten und weitgehend ohne gro\u00dfen Ank\u00fcndigungsbeitrag sp\u00fcrbar schneller. Am 9. Oktober senkten die Clients die Slot-Zeit auf 200 ms \u2013 nach Angaben von Solana eine Halbierung gegen\u00fcber den zuvor \u00fcblichen 400 ms, die Best\u00e4tigungen ungef\u00e4hr doppelt so schnell machen soll. Grundlage waren die Releases Agave v4.3.0<\/a> und Firedancer v26.09.4 vom 24. September, die unter anderem Vorbereitungen f\u00fcr 4.096-Byte-Transaktionen, deterministisches Ordering und BN254-Unterst\u00fctzung enthielten. Niemand hielt eine Launch-Veranstaltung ab. Der Cluster wurde einfach schneller.<\/p>\n\n\n\n

Was auf dem Spiel steht, ist der Teil von Solana, den die meisten Nutzer tats\u00e4chlich sp\u00fcren: nicht der theoretische Durchsatz, sondern die wahrgenommene L\u00fccke zwischen dem Klicken auf einen Swap auf Jupiter und dem Best\u00e4tigen. F\u00fcr DeFi-Plattformen, die auf dem Netzwerk laufen \u2013 Perps auf Drift, das Orderbuch auf Phoenix, die strukturierten Produkt-Vaults auf Adrastea \u2013 ver\u00e4ndert eine Slot-Zeit von 200 ms die Wirtschaftlichkeit des Market-Making. F\u00fcr Wallets ver\u00e4ndert es die UX-Versprechung. Und mit dem am 21. Oktober aktivierten Alpenglow-Konsens kommt eine noch tiefergehende Ver\u00e4nderung des Finalit\u00e4tspfads hinzu. Die wichtigste Infrastruktur-News von Solana des Quartals kam in kleinen, ruhigen Schritten, und fast niemand au\u00dferhalb des Validator-Discords hat sie Schritt f\u00fcr Schritt mitverfolgt.<\/p>\n\n\n\n

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

Solana-Clients bieten historisch zwei unterschiedliche Best\u00e4tigungswege. Der erste, \u201eoptimistische Best\u00e4tigung”, feuert, wenn eine Supermajorit\u00e4t von stake-gewichteten Vote-Krediten innerhalb des TowerBFT-Lockout-Zeitplans auf einem bestimmten Fork landen. Der zweite, \u201erooted”, 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<\/a> beschreibt beide, aber die praktische Asymmetrie \u2013 optimistisch ist schnell und probabilistisch, rooted ist langsam und final \u2013 war immer der zentrale UX-Trade-off von Solana.<\/p>\n\n\n\n

Die Oktober-\u00c4nderungen 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\u00e4tigungen die Nutzer fr\u00fcher. Der am 21. Oktober mit Epoch 1064 aktivierte Alpenglow-Konsens zielt dagegen auf den langsamen, finalen Weg und peilt eine Finalit\u00e4t von etwa 150 ms statt der bisherigen 12,8 Sekunden an. Der Effekt, der in Dune-Dashboards<\/a> und \u00f6ffentlichen Monitoren beobachtbar ist, war zun\u00e4chst uneinheitlich: Die Slot-Zeit halbierte sich wie angek\u00fcndigt, w\u00e4hrend die gemessene Finalit\u00e4t den 150-ms-Zielwert bislang nicht erreicht.<\/p>\n\n\n\n

Die Zahlen, vor und nach<\/h2>\n\n\n\n
Messwert<\/th>Vor Oktober 2026<\/th>Nach Oktober 2026<\/th>Hinweis<\/th><\/tr><\/thead>
Slot-Zeit<\/td>400 ms<\/td>200 ms<\/td>Halbierung, seit 9. Oktober 2026<\/td><\/tr>
Angepeilte Finalit\u00e4t (Alpenglow)<\/td>~12,8 s<\/td>~150 ms<\/td>Zielwert, nicht nachgewiesen<\/td><\/tr>
Gemessene Finalit\u00e4t laut Dashboard<\/td>—<\/td>~6,6 s<\/td>nach Aktivierung am 21. Oktober<\/td><\/tr>
Durchsatz laut Dashboard<\/td>—<\/td>4.721 TPS<\/td>nach Alpenglow-Aktivierung<\/td><\/tr>
Aktive Client-Releases<\/td>—<\/td>Agave v4.3.0, Firedancer v26.09.4 \/ v26.10.2<\/td>Stand Oktober 2026<\/td><\/tr><\/tbody><\/table>
Quellen: solana.com Cluster-Metriken, Firedancer-Release-Notes sowie ein \u00f6ffentliches Finalit\u00e4ts-\/Durchsatz-Dashboard nach der Alpenglow-Aktivierung.<\/figcaption><\/figure>\n\n\n\n

Die zwei Dinge, die wichtig sind, sind die best\u00e4tigte Halbierung der Slot-Zeit und die L\u00fccke zwischen Ziel und Messung bei der Finalit\u00e4t. Dass die Slot-Zeit tats\u00e4chlich von 400 ms auf 200 ms gefallen ist, entfernt einen Teil der schlechtesten UX-Erlebnisse auf dem Netzwerk \u2013 den Trader, der genau \u201econfirm” geklickt hat, als ein Launch die Queue des Leaders saturierte. Die Finalit\u00e4tszahl ist dagegen die n\u00f6tige Beruhigung gegen \u00dcberoptimismus: Alpenglow peilt zwar 150 ms an, doch ein \u00f6ffentliches 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\u00e4chliche Nutzer-Latenz interpretiert werden.<\/p>\n\n\n\n

Alpenglow und die Konsens-Neuausrichtung<\/h2>\n\n\n\n

Alpenglow ist die bislang tiefgreifendste \u00c4nderung 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\u00e4sst sich im solana-improvement-documents Repository<\/a> nachverfolgen. Das erkl\u00e4rte Ziel: eine Finalit\u00e4t 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\u00fctzung mitbrachten.<\/p>\n\n\n\n

Der politisch interessante Teil ist das Verh\u00e4ltnis von Anspruch und bisheriger Realit\u00e4t. Solana-Validatoren haben zwei Jahre \u00fcber MEV-Capture und die Rolle des Jito-Auction-Clients<\/a> diskutiert, der weiterhin auf einem gro\u00dfen Teil des Stake l\u00e4uft. Alpenglow \u00e4ndert den Finalit\u00e4tsmechanismus, nicht das Auction-Modell. Dass die gemessene Finalit\u00e4t trotz 150-ms-Ziel kurz nach der Aktivierung noch bei rund 6,6 Sekunden lag, zeigt, wie gro\u00df der Abstand zwischen einer auf Mainnet aktivierten Spezifikation und einem im Alltag nachweisbaren End-to-End-Wert sein kann. Es ist die Art von \u00c4nderung, die auf Ethereum einen Hard-Fork und eine lange All-Core-Devs-Diskussion erfordert h\u00e4tte; auf Solana war es eine Epoch-Grenze.<\/p>\n\n\n\n

Firedancer ist auf dem Mainnet angekommen<\/h2>\n\n\n\n

Firedancer, die Jump Crypto C++-Neuschreibung des Validator-Clients, ist nicht l\u00e4nger nur ein Versprechen f\u00fcr die Zukunft. Am 16. Oktober 2026 ver\u00f6ffentlichte das Projekt das Firedancer Mainnet Release v26.10.2; parallel wurde eine Funktion angek\u00fcndigt, 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\u00fcr die Oktober-Upgrades legte. Die Existenz eines zweiten High-Performance-Clients hat \u00fcber Jahre ge\u00e4ndert, was im Rust-Client politisch m\u00f6glich war.<\/p>\n\n\n\n

Anza-Engineers haben bei Breakpoint-Konferenzen<\/a> \u00fcber den Druck gesprochen, den ein zweiter Client auf die Referenzimplementierung legt: Scheduler-Entscheidungen, die zuvor als \u201eder 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\u00fcr Endnutzer sp\u00fcrbarer Geschwindigkeitsgewinn geworden.<\/p>\n\n\n\n

Was dies f\u00fcr DeFi-Plattformen \u00e4ndert<\/h2>\n\n\n\n

Eine Slot-Zeit von 200 ms f\u00fchlt sich nicht nur besser an. Sie \u00e4ndert 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\u00fcr diese Oracle-Prints enger ziehen, wenn Slots doppelt so schnell aufeinanderfolgen. Das Team hat zwar noch kein vollst\u00e4ndig aktualisiertes Risikomodell ver\u00f6ffentlicht, doch das relevante Drift-protocol Repository<\/a> 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\u00e4ufiger aktualisieren k\u00f6nnen, ohne die Positionssicherheit zu verlieren.<\/p>\n\n\n\n