SOLANA·HUB
EN

Alpenglow: Solanas neuer Konsens-Mechanismus erklärt

Anza ersetzt TowerBFT und Proof-of-History durch Alpenglow. Was Votor und Rotor sind, wie die Block-Finalität von 12,8 Sekunden auf 150 Millisekunden fällt, und was Constellation als ergänzender Vorschlag mitbringt.

SOLANA·HUB ·

Solana bekommt das größte Upgrade seiner Geschichte — und es betrifft die Frage, wie sich tausende Rechner in Sekunden einigen, was gerade passiert ist.

In einfachen Worten: Stell dir vor, dein Verein soll nach einem Spiel in 5 Minuten beschließen, ob das letzte Tor zählt. Bisher mussten alle 1000 Mitglieder nacheinander zustimmen — das dauerte fast 13 Sekunden. Mit Alpenglow stimmen alle gleichzeitig ab: sobald 80 % die Hand heben, ist der Beschluss gültig — nach 150 Millisekunden, einer Zeitspanne, die kürzer ist als ein Augenzwinkern. Und selbst wenn 40 % der Mitglieder gerade nicht erreichbar sind, hört der Verein nicht auf zu arbeiten — solange nicht mehr als 20 % aktiv sabotieren. Alpenglow bringt Solana näher an die physikalische Grenze dessen, was Lichtgeschwindigkeit im Netzwerk überhaupt zulässt.

Kernidee

Alpenglow ist Solanas neuer Konsens-Mechanismus, veröffentlicht von Anza im Mai 2025. Er ersetzt die bisherigen Kernkomponenten TowerBFT und Proof-of-History durch zwei neue: Votor übernimmt die Abstimmungs- und Finalisierungs-Logik, Rotor übernimmt die Daten-Verteilung. Block-Finalität fällt laut Simulation von rund 12,8 Sekunden auf etwa 150 Millisekunden. Das Netzwerk bleibt funktionsfähig, solange nicht mehr als 20 Prozent feindlich und 20 Prozent unresponsiv sind (“20+20”-Resilienz). Ergänzend hat Helius-Research mit Constellation einen separaten Vorschlag für die Block-Konstruktion vorgelegt — die beiden Ansätze adressieren unterschiedliche Schichten und können koexistieren.

Worum es geht

Solanas Kern-Protokoll bekommt seine größte Überarbeitung seit dem Mainnet-Launch 2020. Anza, einer der zwei großen Validator-Client-Entwickler, hat im Mai 2025 das Whitepaper zu Alpenglow veröffentlicht — einem komplett neuen Konsens-Mechanismus, der TowerBFT und Proof-of-History ablöst. Parallel hat das Helius-Research-Team mit Constellation einen ergänzenden Vorschlag für die Block-Konstruktion vorgelegt.

Dieser Artikel erklärt, was Alpenglow ist, welche Komponenten es ersetzt, wie Votor und Rotor zusammenarbeiten, und welche Rolle Constellation in der weiteren Evolution spielen könnte.

Keine Finanzberatung. Dieser Artikel beschreibt technische Protokoll-Änderungen.

Was Alpenglow ersetzt

Bis zu Alpenglow basiert Solanas Konsens auf zwei Säulen:

TowerBFT ist die Voting- und Block-Finalisierungs-Logik. Validators stimmen über jeden Slot ab; ein Block gilt erst nach einer bestimmten Anzahl bestätigter Votes als final. TowerBFT funktioniert, ist aber latenzschwer: bis zur echten Finalität vergehen laut Anza im Schnitt 12,8 Sekunden.

Proof-of-History (PoH) ist Solanas verifizierbare Zeitstempel-Schicht. PoH erzeugt eine kontinuierliche Hash-Kette, die als kryptographische Uhr funktioniert. Validators können damit ohne zusätzliche Kommunikations-Runden über die Reihenfolge von Events übereinkommen. PoH war historisch ein zentraler Performance-Hebel für Solana, kostet aber Compute auf jedem Validator.

Beide Komponenten verschwinden mit Alpenglow. Anza beschreibt das in ihrem Blog-Post zum Alpenglow-Whitepaper: “When moving to Alpenglow, we say goodbye to a number of legacy components of the core protocol, in particular, TowerBFT and Proof-of-History.”

An ihre Stelle treten zwei neue Komponenten.

Votor: die neue Voting-Schicht

Votor (der neue Abstimmungs-Pfad) ersetzt TowerBFT und übernimmt das Sammeln von Validator-Votes und die Finalisierung von Blocks.

Die zentrale Innovation: Votor hat zwei integrierte Voting-Modi, die parallel laufen.

  • Schneller Modus (1 Runde): wenn mindestens 80 Prozent des Stakes aktiv teilnehmen, finalisiert Votor einen Block in einer einzigen Voting-Runde.
  • Fallback-Modus (2 Runden): wenn nur 60 Prozent des Stakes reagieren, läuft Votor über zwei Voting-Runden.

