Alpenglow: Solanas großer Konsens-Umbau

Praktische Erkenntnisse 

• Der wichtigste Vorteil von Alpenglow für Solana ist eine 100-mal kürzere Zeit bis zur endgültigen Bestätigung einer Transaktion. Abhängig vom geografischen Standort eines Validators sinkt sie von 12,8 Sekunden auf 100–150 ms. Damit kann Solana mit stärker zentralisierter Web2-Infrastruktur konkurrieren und Echtzeitanwendungen ermöglichen.
• Alpenglow vereinfacht den Konsens, indem es mehrere ältere Komponenten von Solana entfernt, darunter Proof of History, Tower BFT und die Gossip-basierte Weiterleitung von Votes. Anstelle von Proof of History führt Alpenglow eine feste Blockzeit von 400 ms ein. Diese ist nicht mit einer global synchronisierten Uhr gleichzusetzen und koordiniert das Timing im gesamten Netzwerk.
• Das Protokoll basiert auf zwei grundlegenden Komponenten: Rotor, einem verbesserten Protokoll zur Blockweiterleitung, das Solanas bestehende Turbine-Architektur erweitert und optimiert, und Votor, einem neuen Abstimmungsmechanismus, der Tower BFT, Proof of History und Gossip zur Weiterleitung von Votes ersetzt.
• Alle Konsensaktivitäten werden off-chain verlagert – Vote-Zertifikate werden weiterhin on-chain verankert. Dabei ersetzt ein schlankes BLS-Zertifikatsystem die Vote-Transaktionen pro Slot. Diese Änderung beseitigt Vote-Gebühren in ihrer heutigen Form. Sie waren bislang die wichtigsten Betriebskosten für Validatoren. Dadurch verbessert sich die Wirtschaftlichkeit besonders für kleinere Betreiber erheblich. Das genaue Wirtschaftsmodell wird noch ausgearbeitet.
• Alpenglow bietet ein „20+20“-Resilienzmodell: Die Sicherheit bleibt erhalten, wenn Angreifer bis zu 20 % des Stakes kontrollieren. Die Verfügbarkeit bleibt erhalten, wenn weitere, separate 20 % des Stakes offline sind oder nicht reagieren. So toleriert das Protokoll sowohl feindliche als auch instabile Netzwerkbedingungen.
• Votor verwendet für den Konsens ein zweistufiges, paralleles Abstimmungssystem. Beim Fast-Finalization-Pfad wird ein Block sofort mit einem Fast-Finalization Certificate finalisiert, wenn er in der ersten Runde die Zustimmung von ≥80 % des Stakes erhält. Beim Slow-Finalization-Pfad beginnt eine zweite Runde, sobald ein Block die Zustimmung von ≥60 % des Stakes erhält. Erreicht diese Runde eine Zustimmung von ≥60 %, wird der Block mit einem Finalized Certificate finalisiert.
• Anders als Turbine, das eine mehrschichtige Baumstruktur mit einem Fanout von 200 nutzt, verwendet Rotor ein Single-Hop-Modell, bei dem Relay-Nodes die Shreds verteilen. Jeder Shred wird als einzelnes, mit einem Erasure Code codiertes Paket übertragen. Das Design von Rotor ist nativ mit Multicast-Systemen wie DoubleZero kompatibel. Beachte, dass Rotor im Vergleich zu Votor höchstwahrscheinlich ein separates SIMD sein wird.
• Alpenglow soll derzeit voraussichtlich Anfang nächsten Jahres im Solana-Mainnet eingeführt werden. Eine Referenzimplementierung des Protokolls findest du auf Github.

Einführung

Der Alpenglow-Konsensalgorithmus ist der bisher bedeutendste Umbau des Solana-Kernprotokolls. Er basiert auf den neuesten Fortschritten der Blockchain-Forschung und gestaltet grundlegend neu, wie das Netzwerk Konsens erreicht.

Alpenglow ist das Werk der neuen Forschungsabteilung von Anza. Sie wird von Professor Roger Wattenhofer von der ETH Zürich geleitet, einer der weltweit führenden Informatikinstitutionen. Professor Wattenhofer ist ein führender Experte für verteilte Systeme. Er war zuvor Mitautor des 2024 veröffentlichten Papers Halting the Solana Blockchain with Epsilon Stake, das mögliche Verfügbarkeitslücken im aktuellen Konsensprotokoll von Solana aufzeigte. Bei Anza arbeiten außerdem seine ehemaligen Doktoranden Kobi Sliwinski und Quentin Kniep mit ihm zusammen.

Das Team sollte Solanas Konsensalgorithmus neu gestalten, um ihn leistungsfähiger und nachweislich korrekt zu machen, ohne seine Turbine-basierte Architektur aufzugeben. Alpenglow integriert viele der neuesten Fortschritte aus der Forschung zu verteilten Systemen, insbesondere beim Umgang mit feindlichem Netzwerkverhalten.

Der Name Alpenglow leitet sich vom deutschen Wort Alpenglühen ab. Es bezeichnet das markante Licht auf Berggipfeln bei Sonnenauf- oder Sonnenuntergang und verweist auf den Schweizer Ursprung des Protokolls.

Welche Vorteile bietet Alpenglow?

Im Folgenden findest du eine allgemeine Zusammenfassung der wichtigsten erwarteten Vorteile von Alpenglow. Im weiteren Verlauf des Artikels gehen wir ausführlicher auf jeden davon ein.

Schnellere Finalität

Der wichtigste Vorteil von Alpenglow für Solana ist eine 100-mal kürzere Zeit bis zur Finalität einer Transaktion, also bis Nutzertransaktionen dauerhaft in einem Blockchain-Netzwerk verankert sind. Abhängig vom geografischen Standort eines Validators sinkt sie von 12,8 Sekunden auf 100–150 ms. Damit kann Solana mit stärker zentralisierter Web2-Infrastruktur konkurrieren und Echtzeitanwendungen ermöglichen.

• Aktuelle Finalität von Solana: 12,8 Sekunden 
• Aktuelle optimistische Bestätigung von Solana: 500–600 Millisekunden
• Finalität mit Alpenglow: 150 Millisekunden (Median)*
• Schnellste Finalität eines Wettbewerbers: 400 Millisekunden (Eigenangabe)

*schwankt je nach geografischer Lage und Cluster-Verteilung.

Keine Vote-Transaktionen mehr

Mit Alpenglow finden alle Konsensaktivitäten off-chain statt. Das entlastet die Transaction Processing Unit (TPU) und das Replay, da beide keine Vote-Transaktionen mehr verarbeiten müssen.

Alpenglow verbessert außerdem die Wirtschaftlichkeit für kleinere Validatoren erheblich. Die Gebühren für Vote-Transaktionen sind die größten Betriebsausgaben für Validatoren. Off-chain-Abstimmungen beseitigen diese Gebühren und senken die Teilnahmekosten drastisch. Dadurch können kleinere Validatoren leichter arbeiten, und die Einstiegshürde für Beiträge zur Netzwerksicherheit sinkt.

Weitere Vorteile sind eine einfachere Commitment-Logik und ein langsamer wachsendes Ledger, da Vote-Transaktionen weder Blockspace belegen noch das Ledger vergrößern.

Diese Umstellung beseitigt außerdem Unklarheiten bei Solanas Kennzahl für Transaktionen pro Sekunde (TPS). Heute wird TPS häufig auf zwei Arten angegeben: als Gesamt-TPS einschließlich Vote-Transaktionen und als tatsächliche TPS, die nur andere Transaktionen zählt.

