Solana-Entwickler starten Governance-Votum für „Alpenglow“-Upgrade
Die Kernentwickler von Solana haben einen Vorschlag mit weitreichenden Folgen in den Governance-Prozess eingebracht: SIMD-0326 „Alpenglow“ soll die bestehenden Konsensmechanismen – Proof-of-History (PoH) und TowerBFT – vollständig ablösen. Hinter dem Vorschlag stehen Quentin Kniep, Kobi Sliwinski und Roger Wattenhofer, die das Upgrade als „grundlegende Überarbeitung des Solana-Konsensprotokolls“ beschreiben. Das Ziel: Blockfinalität innerhalb von nur 100 bis 150 Millisekunden.
Kern des neuen Ansatzes ist Votor, ein leader-pipelined Finality-Protokoll, das klassische On-Chain-Votetransaktionen und bandbreitenintensives Gossiping durch Off-Chain-Vote-Exchange mit lokaler Signaturaggregation ersetzt. Validatoren geben dabei direkte Voten für oder gegen Blöcke ab, die acht Slots später von den Leadern aggregiert und als kompakte Beweise eingereicht werden. Nach Ansicht der Autoren reduziert dies nicht nur massiv die Latenz, sondern steigert zugleich die Ausfallsicherheit: Alpenglow soll bis zu 20 % feindliche und 20 % unresponsive Validatoren tolerieren, ohne dass das Netzwerk stehen bleibt.
Neuer Anreiz- und Gebührenmechanismus
Mit Alpenglow würde sich auch die ökonomische Grundlage für Validatoren ändern. Da die klassischen On-Chain-Votes wegfallen, führt das SIMD einen Validator Admission Ticket (VAT) ein – eine fixe, pro Epoche zu zahlende Gebühr von zunächst 1,6 SOL, die verbrannt wird. Diese Kosten sollen vergleichbar mit den heutigen Vote-Fees sein und stellen weiterhin eine ökonomische Eintrittsbarriere dar.
Darüber hinaus schreibt der Vorschlag vor, dass Validatoren genau ein gültiges Vote pro Slot abgeben müssen. Fehlverhalten wie widersprüchliche Votes lässt sich nachweisen und sanktionieren; wer wiederholt nicht teilnimmt, verliert nicht nur Rewards, sondern kann auch aus dem aktiven Set entfernt werden.
Leader wiederum erhalten die aggregierten Vote-Rewards der von ihnen eingesammelten Stimmen sowie einen Bonus, wenn sie Finalitätszertifikate einbauen. Damit verschiebt sich die Vergütung hin zu einem stärker leistungsabhängigen Modell, das auf niedrige Latenzen und hohe Zuverlässigkeit ausgelegt ist.
Governance-Prozess und offene Fragen
Das Governance-Verfahren ist dreistufig angelegt: zunächst Diskussionen bis Epoche 838, dann eine stake-weight-Erfassung in Epoche 839, gefolgt von einem bindenden Votum zwischen Epoche 840 und 842. Die Abstimmung erfolgt über claimbare Vote-Tokens, die Validatoren auf „Yes“, „No“ oder „Abstain“ übertragen. Entscheidend ist eine Zweidrittel-Mehrheit der abgegebenen Ja- und Nein-Stimmen bei einem Quorum von 33 %, wobei Enthaltungen zum Quorum beitragen, nicht aber zur Supermajorität.
Während die Aussicht auf Finalität im Sub-Sekunden-Bereich beeindruckend wirkt und Solana näher an Web2-Standards bringen könnte, äußern viele Validatoren Bedenken. Diskutiert werden vor allem Rollout-Sicherheit, Testpläne, Fallback-Strategien sowie Detailfragen zur Handhabung von MEV, zur Nutzererfahrung bei Blockteilen, die verworfen werden, und zur Höhe des VAT. Auch die Auswirkungen auf Transaktionsexpiry und Leader-Equivocation werden kritisch hinterfragt.
Das Votum dürfte damit weniger an der Performance-Headline hängen, sondern vielmehr an der Frage, wie belastbar die Sicherheitsbeweise, ökonomischen Anreize und Migrationspfade ausgestaltet sind. Sollte „Alpenglow“ angenommen werden, würde es nicht nur den technischen Kern von Solana neu definieren, sondern auch einen der tiefgreifendsten Konsens-Wechsel in einer großen Blockchain markieren.