Beide Modi arbeiten gleichzeitig. Der jeweils erste, der sein Quorum erreicht, gewinnt — die Finalisierung passiert also so schnell wie möglich, ohne dass das Netzwerk im Voraus entscheiden muss, welcher Modus aktiv ist.

Anstelle des bisherigen Gossip-Protokolls für die Vote-Verbreitung nutzt Alpenglow eine direktere Kommunikations-Primitive. Das senkt die Anzahl der Netzwerk-Hops und damit die Gesamtlatenz.

Rotor: die neue Daten-Verteilung

Rotor (die neue Daten-Verteilungs-Schicht) ist die Evolution von Turbine (bisheriger Block-Verteilungs-Mechanismus), Solanas bisheriger Daten-Dissemination-Schicht.

Turbine zerlegt jeden Block in viele kleine Erasure-Code-Fragmente (fehlerkorrigierende Datenstücke) und verteilt sie über einen Baum aus Relay-Nodes an alle Validators. Jeder Knoten bringt seine Bandbreite proportional zum Stake ein. Diese Architektur hat Solana von Anfang an erlaubt, große Blocks ohne Leader-Bottleneck zu produzieren.

Rotor behält dieses Grundprinzip — Erasure-Codes plus stake-proportionale Bandbreite — und verkürzt die Topologie. Statt eines mehrschichtigen Relay-Baums nutzt Rotor eine einzelne Relay-Layer. Damit sinkt die Anzahl der Netzwerk-Hops, und Anza nennt zusätzlich eine neue Auswahllogik für die Relay-Knoten, die laut Whitepaper die Resilienz unter unzuverlässigen Netzwerk-Bedingungen verbessert.

Die Latenz-Zahlen

Anza hat im Whitepaper Latenz-Simulationen veröffentlicht. Die Eckpunkte:

PhaseTowerBFT (bisher)Alpenglow (neu)
Block-Finalität (median)~12,8 Sekunden~150 Millisekunden
Best-Case-Finalität(nicht relevant)~100 Millisekunden
Voting-Rundenviele, sequenziell1 (schneller Pfad) oder 2 (Fallback)
Daten-VerteilungTurbine (Multi-Hop-Tree)Rotor (Single-Hop-Relay)

Die Simulationen wurden laut Anza mit der aktuellen Mainnet-Stake-Verteilung gerechnet und ohne zusätzlichen Berechnungsaufwand. Ein zentraler Befund: die natürliche untere Schranke jeder Finalisierungs-Latenz ist die geographische Netzwerk-Latenz selbst. Wenn ein Knoten 100 Millisekunden von der Region des Leaders entfernt ist, kann kein Konsens-Protokoll dort schneller als 100 Millisekunden finalisieren.

Alpenglow ist also nicht “magisch schnell” — es kommt näher an die physikalische Untergrenze des Netzwerks, statt zusätzliche Protokoll-Latenz draufzulegen.

Die “20+20”-Resilienz

Klassische Byzantine-Fault-Tolerance-Protokolle (Protokolle, die mit absichtlich bösen Teilnehmern umgehen) vertragen typischerweise bis zu einem Drittel feindlichen Stake. Alpenglow definiert eine differenziertere Schwelle:

  • bis zu 20 Prozent feindlicher Stake (Validators, die aktiv Fehlverhalten zeigen)
  • plus bis zu 20 Prozent nicht-reagierender Stake (Validators, die offline oder verzögert sind, ohne aktiv anzugreifen)

Diese Trennung ist relevant, weil in der Realität die häufigste Form von Stake-Verlust temporäre Nicht-Erreichbarkeit ist, nicht aktive Angriffe. Alpenglow kann also Block-Produktion aufrechterhalten, auch wenn 40 Prozent des Netzwerks aus unterschiedlichen Gründen ausfällt — solange der Anteil aktiv feindlich nicht über 20 Prozent steigt.

Constellation: ergänzender Vorschlag von Helius-Research

Während Alpenglow den Konsens-Layer betrifft, adressiert Constellation eine andere Schicht: die Block-Konstruktion.

Helius-Research beschreibt Constellation in einem ausführlichen Forschungs-Post als das erste formelle Protokoll-Vorschlag für Multiple Concurrent Proposers (MCP) auf einer Production-Blockchain.

Das Modell: statt eines einzelnen Leaders, der allein entscheidet welche Transaktionen in einen Block kommen, arbeiten rund 16 Proposer parallel in einem 50-Millisekunden-Zyklus. Diese Proposer setzen Transaktionen zu Erasure-Code-Stücken (“pslices”) zusammen und verteilen sie an etwa 256 Attester. Die Attester unterschreiben kryptographisch, welche Transaktions-Sets sie gesehen haben.