Ein schlankeres Protokoll

Alpenglow vereinfacht den Konsensprozess, indem es mehrere ältere Komponenten von Solana entfernt, darunter Proof of History, Tower BFT und Gossip zur Weiterleitung von Votes. Es integriert modernste Fortschritte aus der aktuellen Blockchain-Forschung, ohne unnötige Komplexität einzuführen.

Votor und Rotor von Alpenglow bilden die Grundlage für künftige Upgrades wie asynchrone Ausführung und mehrere parallele Leader (MCL). Damit ist Solana gut für weitere Performance-Steigerungen und die Weiterentwicklung des Protokolls aufgestellt.

Wie funktioniert Solanas aktueller Konsensmechanismus?

Proof of History

Proof of History (PoH) ist kein Konsensalgorithmus. Es ist vielmehr ein Hilfsmittel, um Konsens zu erreichen. Die Verwirrung entsteht wahrscheinlich durch die Bezeichnung „Proof of X“. Wer Proof of Work und Proof of Stake kennt, könnte daraus schließen, dass es sich um einen Konsensalgorithmus handelt. Sinnvoller ist es, PoH als „Vorkonsens“-Algorithmus zu betrachten, der den Konsens durch effiziente Transaktionsverarbeitung optimiert.

Auf hoher Ebene ist PoH eine dezentrale Uhr, die Zeit in einem feindlichen Netzwerk nachweisbar macht. Formaler ausgedrückt ist PoH eine kryptografische Zeitstempelfunktion, mit der sich Nodes auf eine Reihenfolge von Ereignissen einigen können, ohne miteinander zu kommunizieren. Sie verwendet eine sequenzielle, gegen Preimage-Angriffe resistente Hashfunktion, um eine Hashkette zu erzeugen. Leader versehen Blöcke anhand dieser Hashes mit Zeitstempeln und weisen damit nach, dass eine bestimmte Zeitspanne vergangen ist. Da alle Hashes verkettet sind, liefert PoH einen historischen Nachweis dafür, dass Daten zu einem bestimmten Zeitpunkt existierten. 

Dieser Ansatz unterscheidet sich von anderen Chains, die die Blockreihenfolge häufig während des Konsenses festlegen und anschließend Zeitstempel hinzufügen. Bei Solana wird stattdessen zuerst eine kryptografisch verifizierbare Uhr aufgebaut. Transaktionen werden entlang dieser Uhr gestreamt, und der Konsens prüft das vorsortierte Transaktionsprotokoll. Die Hashverkettung macht die zeitliche Reihenfolge unbestreitbar. 

Tower BFT

Tower BFT kommt zum Einsatz, nachdem Shreds, also Teilblöcke, an andere Validatoren verteilt wurden und das Netzwerk sie erneut ausgeführt hat, um zu entscheiden, ob der Block Teil des Ledgers wird. Konzeptionell ist es ein pBFT-ähnlicher Konsensalgorithmus, der die netzwerkweite Uhr von Proof of History nutzt. Statt für jeden Slot eine synchrone Konsensrunde zu benötigen, verpflichten sich Validatoren anhand der bereits beobachteten Proof-of-History-Sequenz im Voraus auf künftige Slots. Das ermöglicht eine kontinuierliche Blockproduktion.

Validatoren senden pro Slot eine Vote-Transaktion, die von ihrem Vote-Account signiert wird. Votes für einen bestimmten Fork lösen einen Lockout, also eine Sperrfrist, für diesen Fork aus. Ein Lockout ist eine festgelegte Anzahl von Slots, während der ein Validator nicht für einen anderen Fork stimmen kann. Dadurch sollen sich Validatoren auf einen Fork festlegen. Wenn sie den Fork wechseln wollen, verlängert sich der Lockout exponentiell. Jeder Vote enthält einen Lockout-Zähler, der sich jedes Mal verdoppelt, wenn der Validator für einen nachfolgenden Slot stimmt. So entsteht ein „Vote Tower“ aus Verpflichtungen. Stimmt ein Validator also für Block X, ist er für eine exponentiell wachsende Zahl künftiger Slots davon ausgeschlossen, für einen widersprüchlichen Fork zu stimmen, etwa für 1, 2, 4, 8 … Slots. Ein Verstoß gegen den Lockout ist nachweisbar und kann bestraft werden, obwohl Slashing im Mainnet noch nicht aktiviert wurde.

Solana erreicht unter Tower BFT zwei Stufen der Finalität: optimistische Bestätigung und deterministische Finalität. 

Wenn ein neuer Block erzeugt wird und ≥66 % des Stakes für ihn stimmen, erkennt das Netzwerk ihn als Teil des führenden oder kanonischen Forks an. Dies wird als optimistische Bestätigung bezeichnet, da der Block die Commitment-Stufe „confirmed“ erhält, sobald eine qualifizierte Mehrheit für ihn gestimmt hat. Die optimistische Bestätigung wurde in v1.3 des Clients von Solana Labs, heute Agave, eingeführt. Sie verbessert die UX, indem ein Block bereits vor seiner formalen Finalisierung als final behandelt wird.

Seit Solanas Genesis-Block wurde noch nie ein optimistisch bestätigter Block zurückgesetzt. Dafür müsste mindestens ein Drittel des gesamten Stakes einen widersprüchlichen Fork offenlegen, nachdem 66 % bereits ehrlich abgestimmt haben. Anders ausgedrückt: Sobald die optimistische Bestätigung eines Blocks ~87 % des Stakes erreicht, müsste ein Angreifer ≥20 % desselben Stakes zu einer Doppelsignatur bewegen. Das ist nachweislich slashbar. Obwohl die optimistische Bestätigung im streng konsenstheoretischen Sinn keine absolute Finalität bietet, liefert sie in der Praxis starke Garantien. Diese Blöcke können für fast alle Anwendungsfälle als final betrachtet werden. Deshalb wird Solanas Finalität für praktische Zwecke häufig mit 500–600 Millisekunden angegeben.

Für echte deterministische Finalität muss ein Block den maximalen Lockout im Vote Tower erreichen. Dafür müssen ihn 32 aufeinanderfolgende Votes bestätigen. Auf dem Block müssen also 32 weitere Blöcke aufbauen, bevor er als „finalized“ oder dauerhaft im Netzwerk verankert gilt. Wegen der Anforderung von 32 Slots und Slot-Zeiten von ~0,4 Sekunden dauert es ~12,8 Sekunden, bis ein Block deterministische Finalität erreicht. Sie ist erreicht, sobald die Tiefe der Lockout-Votes ein Rollback unmöglich macht.

Welche Einschränkungen hat Solanas aktueller Konsensmechanismus?

Proof of History und Tower BFT haben Solana zu hohem Durchsatz und schnellen optimistischen Bestätigungen verholfen. Dieses Design hat jedoch mehrere Einschränkungen bei Kosten, Latenz, Verfügbarkeit und Validator-Betrieb.

Hoher Abstimmungsaufwand und hohe Kosten

Jeder Validator muss kontinuierlich über jeden Slot abstimmen, um zum Konsens beizutragen. Votes sind Transaktionen, die mit dem Vote-Programm interagieren, Netzwerkressourcen verbrauchen und Gebühren kosten. 

