Solana Alpenglow: Wie Votor und Rotor die Finalität auf 150 ms drücken sollen

Warum Solana den Konsens umbauen will

Solana ist schon heute für niedrige Latenz bekannt. Der wichtige Unterschied liegt aber zwischen einer Transaktion, die sich schnell bestätigt anfühlt, und einer Transaktion, die vom Konsens endgültig als abgeschlossen gilt.

Die aktuelle Architektur nutzt Proof of History als kryptografischen Zeit- und Ordnungsmechanismus: Leader-Knoten versehen Blöcke mit Nachweisen, die Validatoren prüfen können . Darauf setzt Tower BFT auf. Dieser Mechanismus stapelt Validator-Stimmen mit sogenannten Lockouts; jede Stimme bestätigt einen Fork und verlängert die Sperrfristen früherer Stimmen .

Das hat Solana schnelle optimistische Bestätigungen ermöglicht. Anza beschreibt Solanas heutige optimistische Finalität in der Größenordnung von etwa einer Sekunde, während SIMD-0326 die stärkere Tower-BFT-Finalität mit 12,8 Sekunden und Alpenglow mit 100–150 ms vergleicht . Genau hier setzt Alpenglow an: nicht nur bei gefühlter Geschwindigkeit, sondern beim Zeitpunkt, ab dem Konsens-Finalität erreicht ist.

Votor: Finalität in ein oder zwei Runden

Votor ist der Teil von Alpenglow, der Voting und Block-Finalisierung übernehmen soll . In SIMD-0326 wird Votor als leichtgewichtiges, direktes Voting-Protokoll beschrieben, das Blöcke je nach Netzwerkbedingungen entweder in einer einzelnen oder in zwei Abstimmungsrunden finalisieren kann .

Das ist ein deutlicher Bruch mit Tower BFTs Vote-Tower-Logik. Statt über eine längere Kette von Stimmen und Lockouts Finalität aufzubauen, soll Votor schneller zu einem eindeutigen Ergebnis kommen, sofern ausreichend Stake teilnimmt. Einige technische Drittanalysen sprechen von Stake-Schwellen im Bereich von 60 % bis 80 %; die robustere Aussage aus der Primärvorlage bleibt jedoch das Ein- oder Zwei-Runden-Modell aus SIMD-0326 .

Anza beschreibt Alpenglow außerdem als Konsens-Engine, die BLS-Kryptografie nutzt, um Finalisierungslatenz deutlich zu senken und zugleich Sicherheit zu erhalten . Der Anspruch ist also nicht bloß eine schnellere Meldung im Wallet, sondern ein kürzerer Weg zu deterministischer Finalität.

Rotor: Blockdaten müssen genauso schnell ankommen

Rotor ist Alpenglows Protokoll für Datenverteilung. Anza beschreibt es als Weiterentwicklung der bisherigen Turbine-Idee, also des Systems, mit dem Solana Blöcke im Validator-Netzwerk verteilt .

Der Grund ist simpel: Votor kann nur schnell finalisieren, wenn Validatoren die relevanten Blockdaten schnell genug erhalten, prüfen und darüber abstimmen können. Schnelles Voting ohne schnelle Blockausbreitung wäre nur die halbe Lösung.

Drittanalysen beschreiben Rotor als stärker strukturierte, stake-gewichtete Relay-Architektur. Genannt werden Ziele unter 100 ms für Block-Broadcasts und in einem Bericht sogar 18 ms unter typischen Netzwerkbedingungen . Diese Zahlen sollten als Zielwerte oder Schätzungen gelesen werden, nicht als bereits bewiesene Mainnet-Messwerte. Sie erklären aber, warum Rotor und Votor zusammen gedacht werden: schnellere Blockverteilung stützt schnellere Finalität.

Was sich verbessern könnte – und wo Vorsicht angebracht ist

Kurz gesagt: Alpenglows direktestes Versprechen ist niedrigere Latenz bis zur Finalität. Die möglichen Vorteile für Durchsatz und Validator-Kosten kommen vor allem daher, dass Konsensverkehr – insbesondere Vote-Overhead – reduziert werden soll.

Zeitplan: Governance geschafft, Mainnet noch offen

Anza stellte Alpenglow als neuen Konsens für Solana vor und bezeichnete das Projekt als die größte Änderung am Kernprotokoll der Blockchain . Die formale SIMD-0326-Vorlage folgte im August 2025 und beschreibt Alpenglow als umfassende Überarbeitung des Solana-Konsensprotokolls .

Die Abstimmung begann laut SolanaFloor am 27. August 2025 mit Epoche 840 und lief bis Epoche 842 . Anfang September 2025 war die Governance-Hürde genommen. Bei den gemeldeten Zustimmungswerten gibt es leichte Unterschiede: Alchemy nennt 98,27 % Zustimmung, Blockworks 98,94 % der teilnehmenden Stimmen; beide berichten von rund 52 % Stake-Beteiligung . Der gemeinsame Kern: Die Validator-Unterstützung war überwältigend.

Weniger eindeutig ist der Weg vom Testbetrieb ins Mainnet. Eine Anza-Roadmap nannte zunächst eine Erwartung für Anfang 2026, während eine spätere Alchemy-Zusammenfassung aus April 2026 Alpenglow in privaten Cluster-Tests sah und den Mainnet-Start eher Ende 2026 erwartete . Anza schrieb außerdem, der Fokus 2026 liege darauf, Alpenglow aus Entwicklungsclustern in breitere Deployment-Arbeit zu bringen .

Die vorsichtigste Lesart lautet daher: Vorschlag und Governance im dritten Quartal 2025, Entwicklung und private Cluster-Tests im Jahr 2026, möglicher Mainnet-Rollout 2026 – mit Ende 2026 als konservativerem Erwartungswert, falls Tests und Implementierung der entscheidende Engpass bleiben .

Fazit

Wenn Alpenglow wie vorgeschlagen ausgerollt wird, wäre es Solanas bislang folgenreichster Konsens-Umbau. Votor soll Voting und Finalität auf ein oder zwei schnelle Runden verdichten; Rotor soll Blockdaten so schnell durch das Validator-Netz bewegen, dass dieser neue Finalitätsweg praktisch nutzbar wird .

Die Zahl von 100–150 ms ist spektakulär, sollte aber bis zum Nachweis im Mainnet als technisches Ziel verstanden werden. Der Governance-Rückenwind ist da. Ob sich die versprochenen Verbesserungen bei Finalität, Vote-Overhead, Blockspace und Validator-Kosten tatsächlich im Live-Betrieb zeigen, entscheidet sich erst mit Tests, Client-Reife und realen Netzwerkbedingungen .