Die Eigenschaft die Constellation dabei verspricht: selektive Zensur-Resistenz (kein Proposer kann einzelne Transaktionen heimlich aussperren). Entweder werden alle gebühren-konkurrenzfähigen Transaktionen eines Zyklus inkludiert, oder keine. Ein Leader kann nicht selektiv einzelne Transaktionen ausschließen, ohne einen für das Netzwerk ungültigen Block zu produzieren.

Helius weist im Post explizit auf offene Probleme hin. Zwei davon sind besonders relevant:

  • Content-visible Ordering bleibt ungelöst. Transaktionen sind für alle Proposer beim Empfang sichtbar — die Multi-Proposer-Architektur erweitert die Angriffsfläche hier möglicherweise sogar.
  • Zeit-basierte Latenz-Spiele werden im aktuellen Design als nicht strafbar bezeichnet.

Constellation ist ein Vorschlag, kein finalisiertes Protokoll. Anza und die Solana-Foundation haben noch keine offizielle Adoption signalisiert.

Wie Alpenglow und Constellation zusammenpassen

Beide Vorschläge adressieren unterschiedliche Layer des Solana-Stacks:

  • Alpenglow ändert, wie Validators sich auf finalisierte Blocks einigen (Konsens-Layer).
  • Constellation ändert, wer die Blocks initial zusammenbaut (Block-Construction-Layer).

Technisch könnten sie koexistieren. Alpenglow finalisiert Blocks, unabhängig davon ob sie von einem einzelnen Leader oder mehreren konkurrierenden Proposern stammen. Aktuell ist Alpenglow konkret in der Whitepaper-zu-Implementation-Phase. Constellation ist Research-Stage.

Stand der Implementation

Anza hat das Alpenglow-Whitepaper in zwei Versionen veröffentlicht:

Die Mainnet-Migration ist ein mehrstufiger Prozess. Eine konkrete öffentliche Zeitachse für die vollständige Aktivierung auf Mainnet hat Anza im Blog-Post nicht angegeben. Beobachter verfolgen Roll-Out-Schritte typischerweise über Validator-Client-Releases (Agave, Firedancer) und SIMD-Dokumente.

Constellation befindet sich im Research-Stadium. Helius-Research weist darauf hin, dass weitere Iterationen und ein formales SIMD-Verfahren notwendig wären, bevor eine Implementation anstehen würde.

Was sich für unterschiedliche Rollen ändert

Reines Reporting der dokumentierten Effekte aus dem Whitepaper und dem Helius-Post:

Validators: veränderte Software-Anforderungen für Votor (neuer Voting-Pfad) und Rotor (neue Relay-Auswahl). Die “20+20”-Resilienz erlaubt höhere Toleranz gegenüber zeitweisen Ausfällen. Constellation würde, falls implementiert, neue Rollen (Proposer, Attester) zusätzlich zur Validator-Rolle einführen.

Anwendungs-Entwickler: sub-second Finalität verändert die User-Experience-Erwartungen für DeFi, Trading, Games und Real-Time-Anwendungen. Was bisher mit “optimistic confirmation” gearbeitet hat, kann künftig auf echte Finalität warten, ohne dass das User-Experience-Probleme auslöst.

Endnutzer und Wallet-Betreiber: keine direkten Aktionen erforderlich. Die Änderungen passieren auf Konsens-Ebene und sind für Wallets und Endnutzer transparent.

Was das für dich heißt

Alpenglow ist noch nicht auf Mainnet aktiv — es befindet sich im Übergang von Whitepaper zu Implementation. Wenn es kommt, ändert sich für Endnutzer und Wallet-Inhaber nichts Sichtbares: keine Migration, keine neue Adresse, kein manueller Schritt. Die Verbesserung passiert unter der Haube. Relevant ist Alpenglow vor allem für alle, die Solana als Plattform beobachten: Sub-Sekunden-Finalität verändert, was auf Solana technisch möglich wird — schnellere DeFi-Abschlüsse, Echtzeit-Anwendungen, geringere Abhängigkeit von optimistischen Bestätigungen. Ob und wann Alpenglow aktiviert wird, lässt sich über Validator-Client-Releases und SIMD-Dokumente nachverfolgen.

Selbst sicher umsetzen? Dieser Artikel erklärt das Konzept. Den geordneten Schritt-für-Schritt-Weg — Wallet, Sicherheit, Staking, DeFi, DACH-Steuern — gibt dir der Solana-Guide.

Quellen

Verwandte SolanaHub-Inhalte:

Verwandte Glossar-Begriffe:

#solana #alpenglow #consensus #votor #rotor #anza #firedancer #performance