Etwa drei Viertel aller Transaktionen auf Solana sind Vote-Transaktionen. Sie verursachen erheblichen Netzwerkaufwand und für Validatoren in jedem Slot reale Kosten. Diese unnötige Abhängigkeit von ununterbrochenen Abstimmungen führt zu hohem Aufwand und Kosten, die mit der Zahl der verarbeiteten Slots und Validatoren im Cluster steigen. 

Latenz bis zur Finalität

Die optimistische Bestätigung ist schnell, die deterministische Finalität jedoch nicht. ~12,8 Sekunden sind im Vergleich zu neueren Konsensprotokollen wie Mysticeti von Sui langsam, das eine Finalität von ~500 ms erreicht. Das verursacht Probleme für Anwendungen wie Börsen, die absolute Sicherheit für ihren Betrieb benötigen. In der Praxis vertrauen Nutzer bestätigten Blöcken. Das Netzwerk muss jedoch weiterhin lange Fork-Verläufe vorhalten, falls vor der Finalisierung kleinere Reorganisationen auftreten. 

Die Lücke zwischen optimistischer Bestätigung und deterministischer Finalität ist ein Kompromiss: Tower BFT bevorzugt Verfügbarkeit mit einem kurzen Zeitfenster für mögliche Forks, nimmt dafür aber eine langsamere Finalität in Kauf. Selbst ohne Angriffe oder Konsensfehler wirken ~12,8 Sekunden im Vergleich zu Chains mit schneller Finalität und bestehender Web2-Infrastruktur langsam.

Verfügbarkeit und Toleranz gegenüber Netzwerkpartitionen

Tower BFT erfordert, dass eine qualifizierte Mehrheit der Validatoren online ist und reagiert, um neue Blöcke zu bestätigen und zu finalisieren. Der Konsens kann zum Stillstand kommen, wenn mehr als ein Drittel des Stakes offline oder das Netzwerk stark partitioniert ist. Solana kann weiterhin Blöcke produzieren und damit Verfügbarkeit priorisieren. Das Netzwerk erreicht jedoch möglicherweise nicht die Abstimmungsschwelle, um diese Blöcke optimistisch zu bestätigen. Im schlimmsten Fall, wie bei den jüngsten Ausfällen von Solana, können Validatoren beim Warten auf Votes festhängen oder den optimistischen Fork nicht verarbeiten. Das kann einen Netzwerkstillstand auslösen, der einen koordinierten Neustart erfordert.

Das ist eine klassische Einschränkung des BFT-Konsenses. Solana berücksichtigt nicht nativ, dass große Teile der Validatoren vorübergehend nicht reagieren. Unter extremen Bedingungen litt daher Solanas Verfügbarkeit, weil das Protokoll ein Unterschreiten der qualifizierten Mehrheit für den Konsens nicht kontrolliert bewältigen konnte. Tower BFT musste weiterhin Blöcke produzieren, obwohl weniger als 60 % des Stakes online waren. Diese Blöcke konnten nie optimistisch bestätigt werden und lassen sich möglicherweise zurücksetzen.

Betriebliche Komplexität für Validatoren

Tower BFT stellt hohe Anforderungen an Validatoren: kontinuierliche Vote-Transaktionen, robuste Netzwerkanbindungen, Client-Upgrades, das Vermeiden von Ausfällen und die dauerhafte Speicherung des „Tower State“. Startet ein Validator neu oder verliert seinen neuesten Tower State, riskiert er einen Vote, der gegen eine frühere Lockout-Verpflichtung verstößt. Das führt zum Verlust von Vote Credits.

Da das Protokoll auf kontinuierliches Hashing durch Proof of History und Gossip zur Weiterleitung von Votes angewiesen ist, müssen Validatoren intensiv arbeiten, um mit Solanas Slot-Zeit von ~400 ms Schritt zu halten. Auch Solanas hohe Hardwareanforderungen sind trotz ihrer kontinuierlichen Senkung nicht unerheblich. Unabhängig von ihrem Stake müssen außerdem alle Validatoren über jeden Slot abstimmen, um ihre Rewards zu maximieren. Kleinere Validatoren zahlen daher größtenteils dieselben Gebühren und bewältigen dieselbe Arbeitslast wie größere. Da Leader-Slots proportional zum Stake zugeteilt werden, produzieren Validatoren mit mehr Stake mehr Blöcke und erhalten dadurch einen größeren Anteil der von anderen Validatoren gezahlten Vote-Gebühren. So entsteht ein Kreislauf, in dem Vote-Gebühren Kapital effektiv zu Validatoren mit höherem Stake umverteilen.

Außerdem macht Solanas aktueller Konsensmechanismus das Replay doppelter Blöcke extrem komplex, da Clients mehrere Kandidaten für denselben Slot verwalten müssen. Das Zertifikatsystem von Votor garantiert, dass jeder Slot entweder einen einzelnen Hash oder einen expliziten Skip festschreibt. Dadurch wird das Replay doppelter Blöcke trivial.

Es wird deutlich, dass das innovative Design von Tower BFT erhebliche betriebliche Komplexität für Validatoren verursacht.

Wie funktioniert Alpenglow?

Alpenglow basiert auf zwei Kernkomponenten:

• Rotor: ein verbessertes Protokoll zur Blockweiterleitung, das auf der bestehenden Turbine-Architektur aufbaut und sie optimiert.
• Votor: ein neues Abstimmungsprotokoll, das Tower BFT, Gossip-basierte Vote-Weiterleitung und Proof of History für die Konsensteilnahme ersetzt.

In den folgenden Abschnitten betrachten wir diese Komponenten im Detail.

Rotor: Neue Schicht zur Datenverteilung

Rotor ist ein verbessertes Protokoll zur Blockweiterleitung. Es baut auf Solanas bestehendem Turbine-Design auf und verbessert vor allem Effizienz und Einfachheit. Anders als Turbine, das eine mehrschichtige Baumstruktur mit einem Fanout von 200 verwendet, nutzt Rotor ein Single-Hop-Modell (2δ). 

Blöcke werden in Slices aufgeteilt. Anschließend wird jeder Slice mithilfe von Reed-Solomon-Erasure-Codes in mehrere Shreds codiert. Um die Authentizität der Shreds sicherzustellen, erstellt der Leader aus ihren Hashes einen Merkle-Baum und signiert dessen Root. Jeder Shred enthält seinen Pfad in diesem Baum sowie die Signatur des Leaders.

Jeder Shred wird direkt an einen Relay-Node gesendet. Die Relays übertragen ihren Shred anschließend an alle Nodes im Netzwerk, zuerst an den nächsten Leader. Dieser einschichtige Ansatz reduziert die Latenz und vereinfacht den Weiterleitungspfad. Außerdem ist er überraschend schnell:

Sowohl der Leader als auch die Shred-Relays werden durch Stake-gewichtete Stichproben ausgewählt. Jeder Node ist damit für die Übertragung einer Datenmenge verantwortlich, die proportional zu seinem Stake ist. Dank der Erasure-Codierung müssen Nodes nur einen Teil der Shreds empfangen, um den ursprünglichen Block-Slice zu rekonstruieren.

Ein wesentlicher Unterschied zu Turbine ist, dass Rotor nur eine einzelne Erasure-codierte Version jedes Shreds überträgt. Separate Daten- und Recovery-Shreds wie bei Turbine sind nicht nötig. Die Redundanz, also das Datenexpansionsverhältnis, bleibt gleich. Dieses Design verhindert jedoch fragwürdige Strategien bei der Weiterleitung von Daten-Shreds und hält das Protokoll einfach.

Die Architektur von Rotor ist außerdem mit Multicast-Systemen wie DoubleZero kompatibel und bietet Flexibilität bei der Zustellung von Blöcken. Da die Blockweiterleitung erhebliche Bandbreite verbraucht – große Validatoren erreichen derzeit fast 150.000 ausgehende Pakete pro Sekunde –, führt Rotor ein Modell ein, das Relays für die Datenverteilung belohnt. So richten sich die Anreize an der Performance des Netzwerks aus.

Das Alpenglow-Whitepaper definiert keinen konkreten Mechanismus zur Berechnung oder Verteilung von Rewards. Es weist jedoch darauf hin, dass Rotor-Rewards die verbrauchte Bandbreite berücksichtigen sollten. Nodes, die mehr Daten weiterleiten, sollen einen größeren Anteil der Rewards erhalten.

Was ist Blokstor?

In Blokstor speichern und verwalten Nodes die von Rotor empfangenen Blockdaten. Formaler ausgedrückt ist Blokstor eine Datenstruktur, die die Speicherung von Slices verwaltet. Beim Empfang eines Shreds wird sein Inhalt zu Blokstor hinzugefügt, wenn bestimmte Bedingungen erfüllt sind. Dazu gehören:

• Blokstor enthält noch keinen Shred für diese Indizes
• Eine gültige Leader-Signatur
• Ein gültiger Merkle-Baum-Pfad

Blokstor löst das Ereignis "Block(slot(b), hash(b) hash(parent(b)))" aus, wenn es den ersten vollständigen Block b für slot(b) empfängt. Blokstor kann außerdem Reparaturverfahren ausführen, um alternative Blöcke für denselben Slot zu sammeln und zu speichern. Sobald ein Block finalisiert ist, darf Blokstor im betreffenden Slot nur diesen Block speichern.

Votor: Neue Engine für Abstimmungen und Finalisierung

Votor ist Aplenglows neue Engine für Abstimmungen und Finalisierung. Sie ersetzt Tower BFT bei der Beglaubigung und Finalisierung von Blöcken. Votor ist von der Simplex-Forschungsreihe inspiriert, die Effizienz und Einfachheit verbessert, und überträgt deren Erkenntnisse auf einen Proof-of-Stake-Kontext. 

Simplex zeigt, dass sich in einem Proof-of-Stake-System mit rotierenden Leadern und extrem kleinen Nachrichten effizient byzantinische Einigung erreichen lässt, sofern es eine enge Obergrenze für die Netzwerkverzögerung gibt. Aufbauend auf diesen Erkenntnissen erreicht Votor den Konsens in einer oder zwei Runden.

Auf hoher Ebene stellt Votor sicher, dass es für jeden Slot entweder ein Skip Certificate gibt, das einen übersprungenen Slot kennzeichnet, oder einen beglaubigten Block, der auf der kanonischen Chain beglaubigter Blöcke aufbaut. Damit ein Block beglaubigt wird, braucht er ein gültiges Zertifikat. Statt Gossip mit Votes zu überfluten, senden Validatoren schlanke Vote-Nachrichten an eine Stake-gewichtete Gruppe von Peers. Dabei entsteht eine Art „Direct-Send“-Mesh anstelle des traditionellen Solana-Gossips. Sobald ein Quorum erreicht ist, kann jeder Node diese Signaturen mithilfe des Boneh–Lynn–Shacham-(BLS)-Signaturschemas zu einem Zertifikat zusammenfassen. Dadurch entfallen Vote-Transaktionen pro Slot. Stattdessen wird der Header des aggregierten Zertifikats on-chain verankert.

Wie funktioniert der Abstimmungsmechanismus von Votor?

Votor verwendet einen gestaffelten, parallelen Abstimmungsmechanismus, der in zwei Pfade unterteilt ist:

• Fast-Finalization: Erhält der vorgeschlagene Block in der ersten Abstimmungsrunde die Zustimmung von ≥80 % des Stakes, wird er sofort finalisiert und ein Fast-Finalization Certificate erzeugt. Diese Finalisierung in einer Runde ist möglich, weil 80 % des Stakes deutlich über der Schwelle für eine qualifizierte Mehrheit liegen. Eine zweite Abstimmungsrunde ist daher nicht nötig.
• Slow-Finalization: Erhält die erste Abstimmungsrunde die Zustimmung von <80 %, aber ≥60 % des Stakes, startet Votor sofort eine zweite Abstimmungsrunde. Sobald diese zweite Runde die Zustimmung von ≥60 % des Stakes erreicht, wird ein Finalized Certificate erzeugt.

Beide Pfade laufen parallel. Der erste Pfad, der seinen Schwellenwert erreicht, finalisiert den Block. Sobald ein Leader die Verarbeitung des übergeordneten Blocks abgeschlossen hat, kann er mit der Übertragung des nächsten Blocks beginnen, während weiterhin Votes eingehen. Dadurch entsteht wie beim alten Konsens von Solana alle ~400 ms ein Block. Erhält die erste Runde nicht die Zustimmung von ≥80 % des Stakes, wechselt Votor mit diesem Design zur zweiten Abstimmungsrunde. Aufgrund der Überschneidung beim Stake können außerdem nicht zwei widersprüchliche Blöcke Finalität erreichen.

Was ist die Pool-Datenstruktur von Votor?

Der Pool ist eine Datenstruktur, die jeder Node führt. Sie dient als lokales Ledger für Abstimmungsaktivitäten und die Erzeugung von Zertifikaten. Sie speichert empfangene Votes für jeden Slot und jeden Node zwischen. Sobald genügend Votes eingegangen sind, wird ein entsprechendes Zertifikat erzeugt. Wird ein neu empfangenes oder selbst erzeugtes Zertifikat zum Pool hinzugefügt, überträgt der Node es an alle anderen Nodes. 

Mehrere Validatoren können fast gleichzeitig Zertifikate erzeugen. Für den Konsens ist jedoch jedes Zertifikat funktional gleichwertig, das die Quorumsschwelle erreicht – unabhängig davon, welche Validatoren konkret im Signatursatz enthalten sind. Die einzige Ausnahme ist das Finalized Certificate, da bis zu drei unterschiedliche Zertifizierungen im Umlauf sein können. Für einen bestimmten Slot gibt es über alle Typen hinweg nie mehr als vier eindeutige Zertifikate. Jedes eindeutige Zertifikat wird nur einmal übertragen. Dieser Ansatz verhindert Vote-Spam. Gleichzeitig kann jeder ehrliche Node das Zertifikat erzeugen und teilen, sobald der Pool ein Quorum anzeigt.

Wichtigste Erkenntnisse

Votes werden als einzelne UDP-Pakete an alle Validatoren gestreamt. Diese speichern empfangene Votes für jeden Slot und jeden Node zwischen. Die Beglaubigung und Finalität eines Blocks unter Votor werden durch die folgenden drei Bedingungen bestimmt:

• Zustimmung von ≥80 % des Stakes in der ersten Abstimmungsrunde.
• Zustimmung von ≥60 % des Stakes in der ersten und zweiten Abstimmungsrunde.
• Der Validator empfängt von einem anderen Validator ein gültiges Zertifikat, das die Finalisierung des Blocks bestätigt.

Kein Proof of History mehr

Da Rotor Blockdaten in einem Hop verteilt und Votor eine angestrebte maximale Latenz von ~150 ms hat – darauf gehen wir im nächsten Abschnitt näher ein –, benötigt Solana keine dezentrale Uhr mehr. Einfache lokale Uhren reichen aus. Alpenglow ersetzt Proof of History durch lokale Timeout-Timer.

Wie funktioniert der Timeout-Mechanismus von Votor?

In der Praxis funktioniert das Timeout-System wie folgt:

• Leader-Fenster: Der Leader ist für ein Fenster aus vier Slots mit jeweils Δblock ≈ 400ms verantwortlich.
• Datenankunft oder Timeout: Sobald der übergeordnete Block eines Leaders beglaubigt ist, starten alle Validatoren ihre Timeouts und legen vier Fristen fest – eine pro Slot – bei t = now + Δtimeout + slotIndex * Δblock, wobei Δblock ≈ 400ms gilt. Diese Timer werden nie zurückgesetzt und dienen als Obergrenzen. Treffen die Shreds eines Blocks rechtzeitig ein, stimmt der Validator mit einer NotarVote-Nachricht über den Slot ab und der ausstehende Timeout bleibt ohne Wirkung. Läuft die Zeit jedoch ab, bevor Shreds eintreffen, geht der Validator davon aus, dass der Leader unehrlich oder ausgefallen ist, und sendet einen SkipVote.
• Zertifizierung: Für beglaubigte Blöcke wird wie oben beschrieben ein Fast-Finalization oder Finalized Certificate erzeugt. Für übersprungene Slots kann außerdem ein Skip Certificate erzeugt werden.

Alpenglow führt ein System ein, bei dem jeder Validator Timeouts lokal und unabhängig misst. Solana benötigt daher keine einzelne Hash-basierte Uhr wie Proof of History. Da Nachrichten nur aus einem einzelnen UDP-Paket bestehen und Rotor nur einen Hop benötigt, ist die Grenze von 400 ms ohne Hashing realistisch. Validatoren müssen nicht mehr kontinuierlich Hashes berechnen, können ohne Lockouts gegen Blöcke stimmen und alternative Clients wie Firedancer müssen die Proof-of-History-Implementierung des Agave-Clients nicht nachbilden.

Slots überspringen

Validatoren können einen Slot auch überspringen, indem sie eine SkipVote-Nachricht senden. Wenn ≥60 % des Stakes einen SkipVote abgeben, wird ein Skip Certificate erzeugt und der Slot formal übersprungen. Skip Votes haben für Rewards dasselbe Gewicht wie Votes zur Beglaubigung. Validatoren haben daher keinen Anreiz, bei Fehlverhalten eines Leaders zu schweigen. Beachte, dass sich dies ändern kann, sobald das Wirtschaftsmodell für Alpenglow fertiggestellt ist.

Validatoren senden einen SkipVote für einen Slot, sobald sie feststellen, dass sie keinen Block für diesen Slot finalisieren können. Gründe dafür können ein Timeout, ein fehlender Block oder ein ungültiger beziehungsweise fehlerhafter Block sein. Tritt eine dieser Bedingungen im ersten Slot des vier Slots umfassenden Leader-Fensters ein, markieren die Validatoren das gesamte Fenster als fehlerhaft. Sie durchlaufen dann die verbleibenden Slots im Fenster und senden SkipVotes für jeden Slot, über den sie noch nicht abgestimmt haben. So kann das gesamte Fenster aus vier Slots in einer einzigen Skip-Runde zusammenfallen. Jeder Vote gilt weiterhin nur für einen Slot. Da die meisten Validatoren jedoch denselben Burst senden, erreichen alle drei ausstehenden Slots ungefähr gleichzeitig die Schwelle von 60 %. Dadurch wartet der Cluster nicht drei weitere leere Slots untätig ab, während der Timeout eines Offline-Leaders abläuft.

Dadurch entstehen natürlich Lücken in der Blockproduktion. Dank der schnellen Skip Certificates läuft der Slot-Takt jedoch ohne Unterbrechung weiter. Das vereinfacht die Fork-Auswahl und verbessert die Konsistenz, da ein Skip Certificate für diesen Slot als kanonischer „Null-Block“ dient. Alle ehrlichen Nodes übernehmen den Skip als Ergebnis. Es entsteht daher kein konkurrierender Fork, und übersprungene Slots führen nicht zu dauerhaften Forks. Die reguläre zeitliche Abfolge der Blockproduktion bleibt erhalten.

Validator-Rewards

Validator-Rewards unter Votor basieren auf der Teilnahme an Abstimmungen und der Erzeugung von Zertifikaten. Nodes, die durch Votes zum Konsens beitragen, werden gleich belohnt – unabhängig davon, ob sie für (NotarVote) oder gegen (SkipVote) einen Block stimmen. Das fördert ehrliche Teilnahme und stellt sicher, dass Nodes anhand ihres eigenen Zustands abstimmen, statt die Mehrheit vorherzusagen oder sich ihr anzupassen.

Eine genaue Implementierung der Rewards wurde bisher nicht festgelegt.

Alpenglow-Performance-Benchmarks und Simulationsergebnisse

Simulationen von Anza zeigen, dass Alpenglow einen Block in etwa 100–150 ms finalisiert. Die genaue Dauer hängt davon ab, ob der Fast-Finalization- oder der Fallback-Pfad (also die langsame Finalisierung) den Block notariell bestätigt. Der Fast-Finalization-Pfad zielt auf eine Latenz von ~100 ms, der Slow-Finalization-Pfad auf ~150 ms.

Latenzhistogramm

Die Netzwerklatenz setzt in jedem verteilten System eine grundlegende Untergrenze für die Kommunikation. Befindet sich der Leader beispielsweise in New York und der Großteil des Stakes in Europa, kann die mediane Latenz in eine Richtung, mit der ein Node Informationen an andere Netzwerk-Nodes sendet, etwa 200 Millisekunden erreichen. Bei geografisch nah beieinanderliegenden Nodes ist die Latenz niedriger, etwa innerhalb desselben Rechenzentrums oder derselben Region. Bei Nodes im Globalen Süden oder anderen weit entfernten Regionen ist sie deutlich höher.

• Netzwerk: Die Netzwerklatenz, um 1 Bit über das Internet an andere Nodes zu senden
• Rotor: Wie viel langsamer Rotor im Vergleich zu dieser Untergrenze ist
• Notarielle Bestätigung: Die Zeit bis zum Empfang notariell bestätigter Votes von 60 % des Stakes (eine weitere Abstimmungsrunde ist ebenfalls möglich; nach dem Empfang kann die Finalisierung beginnen)
• Finalität: Finalisierungszeit

Die Gesamtfinalität von Alpenglow liegt beim Doppelten der Untergrenze. Der Consensus-Overhead verdoppelt also die reine Netzwerkuntergrenze. Beträgt der längste Hop in eine Richtung zwischen dem Leader und dem Stake der Supermajority beispielsweise ~70 ms (also ~140 ms RTT), sollte die Finalität über den schnellen Pfad im Bereich von 120–150 ms liegen.

Das Latenzhistogramm aus den Simulationen von Anza zeigt, dass 65 % des Stakes innerhalb von 50 ms über der reinen Netzwerklatenz finalisieren. Die meisten Validatoren stimmen also fast unmittelbar nach Eintreffen der Daten ab.

Mit Alpenglow liegen deterministische Commitments deutlich unter denen konkurrierender L1s. Dadurch nähert sich die Onchain-Erfahrung von Solana viel stärker der traditioneller Web2-Dienste an.

Sicherheits- und Fehlertoleranzanalyse von Alpenglow

Der Consensus von Alpenglow verbessert den traditionellen BFT-Consensus, der gegenüber Angreifern widerstandsfähig bleibt, solange diese höchstens 33 % des Netzwerk-Stakes kontrollieren. Dies wird als „3f + 1“ bezeichnet. Alpenglow senkt diese Grenze auf Grundlage der von Martin und Alvisi in Fast Byzantine Consensus eingeführten 5f+1-Grenze auf 20 % des Netzwerk-Stakes. Es verwendet ein „20+20“-Resilienzmodell, das die Sicherheit in zwei Bereiche aufteilt:

• Byzantinische Fehler ≤ 20 %: Die Sicherheit bleibt gewahrt, wenn feindliche Validatoren weniger als 20 % des gesamten Stakes kontrollieren. Dabei geht es um einen erheblichen Betrag in Milliardenhöhe, und der Angriff wäre leicht zu erkennen und zu bestrafen. Ein Angreifer riskiert somit seinen gesamten Stake, was solche Angriffe wirtschaftlich unrentabel macht.
• Nicht böswillige Ereignisse ≤ 20 %: Die Lebendigkeit bleibt gewahrt, wenn höchstens 20 % des gesamten Stakes – zusätzlich zum feindlichen Stake – offline, abgestürzt oder anderweitig nicht am Consensus beteiligt sind. Dazu gehören Netzwerkausfälle, Fehlkonfigurationen und Softwarefehler. Das Netzwerk kann Blöcke also weiterhin finalisieren, selbst wenn eine erhebliche Minderheit der Validatoren nicht reagiert.

Sicherheit

Die Sicherheit ist gewährleistet, solange der gesamte feindliche Stake ≤20 % beträgt und nicht verhindern kann, dass mindestens 60 % des ehrlichen Stakes an einem Fork teilnehmen. Unter diesen Bedingungen ist jeder Vote-Schwellenwert, den das Protokoll als final behandelt – also eine Runde im schnellen Pfad oder zwei Runden im langsamen Pfad –, hoch genug, um einen widersprüchlichen Schwellenwert auf einem anderen Fork auszuschließen. Versuchen feindliche Validatoren zu equivocaten, also für zwei verschiedene Forks zu stimmen oder zwei verschiedene Blöcke im selben Slot zu erzeugen, erhalten ehrliche Nodes schließlich ihre widersprüchlichen Signaturen. Das lässt sich leicht erkennen und sollte künftig idealerweise zu strafbaren Verstößen wie Slashing führen. 

Versucht ein Leader außerdem, einen ungültigen Block zu erzeugen, verweigern ehrliche Validatoren einfach ihre Stimme. Alpenglows Modell der direkten Kommunikation bei Abstimmungen erschwert es böswilligen Akteuren, einen ehrlichen Node mit Stake zu isolieren oder zu eclipsen, da die Stimmen der ehrlichen Mehrheit sie letztlich entlarven. Ein böswilliger Leader könnte den Consensus höchstens in den langsameren Pfad zwingen oder eine Verzögerung um einen Slot verursachen. Er kann die Chain jedoch nicht dauerhaft anhalten oder aufspalten.

Lebendigkeit

Die Lebendigkeit ist unter Bedingungen partieller Synchronität gewährleistet, solange die Fehlerschwellen eingehalten werden. Nach einer gewissen Netzwerkverzögerung können ehrliche Validatoren also kommunizieren und ≥60 % des Stakes für einen Block sammeln. Sind genau 20 % des gesamten Stakes offline, kann der schnelle Pfad weiterhin erfolgreich sein, wenn alle verbleibenden ehrlichen Nodes abstimmen. Sind etwas mehr als 20 % des gesamten Stakes offline, verwendet das Netzwerk konsequent den langsamen Finalisierungspfad mit einer zweiten Abstimmungsrunde. Die Finalität bleibt garantiert, wenn auch langsamer. Gutartige Ausfälle beeinträchtigen daher hauptsächlich die Performance und nicht die Sicherheit.

Hohe Ausfallsicherheit

Alpenglow wurde ausdrücklich für hohe Ausfallsicherheit unter schwierigen Netzwerkbedingungen entwickelt. Es bleibt also auch bei 20 % böswilligem und 20 % nicht reagierendem Stake sicher und betriebsfähig. 

Dies ist jedoch kein Allheilmittel für jeden denkbaren Fehler. Alpenglow ist eine erhebliche Verbesserung für Solana, beseitigt das Risiko von Netzwerkstillständen oder -ausfällen bei verletzten Annahmen aber nicht vollständig. Für die Erzeugung neuer Blöcke sind ≥60 % des Stakes erforderlich. Handeln ≥20 % des Stakes böswillig, könnten sie den Consensus verhindern oder einen Fehler verursachen. Innerhalb der festgelegten Grenzen garantiert Alpenglow jedoch Sicherheit und Lebendigkeit nach einer oder zwei Abstimmungsrunden.

Schwächt die Abschaffung von Proof of History die Sicherheit?

Obwohl Proof of History für den aktuellen Betrieb von Solana grundlegend ist, schwächt seine Abschaffung die Sicherheit in keiner wesentlichen Weise. Wie bereits erwähnt, ersetzt die universelle Grenze von 400 ms die Hash-Uhr von Proof of History. Selbst bei erheblichen Netzwerkverzögerungen verhindert die Überschneidung des Stakes in Votor – also ≥80 % bei einer Runde und ≥60 % + ≥60 % bei zwei Runden –, dass ehrliche Validatoren zwei verschiedene Forks genehmigen.

Allerdings verschieben sich dadurch die Garantien für die Lebendigkeit, da diese von der Synchronitätsannahme für Nachrichten abhängt. Die Lebendigkeit bleibt gewahrt, solange ehrliche Nachrichten innerhalb dieser Verzögerung eintreffen. Rotors Datenverteilung mit nur einem Hop und Votes in einzelnen Paketen halten die Latenz selbst unter Last deutlich innerhalb des 400-ms-Fensters.

Insgesamt beseitigt die Abschaffung von Proof of History die Abhängigkeit vom kontinuierlichen Berechnen von Hashes und damit alle Angriffsvektoren, die auf dem Anhalten dieses Prozesses beruhen. Wie oben erwähnt, verschieben sich dadurch auch die Garantien für die Lebendigkeit. Die Abschaffung von Proof of History schwächt die Sicherheit jedoch in keiner wesentlichen Weise.

Wichtigste Erkenntnisse

Alpenglow tauscht eine geringfügig niedrigere byzantinische Fehlertoleranz gegen deterministische Finalität in weniger als einer Sekunde, den robusten Umgang mit großen gutartigen Ausfällen und die einfachere Erkennung böswilliger Validatoren. Die wichtigsten Erkenntnisse lassen sich wie folgt zusammenfassen:

• Zwei widersprüchliche Blöcke können nur finalisiert werden, wenn ≥20 % des Stakes doppelt signieren. Das lässt sich zweifelsfrei beweisen und bestrafen.
• Solana finalisiert weiterhin Blöcke, solange ≥60 % des Stakes kommunizieren können, selbst wenn der restliche Stake offline ist.
• Im schlechtesten Fall wechselt die Finalisierung zur zweiten Abstimmungsrunde mit einer Ziellatenz von ~150 ms. Angriffe verlangsamen damit die Chain, bevor sie deren Sicherheit gefährden.
• Die Kosten für das Überschreiten der byzantinischen Grenze von 20 % sind prohibitiv. Kleinere Verstöße lassen sich erkennen und sozial sowie wirtschaftlich bestrafen, sobald Slashing im Mainnet aktiv ist.

Wie wirkt sich Alpenglow auf Validatoren aus?

Die Kosten für Abstimmungen sind die größte Einstiegshürde für den Betrieb eines Solana-Validators. Für den Betrieb eines Validators ist keine strikte Mindestmenge an SOL erforderlich. Das Senden von Vote-Transaktionen in jedem Slot, das für die Teilnahme am Consensus notwendig ist, kann jedoch bis zu ~1 SOL pro Tag kosten.

Alpenglow soll Vote-Transaktionen pro Slot durch ein kompaktes Zertifikatsystem ersetzen, das die heutigen Abstimmungsgebühren praktisch abschafft. Jeder Validator sendet leichtgewichtige Vote-Nachrichten an alle anderen Nodes. Sobald ein Quorum erreicht ist, kann jeder Node diese Signaturen mithilfe des BLS-Signaturschemas zu einem Zertifikat aggregieren. Da die Votes nun per BLS aggregiert sind, wird nur der Zertifikat-Header onchain verankert. In der Praxis würden damit die täglichen Kosten von ~1 SOL pro Validator entfallen. 

Wie bereits erwähnt, wird mit Alpenglow jeder Blockvorschlag über zwei parallele Abstimmungspfade bewertet:

• Fast-Finalization (eine Runde)
  • Wird ausgelöst, wenn die Zahl notariell bestätigter Votes für einen bestimmten Block in der ersten Abstimmungsrunde ≥80 % des Stakes erreicht
  • Erzeugt ein Fast-Finalization-Zertifikat 
  • Hat eine Ziellatenz von ~100 ms
• Slow-Finalization (zwei Runden)
  • Wird ausgelöst, wenn die Zahl notariell bestätigter Votes für einen bestimmten Block in der ersten Abstimmungsrunde ≥60 % des Stakes erreicht
  • Erzeugt ein Finalisierungszertifikat, nachdem die Zahl notariell bestätigter Votes in der zweiten Runde ≥60 % des Stakes erreicht
  • Hat eine Ziellatenz von ~150 ms

Votor führt beide Pfade parallel aus. Beide Zähler werden aus demselben Stream der Votes aus der ersten Runde aktualisiert. Das erste Zertifikat, das seinen Schwellenwert überschreitet, finalisiert den Block. Die sich überschneidende Stake-Menge von ≥60 % stellt sicher, dass zwei widersprüchliche Blöcke niemals beide Finalität erreichen können.

Die betrieblichen Auswirkungen dieses neuen Designs sind für Validatoren positiv:

Niedrigere Betriebskosten 

Die Abschaffung der Abstimmungsgebühren senkt die Einstiegshürde für potenzielle Validatoren erheblich. Gleichzeitig machten diese Gebühren kleinere Validatoren in Bärenmärkten stärker von Inflationsbelohnungen abhängig. Ihre Abschaffung könnte angesichts der umstrittenen Abstimmung zu SIMD-228 künftige Diskussionen über die Inflation von Solana rechtfertigen, siehe SIMD-228. In der derzeit diskutierten Implementierung von Alpenglow würde eine solche Senkung die für einen profitablen Betrieb erforderliche Mindestmenge an SOL von ~4850 SOL (~800.000 USD) auf ~450 SOL (~75.000 USD) reduzieren. Dies wurde mit dem Validator Profit Calculator von Cogent Crypto berechnet.

Vereinfachte Schlüsselverwaltung 

Solana-Validatoren müssen nicht mehr in jedem Slot Votes signieren. Der Identitätsschlüssel des Validators kann dadurch ohne Performance-Risiken in einem Hardware Security Module (HSM) gespeichert werden, was das Hot-Wallet-Risiko effektiv senkt.

Geringere Netzwerklast in Leader-Slots

Ein aggregiertes Zertifikat pro Block ersetzt Tausende einzelner Vote-Transaktionen pro Epoche und reduziert dadurch die Netzwerklast in Leader-Slots. 

Keine Lock-out-Berechnungen

Die exponentielle Lock-out-Tabelle im Tower-Stil von Solana entfällt. Validatoren müssen nur noch die neueste Zertifikatskette im Arbeitsspeicher verfolgen, was Neustarts beschleunigt.

Wie wirkt sich Alpenglow auf RPC-Anbieter aus?

Die betrieblichen Auswirkungen dieses neuen Designs sind für RPC-Anbieter überwiegend positiv. Einige könnten jedoch die Skalierbarkeit beeinträchtigen:

Vereinfachte Commitment-Level 

Dieses neue Finalitätsniveau würde die bisherige Lücke zwischen den Commitment-Levels confirmed (also optimistisch) und finalized (also verwurzelt) schließen. Weitere Informationen findest du unter Commitment-Level. UX-Logik, die beispielsweise auf zwei Bestätigungsstufen wartet und bis zur Finalisierung einen Spinner anzeigt, lässt sich auf eine einzelne Zertifikatsprüfung reduzieren.

Kleinere Ledger-Größe

Bei der aktuellen Nachfrage nach Solana würde das Ledger aufgrund der entfallenden Vote-Transaktionen rund drei Viertel langsamer wachsen. Dadurch würden auch Snapshots und Archive kleiner. Wie sich dies in der Praxis auswirkt, ist angesichts der prognostizierten Ziele für höhere CU-Blocklimits jedoch noch offen.

Engpass beim WebSocket-Fan-out

Mit Alpenglow ist das Polling von Transaktionen nicht mehr sinnvoll, da die Finalität nach ~100–150 ms eintritt und in einem einzigen Zertifikat codiert ist. Sinnvoller wäre es, Finalitätsinformationen über einen Push-Kanal zu beziehen, der während der gesamten Laufzeit der App, des Browsers oder des Bots geöffnet bleibt und jedes neue Zertifikat an alle abonnierten Clients sendet. Die Engpässe verlagern sich dadurch von Millionen kleiner HTTP-Abfragen auf Hunderttausende Echtzeit-Sockets.

Aktualität von Echtzeit-Caches

Jeder Cache, der Account-Daten länger als eine Viertelsekunde vorhält, könnte veraltete Daten ausliefern, da Zertifikate einen Block innerhalb von 100–150 ms bestätigen. Edge-Caches, CDNs und Layer-7-Proxys benötigen extrem kurze TTLs oder zertifikatsbasierte Purge-Hooks.

Wie sieht der Entwicklungszeitplan von Alpenglow aus?

Alpenglow wurde Ende Mai auf der Accelerate-Konferenz in New York offiziell vorgestellt. In der nächsten Phase wird ein formelles Solana Improvement Document (SIMD) veröffentlicht. Dadurch kann die Community über GitHub, die Solana-Governance-Foren und den Solana Tech Discord Feedback zum Vorschlag geben.

Nach der Prüfungsphase durch die Community folgt eine Onchain-Governance-Abstimmung der Validator-Community. Parallel dazu wird das neue Design umfassend getestet, um Performance und Sicherheit zu gewährleisten.

Wenn alle Phasen planmäßig verlaufen, wird die Bereitstellung im Solana-Mainnet bis Anfang nächsten Jahres erwartet.

Risiken und offene Fragen zu Alpenglow

Ein neuer Consensus-Algorithmus

Der Wechsel zu einem neuen Consensus-Protokoll ist ein bedeutendes Vorhaben, es gibt jedoch relevante Präzedenzfälle. Der Merge von Ethereum im Jahr 2022 zeigte, dass ein großes aktives Netzwerk seinen zentralen Consensus-Mechanismus erfolgreich von Proof-of-Work auf Proof-of-Stake umstellen kann, ohne den Betrieb zu unterbrechen. Es bestehen weiterhin zahlreiche Risiken, aber das Vorhaben betritt kein vollständiges Neuland.

Ein solcher Übergang erfordert außerdem Migrationsleitfäden, damit Apps, SDKs, Wallets und Bots nicht unbemerkt ausfallen, wenn Alpenglow die Commitment-Level confirmed und finalized in einer einzigen Zertifikatsprüfung zusammenführt. Code, der ausdrücklich zwei Commitment-Level abfragt oder standardmäßig das Commitment-Level confirmed nutzt, funktioniert dann nicht mehr. Bevor Alpenglow live geht, muss das Ökosystem Dokumentation, Lint-Warnungen, RPC-Methoden und die allgemeine Codearchitektur koordiniert anpassen. 

Governance

Auch das Governance-Risiko muss berücksichtigt werden. Die jüngste Abstimmung zu SIMD-228 zeigt, dass Solana als wirklich dezentrales Netzwerk funktioniert. Selbst Vorschläge, die von Core-Entwicklern und prominenten Mitgliedern der Community unterstützt werden, werden nicht zwangsläufig angenommen. Die mit Alpenglow eingeführten Änderungen, insbesondere die niedrigeren Abstimmungskosten, sind für Validatoren und speziell für kleinere Betreiber jedoch weitgehend vorteilhaft. Daher halten wir erheblichen Widerstand in der Governance für relativ unwahrscheinlich.

Belohnungen

Das Alpenglow-Whitepaper und die bisher veröffentlichten Begleitmaterialien nennen keine genauen Mechanismen, um die Abstimmungsaktivität von Validatoren zu belohnen oder Rotor-Relays für ihre Bandbreitennutzung zu vergüten. Das Whitepaper stellt außerdem klar, dass Equivocation bestraft werden kann. Es bleibt jedoch offen, wer die Strafe tatsächlich einreicht, wie hoch sie ausfällt und ob sie automatisch oder durch die Governance verhängt wird. Diese Lücken lassen wichtige Aspekte der Validator-Ökonomie ungeklärt und könnten im Ökosystem kontroverse Debatten auslösen.

MEV

Alpenglow wird auch die aktuelle MEV-Landschaft auf Solana grundlegend umstrukturieren. Die Latenz bleibt ein entscheidender Faktor für MEV, da einige profitable Strategien TPU-Traffic spiegeln oder Transaktionen per Spam stornieren und in einer bestimmten Reihenfolge ersetzen, bevor sie optimistisch bestätigt werden. All dies geschieht im aktuellen Zeitfenster von ~500–600 ms, das Alpenglow auf ~150 ms verkürzen soll. Auf den ersten Blick könnten Leader, insbesondere Validatoren mit eigener angepasster Infrastruktur für den Blockaufbau, einen größeren Anteil des MEV abschöpfen. Unabhängige Latenz-Arbitrageure könnten ihren Vorteil verlieren, sofern sie nicht noch schnellere und granularere Handelssysteme entwickeln.

Mehrere parallele Leader

Das Design von Alpenglow lässt sich deutlich flexibler an ein Multi-Leader-Framework anpassen, das als Multiple Concurrent Leaders (MCL) bekannt ist, als die aktuelle Consensus-Architektur von Solana. Wie Anatoly Yakovenko anmerkte, könnte ein erster MCL-Prototyp zwei Alpenglow-Instanzen starten, die dasselbe Rotor-Set verwenden und alle Shreds gleichzeitig freigeben. Rotor würde die parallelen Streams verteilen, während Votor jede Lane notariell bestätigt. Dabei ergeben sich jedoch mehrere Fragen zur Ausführungsschicht. Konkret:

• Wie sollten Write-Sets partitioniert werden, damit die Blöcke zweier Leader niemals denselben Account sperren – oder damit sich solche Konflikte deterministisch und kostengünstig lösen lassen?
• Wie führen wir die Zertifikate der einzelnen Lanes zu einer kanonischen State Root zusammen, ohne die Replay-Kosten zu verdoppeln?
• Welche Logik für den Gebührenmarkt gilt, wenn Lanes um Assets konkurrieren?
• Welche laneübergreifenden MEV-Strategien würde dies ermöglichen?
• Könnte ein einzelner Validator mit hohem Stake parallele Slots dominieren, wenn es keine Lane-Limits gibt? 

Das Design von Alpenglow beseitigt Hindernisse auf Consensus-Ebene und macht MCL damit zu einem realistischen Punkt auf der Roadmap. Bis diese offenen Fragen beantwortet sind, bleibt es jedoch ein vielversprechendes Vorhaben für die Zukunft.

Fazit

Dieser Bericht hat die Kernkomponenten von Alpenglow untersucht und gezeigt, wie sie das Consensus-Modell von Solana verändern. Außerdem haben wir die technischen Verbesserungen, die Veränderungen der Validator-Ökonomie, die Auswirkungen auf Netzwerkebene sowie die Vorteile für Performance, Einfachheit und Skalierbarkeit analysiert.

Das Alpenglow-Whitepaper markiert einen Wendepunkt für Solana – nicht nur beim Protokolldesign, sondern auch in der Entwicklungsphilosophie. Erstmals hat Solana formale Korrektheitsbeweise für seinen Consensus-Algorithmus veröffentlicht. Das signalisiert eine Abkehr vom traditionell empirischen, ingenieurgetriebenen Ansatz hin zu einer strengeren, forschungsbasierten Grundlage. Diese Entwicklung zeigt ein reifer werdendes Ökosystem, das Performance weiterhin priorisiert, nun aber zusätzlich auf die Disziplin formaler Verifikation setzt.

Die Abschaffung von Proof-of-History (PoH) steht für einen ähnlich symbolischen Wandel der Netzwerkidentität. Obwohl die praktische Bedeutung von PoH oft überschätzt wurde, galt es lange als die charakteristische Innovation von Solana. Es spielte in technischen Einführungen eine zentrale Rolle und wurde zum Synonym für die Marke. Seine Abschaffung markiert das Ende einer Ära und den Beginn einer neuen. Solana wird erwachsen.

Weitere Ressourcen

• Präsentationsfolien zu Alpenglow von der Accelerate - Roger Wattenhofer
• Alpenglow: Ein neuer Consensus für Solana - Anza-Blog
• Alpenglow-Referenzimplementierung - GitHub
• Alpenglow-Whitepaper - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Consensus auf Solana - Helius-Blog
• Scale or Die auf der Accelerate 2025: Vorstellung von Alpenglow – dem neuen Consensus von Solana - YouTube-Video