Agave-4.3-Update: Alles, was du wissen musst

Einführung

Mit Agave 4.3 bereitet sich Solana auf das wohl größte Protokoll-Upgrade seiner Geschichte vor. Der Release-Zyklus von 4.3 führt Alpenglow ein, Solanas mit Spannung erwarteten neuen Konsensmechanismus. Den Abschluss bildet „Alpenswitch“: der koordinierte Übergang des Mainnets weg von TowerBFT.

Seit dem Start basiert Solanas Konsensarchitektur auf Proof of History und TowerBFT. Validatoren stimmen ab, indem sie Transaktionen einreichen, die zusammen mit normalen Benutzertransaktionen verarbeitet und in Blöcke aufgenommen werden. Finalität entsteht, wenn sich diese Stimmen über 32 Slots ansammeln. Dadurch erreicht Solana bei einer Slot-Dauer von 400 Millisekunden eine Finalität von ungefähr 12,8 Sekunden.

Proof of History (PoH) war beim Start eine von Solanas prägenden Architekturinnovationen. Der einzigartige Ansatz ordnete Ereignisse und koordinierte die Zeit. Dass PoH nun ausläuft, markiert deshalb das Ende einer Ära. Zugleich zeigt es, wie weit sich das Protokoll von den Technologien entfernt hat, die es ursprünglich auszeichneten.

Alpenglow ersetzt „PoH + TowerBFT“ durch Votor. In diesem Protokoll tauschen Validatoren ihre Stimmen außerhalb der zentralen Transaktionspipeline aus. Votor bündelt diese Stimmen in kryptografischen Zertifikaten. Das Ziel ist eine Finalität von etwa 150 Millisekunden.

Für Benutzer und Anwendungen, die Transaktionen einreichen und den Zustand von Accounts lesen, gibt es wenig oder gar nichts zu migrieren. Transaktionen und Gebührenmechanismen bleiben unverändert. Die größten Anpassungen betreffen Validatoren und Infrastruktur, die Blöcke, Stimmen, Streams oder Commitment-Daten verarbeiten.

Stimmtransaktionen verschwinden aus Blöcken, confirmed und finalized laufen praktisch zusammen und Streaming-Infrastruktur erhält neue Informationen, um konkurrierende Banks innerhalb desselben Slots zu unterscheiden.

In diesem Artikel sehen wir uns an, wie Alpenglow funktioniert und was Votor an Blockproduktion und Finalität ändert. Außerdem behandeln wir weitere wichtige Änderungen, die im Release-Zyklus von Agave 4.3 erscheinen.

Schrittweise Einführung: zuerst Votor, dann Rotor

Alpenglow basiert auf zwei Hauptkomponenten: Votor ersetzt Solanas Abstimmungs- und Finalitätsmechanismus, während Rotor neu gestaltet, wie sich Blöcke im Netzwerk verbreiten. Beide Mechanismen werden schrittweise eingeführt. Votor kommt zuerst.

Agave 4.3 führt Votor ein, behält aber das bestehende Protokoll zur Blockverbreitung Turbine bei. Rotor wurde ausdrücklich aus SIMD-0326 ausgeschlossen, dem Vorschlag für die erste Aktivierung von Alpenglow. Vor der Bereitstellung benötigt Rotor ein eigenes SIMD. Die erste Einführung ändert, wie Validatoren einen Konsens erreichen, aber noch nicht, wie sich Blockdaten im Netzwerk bewegen.

Votor

Votor ersetzt die Stimmtransaktionen und das Lockout-System von TowerBFT durch ein direkteres Protokoll zwischen Validatoren. Bei TowerBFT stimmen Validatoren über Transaktionen ab, die in Blöcke aufgenommen werden. Nach und nach entsteht genug Lockout-Tiefe, damit ein Block final wird. Bei Votor tauschen Validatoren stattdessen direkt signierte Stimmnachrichten aus. Das Protokoll bündelt diese Signaturen in kompakten Zertifikaten.

Statt darauf zu warten, dass sich Stimmen über 32 Slots ansammeln, kann Votor einen Block nach einer oder zwei Abstimmungsrunden finalisieren. Das Protokoll zielt auf etwa 150 Millisekunden Finalität, verglichen mit ungefähr 12,8 Sekunden bei TowerBFT.

Votor hat zwei gleichzeitig aktive Wege zur Finalität.

Beglaubigen in der ersten Runde mindestens 80 % des Stakes einen Block, lassen sich diese Stimmen zu einem Fast-Finalization Certificate bündeln und der Block ist sofort final. Dies ist der schnelle Pfad des Protokolls und benötigt nur eine Abstimmungsrunde.

Wird der Schwellenwert von 80 % nicht erreicht, kann ein Block dennoch fortschreiten, wenn mehr als 60 % des Stakes für seine Beglaubigung gestimmt haben. Dadurch entsteht ein Notarization Certificate, das eine zweite Abstimmungsrunde ermöglicht. Sobald mehr als 60 % des Stakes über den zweistufigen Pfad Finalisierungsstimmen abgeben, entsteht ein Finalization Certificate und der Block wird final.

Das vollständige Protokoll kennt daher fünf Stimmtypen: Notarization, Notarization Fallback, Skip, Skip Fallback und Final. Verschiedene Kombinationen dieser Stimmen erzeugen Beglaubigungs-, Fallback-, Skip- oder Finalisierungszertifikate. Diese Zertifikate dienen als kompakter kryptografischer Nachweis, dass genug Stake dem Ergebnis eines Slots zugestimmt hat.

Votor kann bereits mit 60 % reaktionsfähigem, ehrlichem Stake weiterarbeiten. Bis zu 20 % des Stakes dürfen sich dabei böswillig verhalten, während weitere 20 % offline sind oder nicht reagieren. Dieser Kompromiss ist beabsichtigt: Alpenglow verzichtet auf den traditionellen byzantinischen Schwellenwert von einem Drittel aus BFT-Designs. Dafür bietet es ein 20+20-Resilienzmodell, das ausgefallene oder nicht verfügbare Validatoren besser toleriert.

Votor verwendet Proof of History außerdem nicht mehr als Konsensuhr. Validatoren nutzen stattdessen lokale Timeout-Timer. Hat ein Validator lange genug gewartet, ohne einen akzeptablen Block zu erhalten, kann er eine Skip-Stimme abgeben und den Konsens fortsetzen lassen. Im Vergleich zu TowerBFT vereinfacht dies die Beziehung zwischen Zeitmessung und Konsens.

Rotor

Rotor ist nicht Teil von Agave 4.3. Derzeit gibt es kein veröffentlichtes Aktivierungsdatum. Deshalb transportiert Turbine weiterhin Blockdaten, wenn Votor aktiviert wird. Rotor und der Smart-Sampling-Mechanismus zur Auswahl seiner Relays durchlaufen später einen separaten Vorschlags- und Einführungsprozess.

Das bedeutet jedoch nicht, dass Solana auf Rotor warten muss, um Finalität in weniger als einer Sekunde zu erreichen. Die aktuelle Einführung von Alpenglow zielt mit Votor in Agave 4.3 auf etwa 150 ms Finalität, während Turbine bestehen bleibt. Rotor soll die Blockverteilung weiter verbessern und die gesamte Alpenglow-Architektur effizienter machen. Für das neue Finalitätsmodell von Votor ist Rotor aber keine Voraussetzung.

Keine Stimmtransaktionen mehr

Eine der sichtbarsten Folgen von Alpenglow ist das Verschwinden von Stimmtransaktionen aus Solana-Blöcken. Validatoren zahlen dafür Transaktionsgebühren. Das Netzwerk benötigt außerdem Bandbreite, Rechenleistung und Ledger-Speicher, um sie zu verarbeiten und zu speichern.

Historisch machten Stimmtransaktionen ungefähr drei Viertel aller Onchain erfassten Transaktionen aus. Mit steigender Blockkapazität ist dieser Anteil gesunken. Stimmtransaktionen sind zwar günstig (5.000 Lamports) und verursachen nur einen kleinen Teil der gesamten Rechenlast (etwa 5 %), erhöhen aber die rohe Transaktionszahl und den Speicherbedarf des Ledgers.

Mit Alpenglow tauschen Validatoren stattdessen BLS-signierte Stimmnachrichten direkt untereinander aus. Agaves ConsensusPool verfolgt die beobachteten Stimmen und bündelt ausreichenden Stake in den Zertifikaten, mit denen Votor den Konsens fortsetzt oder finalisiert.

Nachweise über die Beteiligung von Validatoren verschwinden dadurch nicht aus dem Ledger. Alpenglow-Blöcke erhalten einen neuen Block-Footer mit Konsensinformationen. In der aktuellen Agave-Implementierung kann BlockFooterV1 das neueste Finalisierungszertifikat sowie notar_reward_cert und skip_reward_cert enthalten. Die Belohnungszertifikate umfassen eine aggregierte BLS-Signatur und eine Bitmap, die die abstimmenden Validatoren identifiziert.

Systeme, die derzeit anhand indexierter Transaktionen des Vote Program ermitteln, ob ein Validator abgestimmt hat, müssen stattdessen die Zertifikate und abstimmungsbezogenen Daten von Alpenglow verwenden. Bestehende Transaktionspipelines, die Stimmtransaktionen lediglich herausfiltern, können im Allgemeinen weiterlaufen. Nach Alpenswitch findet der Filter einfach nichts mehr, das er entfernen könnte.

Der Wechsel erzeugt außerdem einen Bruch in Solanas vertrauten TPS-Statistiken. Sobald Alpenglow aktiv ist, sinken rohe TPS-Messwerte, die Stimmtransaktionen enthalten, stark ab – selbst wenn die Benutzeraktivität völlig unverändert bleibt. Für Vergleiche vor und nach Alpenswitch sind deshalb TPS ohne Stimmtransaktionen die aussagekräftige Kennzahl. Ihr Wegfall beseitigt eine langjährige Quelle von Missverständnissen über Solanas tatsächlichen Durchsatz und erleichtert Vergleiche mit anderen Netzwerken.

Das Entfernen von Stimmtransaktionen gibt Benutzern etwas Kapazität zurück. Dieser Effekt sollte jedoch nicht überschätzt werden, da Stimmen nur einen relativ kleinen Teil der Rechenlast des Netzwerks ausmachen.

Commitment-Level

Alpenglow beseitigt außerdem eine langjährige Unterscheidung in Solana: die Lücke zwischen confirmed- und finalized-Commitment.

Heute wählen Anwendungen zwischen drei Commitment-Leveln. processed bietet die aktuellste Ansicht, jedoch keine clusterweite Garantie. confirmed bedeutet, dass eine Supermajorität des Stakes für den Block gestimmt hat. Dieser Zustand wird typischerweise innerhalb von ein oder zwei Slots erreicht. finalized bietet deterministische Finalität. Bei TowerBFT muss der Block dafür jedoch den maximalen Vote-Lockout erreichen. Zwischen Bestätigung und Finalisierung liegen dadurch ungefähr 32 Slots. Im Allgemeinen empfiehlt sich confirmed für latenzkritische RPC-Anfragen und finalized, wenn eine stärkere Garantie nötig ist.

In der Praxis hat sich confirmed als äußerst zuverlässig erwiesen: Noch nie konnte ein optimistisch bestätigter Solana-Block anschließend nicht finalisiert werden. Die Protokollgarantie ist dennoch schwächer. Ein bestätigter Block ist noch nicht deterministisch final. Anwendungen wie Bridges, Börsen und Abwicklungssysteme, die dieses verbleibende Restrisiko nicht tolerieren können, mussten deshalb bisher auf finalized warten.

Alpenglow beseitigt diesen Kompromiss. Sobald Votor ein Schnellfinalisierungs- oder Finalisierungszertifikat erzeugt, ist der Block final. Wählt Votor eine finalisierte Bank als Root aus, aktualisiert der Validator gleichzeitig seinen höchsten bestätigten Slot, Root und höchsten Supermajority-Root.

Für Entwickler bedeutet das: confirmed und finalized verweisen nach Alpenswitch praktisch auf denselben Konsenszustand. Bestehende Anwendungen müssen ihre Commitment-Einstellung am Tag der Aktivierung nicht ändern. Die RPC-Schnittstelle akzeptiert weiterhin processed, confirmed und finalized. Der Latenzunterschied zwischen den letzten beiden verschwindet jedoch.

Für normale RPC-Nutzer ist der Unterschied zwischen den beiden Finalisierungspfaden von Votor unsichtbar. Ob ein Block den Schwellenwert von 80 % für die Schnellfinalisierung in einer Runde erreicht oder über den zweistufigen Pfad mit einem Schwellenwert von 60 % finalisiert wird: Das von außen sichtbare Ergebnis ist identisch.

Mehrere Blockkandidaten

Eine weitere wichtige Änderung in Alpenglow betrifft RPC-Anbieter, Indexer und andere Infrastruktur, die Validator-Daten verarbeitet. Ein Slot kann nicht länger als eindeutige Blockkennung behandelt werden.

Ein Solana-Slot ist ein Zeitfenster, in dem ein Leader einen Block produzieren kann. Eine bank ist dagegen die lokale Darstellung des Zustands durch den Validator, der beim Ausführen eines bestimmten Blockkandidaten entsteht. Diese Konzepte waren schon immer verschieden und konkurrierende Banks sind nicht neu. Dennoch behandelte ein großer Teil der produktiven Infrastruktur Slots und Blöcke bisher als Synonyme.

Mit Alpenglow wird diese Annahme zunehmend unsicher.

Agave 4.3 erweitert Geyser – die Validator-Schnittstelle zum Streamen von Account-, Transaktions-, Entry- und Block-Updates – um eine neue Kennung: bank_id. Die neuen Bank-bezogenen Callbacks, darunter update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank und notify_block_metadata_for_bank, ordnen ein Ereignis der konkreten Bank zu, die es erzeugt hat. Bank-bezogene Statusbenachrichtigungen enthalten ebenfalls eine bank_id. Die älteren Callbacks bleiben aus Kompatibilitätsgründen in 4.3 erhalten, sind aber veraltet und sollen im nächsten großen Agave-Release entfernt werden.

Entscheidend ist, dass bank_id eine lokale Bank-Instanz identifiziert, nicht einen global vereinbarten Block. Agave erzeugt Bank-IDs aus einem lokalen atomaren Zähler in der Validator-Runtime. Deshalb solltest du nicht erwarten, dass zwei Validatoren demselben wiedergegebenen Block dieselbe bank_id zuweisen. Infrastruktur sollte daher (slot, bank_id) verwenden, um konkurrierende Streams eines einzelnen Validators zu trennen. Zum Abgleichen von Daten über verschiedene Validatoren oder Verbindungen hinweg sollte sie dagegen die Block-ID oder den Blockhash verwenden.

In späteren Phasen von Alpenglow werden mehrere Banks für denselben Slot zum normalen Bestandteil des Validator-Betriebs.

Das deutlichste Beispiel ist der schnelle Leader-Wechsel, eine der Alpenglow-Komponenten, die nach der ersten Aktivierung von Votor eingeführt wird. Ein Leader kann optimistisch auf dem Parent aufbauen, von dem er erwartet, dass der Konsens ihn akzeptiert. Entscheidet Votor stattdessen, dass der Parent übersprungen werden soll, kann der Leader den Parent wechseln und für den Rest seines Leader-Zeitfensters neu aufbauen. Intern bedeutet das, eine Bank für denselben Slot durch eine andere zu ersetzen. Agave enthält bereits die dafür nötige UpdateParent-Logik. Der schnelle Leader-Wechsel gehört nicht zur ersten Alpenglow-Aktivierung in Agave 4.3 und wird voraussichtlich im Laufe von 4.4 eingeführt.

Eine Äquivokation des Leaders kann im Wesentlichen zum gleichen Ergebnis führen. Signiert und verteilt ein Leader zwei verschiedene Blöcke für denselben Slot, müssen Validatoren möglicherweise vorübergehend beide Kandidaten speichern und verarbeiten. Verschiedene Teile des Netzwerks können diese Kandidaten in unterschiedlicher Reihenfolge sehen, da Votor asynchron arbeitet und Validatoren Blöcke, Stimmen, Zertifikate und lokale Timeouts bei ihrem Eintreffen verarbeiten.

Eine kürzlich vorgenommene Änderung senkte MAX_ALTERNATE_BLOCKS_PER_SLOT von 11 auf 6. Ein Validator muss daher höchstens sieben Blockkandidaten für einen Slot speichern. Der Konsens reduziert diese Kandidaten letztlich auf einen Verlauf. Bei Votor erfordert die Beglaubigung mehr als 60 % des Stakes. Zwei widersprüchliche Blöcke können nicht beide gültige Beglaubigungszertifikate erhalten, ohne dass ein erheblicher Stake für beide stimmt. Unter Alpenglows Annahme, dass sich weniger als 20 % des Stakes byzantinisch verhalten, sind widersprüchliche Beglaubigungszertifikate unmöglich, ohne die Sicherheitsannahmen des Protokolls zu verletzen.

Für Geyser-Nutzer ist die praktische Lehre eindeutig: Verwende nicht mehr nur den Slot als Schlüssel für temporäre Zustände. Verfolge Account-Änderungen, Transaktionen, Entries und Blockmetadaten pro (slot, bank_id), bis der Konsens die verbleibende Bank bestimmt. Erscheint für denselben Slot eine weitere Bank, gehören deren Ereignisse zu einem separaten Kandidatenzustand. Sie dürfen die Ereignisse der ersten Bank nicht unbemerkt überschreiben.

Validator Admission Tickets

Stimmtransaktionen sind derzeit der größte Kostenfaktor beim Betrieb eines Solana-Validators. Bei TowerBFT zahlen Validatoren jedes Mal eine normale Transaktionsgebühr, wenn sie eine Stimme einreichen. Pro Epoche summiert sich das auf ungefähr 2 SOL. Alpenglow ersetzt diese Transaktionsgebühren durch eine einmal pro Epoche erhobene Gebühr für Validatoren, die in die aktive Konsensgruppe aufgenommen werden. Sie heißt Validator Admission Ticket (VAT).

Die Grundlagen für diesen Übergang sind bereits aktiv. Die in SIMD-0387 beschriebene Registrierung öffentlicher BLS-Schlüssel wurde im Juli im Mainnet aktiviert. Kurz darauf folgte das VAT-Feature-Gate SIMD-0357. Votor verwendet BLS-Signaturen, damit sich die Signaturen vieler Validatoren in einem einzigen kompakten Zertifikat bündeln lassen. Jeder Validator muss einen öffentlichen BLS-Schlüssel in seinem Vote-Account registrieren, bevor er an Alpenglow teilnehmen kann. Seit der Aktivierung des VAT-Gates sind Validatoren ohne solchen Schlüssel bereits von der Abstimmungsgruppe ausgeschlossen.

Bis Alpenglow startet, reichen Validatoren weiterhin normale Stimmtransaktionen ein und zahlen die zugehörigen Gebühren. In dieser Phase dient VAT vor allem als Zugangsfilter. Berechtigte Validatoren benötigen einen BLS-Schlüssel und müssen nach Stake zu den 2.000 höchstplatzierten qualifizierten Validatoren gehören. VAT beginnt mit der Aktivierung von Alpenglow. Dann verschwinden die Stimmtransaktionen.

Sobald Alpenglow aktiv ist, wird die Zulassung an den Epochengrenzen neu berechnet. Der Vote-Account eines Validators muss einen registrierten BLS-Schlüssel und genug SOL enthalten, um das Ticket sowie die Mietbefreiung zu decken. Qualifizieren sich mehr als 2.000 Accounts, ordnet das System sie nach Stake und nimmt die Validatoren mit dem höchsten Stake auf. Anschließend zieht es das Ticket direkt vom Vote-Account jedes aufgenommenen Validators ab und sendet es an Solanas Incinerator-Account. Validatoren müssen ihren Vote-Account daher ausreichend finanzieren. Im alten System wurden die Gebühren für Stimmtransaktionen vom Identity-Account des Validators abgezogen.

Die ursprünglichen Vorschläge für Alpenglow und VAT sahen ein Ticket von 1,6 SOL pro Epoche vor. Das entspricht ungefähr 80 % der rund 2 SOL, die ein Validator zuvor für Stimmtransaktionen ausgab. Diese Zahl ging von Solanas historischem Ziel einer Slot-Dauer von 400 Millisekunden aus. SIMD-0525 skaliert VAT stattdessen mit der Slot-Dauer. Bei Slot-Zeiten von 200 Millisekunden kostet die Zulassung 0,8 SOL.

VAT ändert außerdem, wohin diese Kosten fließen. Heute wird die von einer Stimmtransaktion gezahlte Grundgebühr von 5.000 Lamports halbiert: 50 % werden verbrannt und 50 % gehen an den Block-Leader. VAT wird dagegen vollständig an den Incinerator gesendet. VAT soll SOL jedoch nicht wesentlich deflationärer machen. Der Hauptzweck besteht darin, die Aufnahme in die Konsensgruppe weiterhin mit wirtschaftlichen Kosten zu verbinden, nachdem die Gebühren für Stimmtransaktionen entfallen.

Sicherheit und Vorbereitung

Das Konsensprotokoll eines laufenden Netzwerks zu ersetzen, ist ein außergewöhnlich riskanter Vorgang. Alpenglow durchläuft deshalb deutlich umfangreichere Tests und Migrationen als eine typische Agave-Feature-Aktivierung. Dazu gehören ein eigener Community-Testcluster und ein Bug-Bounty-Programm.

Seit Mai betreiben Validator-Operatoren einen eigenen Alpenglow Community Cluster, der auf mehr als 100 Nodes angewachsen ist. Die Operatoren verwenden echte Validator-Hardware und reale Netzwerkkonfigurationen. So lässt sich Alpenglow unter geografischer Verteilung, schwankender Latenz, verschiedenen Softwarekonfigurationen, Neustarts und Betriebsfehlern testen, die in kontrollierten Umgebungen nur schwer nachzustellen sind.

Einer seiner wichtigsten Zwecke war es, Alpenswitch selbst zu testen. Die Operatoren prüften nicht nur, ob Votor funktioniert, wenn ein Cluster bereits Alpenglow ausführt. Sie übten wiederholt den Übergang von TowerBFT zum neuen Konsenssystem.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9. Mai 2026, 6:59 PM

Alpenglow wurde außerdem gezielt auf Angriffsvektoren geprüft. Im August startete Anza einen zweiwöchigen Alpenglow-Bug-Bounty-Wettbewerb mit einem Preispool von bis zu 50.000 SOL. Anders als das dauerhafte Agave-Bounty konzentrierte sich der Wettbewerb speziell auf den neuen Konsens-Stack. Dazu gehörten Votor, die Prüfung von BLS-Signaturen und Zertifikaten, die Validator-Zulassung und der Migrationspfad von TowerBFT zu Alpenglow. Die Beteiligung war groß. Anza meldete mehr als 300 Einreichungen und kündigte die Ausschüttung von über 25.000 SOL als Belohnungen an.

Die Unterstützung für Frankendancer endet mit der Einführung von Alpenglow. Frankendancer war immer als Übergangsclient gedacht. Er kombiniert die Netzwerk- und Blockproduktionskomponenten von Firedancer mit Agave-Komponenten für Ausführung und Konsens. Das neue Konsenssystem in dieser hybriden Architektur zu unterstützen, würde erheblichen zusätzlichen Wartungs- und Sicherheitsaufwand verursachen. Deshalb konzentriert sich das Firedancer-Team stattdessen auf den vollständigen Firedancer-Client.

Validatoren wurde mitgeteilt, dass weder Frankendancer noch der vollständige Firedancer das kurze Migrationsfenster von TowerBFT zu Alpenglow unterstützen werden. Firedancer-Operatoren sollten daher vor Alpenswitch einen Failover zu einem Agave-Validator einrichten, während der Übergabe bei Agave bleiben und anschließend zu Firedancer zurückkehren, sobald der Cluster unter Alpenglow wieder normal läuft.

So läuft Alpenswitch tatsächlich ab

Alpenglow wird nicht überall zu einem beliebigen Zeitpunkt aktiviert. Sobald das Feature aktiviert ist, legt das Protokoll 5.000 Slots später eine Migrationsgrenze fest. TowerBFT läuft weiter, während Validatoren diese Grenze überschreiten und nach einem ausreichend stark bestätigten Block suchen. Anschließend signieren die Validatoren den ausgewählten Alpenglow-Genesis-Block mit BLS und verteilen diese Genesis-Stimmen direkt untereinander.

Die Übergabe erfolgt, sobald mindestens 82 % des Stakes denselben Genesis-Block signiert haben und dadurch das Alpenglow-Genesis-Zertifikat entsteht. Validatoren, die dieses Zertifikat empfangen und verifizieren, deaktivieren TowerBFT nach dem Genesis-Block und initialisieren Votor aus dem vereinbarten Zustand. Anschließend verbreitet sich das Zertifikat in der Validator-Gruppe und führt die übrigen Nodes über die Grenze.

Mit diesem Zertifikat können Infrastrukturbetreiber einfach feststellen, auf welcher Seite von Alpenswitch sich ein Cluster befindet.

Agave 4.3 führt eine neue RPC-Methode getAgGenesisCert ein. Vor der Migration gibt eine Agave-4.3-Node null zurück. Nach dem Wechsel des Clusters gibt sie das Alpenglow-Genesis-Zertifikat zurück, einschließlich Genesis-Block und aggregierter BLS-Signatur. Eine ältere Node, die diese Methode nicht unterstützt, gibt stattdessen Method not found zurück. Die CLI stellt dieselben Informationen über Folgendes bereit: solana alpenglow-genesis-info.

Validatoren, RPC-Anbieter und andere Infrastruktur, die auf die Migration reagieren muss, sollten deshalb nach dem Genesis-Zertifikat suchen, statt anzunehmen, dass Alpenglow zu einem bestimmten Zeitpunkt aktiv wurde.

Neue kryptografische Syscalls

Agave 4.3 erweitert außerdem das kryptografische Werkzeugset der SVM um neue Runtime-Primitive für Operationen, deren direkte Ausführung in sBPF unverhältnismäßig teuer wäre.

Die beiden wichtigsten Ergänzungen sind SHA-512-Hashing und modulare Exponentiation großer Ganzzahlen. Beide sind additiv und durch Feature-Gates geschützt: Bestehende Programme bleiben unverändert. Programme, die sie aktivieren, können rechenintensive Kryptografie an optimierte native Implementierungen in der Validator-Runtime delegieren.

Modulare Exponentiation großer Ganzzahlen

SIMD-0529: Syscall für Big-Integer-ModExp führt sol_big_mod_exp ein, einen Syscall zur Berechnung von:

result = (base ^ exponent) mod modulus

Modulare Exponentiation ist eine grundlegende Operation für die Verifizierung von RSA-Signaturen, kryptografische Akkumulatoren, einige verifizierbare Verzögerungsfunktionen und andere zahlentheoretische Protokolle. Sie direkt in einem SVM-Programm mit Ganzzahlarithmetik beliebiger Genauigkeit zu implementieren, ist extrem rechenintensiv. Das gilt besonders für gängige RSA-Schlüsselgrößen wie 2048, 3072 und 4096 Bit.

Der neue Syscall verlagert die aufwendige Arithmetik in die Validator-Runtime. Programme übergeben Basis, Exponent und Modulus als vorzeichenlose Little-Endian-Ganzzahlen. Das Ergebnis wird in einem vom Aufrufer bereitgestellten Speicherbereich abgelegt. Jeder Operand ist zunächst auf 512 Byte begrenzt. Das reicht für Ganzzahlen mit bis zu 4096 Bit.

Der offensichtlichste Anwendungsfall ist die RSA-Verifizierung. Ein Programm, das eine herkömmliche RSA-Signatur prüft, kann beispielsweise sol_big_mod_exp mit dem üblichen öffentlichen Exponenten 65537 aufrufen, statt selbst die Exponentiation großer Ganzzahlen zu implementieren. Der Syscall beschränkt sich bewusst auf das arithmetische Primitiv. Programme bleiben für Hashing, RSA-Padding wie PKCS#1 v1.5 oder PSS, Schlüsselvalidierung und jede protokollspezifische Domain Separation verantwortlich.

Er kann auch große Ganzzahlen effizient modular reduzieren. Mit dem Exponenten 1 reduziert sich die Operation auf:

base mod modulus

Damit erhalten Programme ein natives Primitiv, um Ganzzahlen zu reduzieren, die größer als die integrierten Maschinenwortgrößen der SVM sind. Eine universelle Big-Integer-Implementierung ist dafür nicht mehr nötig.

Das Design ähnelt konzeptionell Ethereums mit EIP-198 eingeführtem ModExp-Precompile. Auch das Modell zur Abrechnung der Rechenleistung folgt der Formel von EIP-198 für die Operationskomplexität. Es ist jedoch nicht Byte für Byte mit Ethereum kompatibel. Solana stellt die Funktion über eine native Syscall-ABI bereit, verwendet Little-Endian-Eingaben und verlangt, dass der Modulus eine ungerade Ganzzahl größer als eins ist. Gerade Moduli werden abgelehnt.

Das macht den Syscall besonders nützlich für Interoperabilität, ohne dass Solana dafür die EVM-Precompile-Schnittstelle übernehmen muss. Programme, die Beweise, Signaturen oder Attestierungen auf Basis Ethereum-typischer kryptografischer Annahmen prüfen, können dieselbe zugrunde liegende Arithmetik wiederverwenden und nur den Aufruf anpassen.

SHA-512

Die zweite Ergänzung ist deutlich einfacher, aber sofort nützlich.

SIMD-0512: SHA-512-Syscall fügt sol_sha512 hinzu. Dadurch erhalten Onchain-Programme über die Validator-Runtime direkten Zugriff auf die SHA-512-Hashfunktion. Die Schnittstelle entspricht Solanas bestehenden Syscalls sol_sha256, sol_keccak256 und sol_blake3 und gibt den standardmäßigen 64-Byte-SHA-512-Digest zurück.

SHA-512 ist insbesondere eines der zentralen Primitive von Ed25519, dem von Solana selbst intensiv genutzten Signaturverfahren. Sowohl Agave als auch Firedancer verwenden SHA-512 bereits intern. Vor dieser Änderung konnten SVM-Programme jedoch nicht direkt auf diese optimierte Implementierung zugreifen. Ein Programm, das SHA-512 benötigte, musste den Algorithmus stattdessen in Software implementieren.

Aus Sicht der Rechenleistung ist dieser Unterschied erheblich. Das SIMD schätzt, dass das Hashen einer kurzen Eingabe mit einer sBPF-Implementierung Tausende CUs kostet. Dieselbe Operation über den Syscall benötigt weniger als 100 CUs. sol_sha512 verwendet dasselbe allgemeine Kostenmodell wie Solanas bestehender SHA-256-Syscall.

Zusammen setzen die beiden Syscalls einen allgemeinen Trend in der SVM fort: Häufige, aber rechenintensive kryptografische Primitive wandern aus einzelnen Programmen in standardisierte, abgerechnete Runtime-Operationen. Programme definieren weiterhin das übergeordnete kryptografische Protokoll. Der Validator kann die aufwendigen Bausteine jedoch wesentlich effizienter ausführen als eine sBPF-Implementierung.

Fazit

Die wichtigste Änderung in Agave 4.3 ist Alpenglow. Es ersetzt TowerBFT durch Votor, entfernt Stimmtransaktionen aus Blöcken, verkürzt die Finalität von Sekunden auf Millisekunden und verändert, wie Validatoren und Infrastruktur mit dem Konsens interagieren.

Für die meisten Benutzer und Anwendungsentwickler wird ein großer Teil dieses Übergangs unsichtbar ablaufen. Für Validatoren, RPC-Anbieter, Indexer und Infrastrukturteams markiert Agave 4.3 jedoch den Beginn eines grundlegenden Wandels bei Solanas Konsensfindung.

Weitere Ressourcen

• Alpenglow-Whitepaper v1.2 (Juli 2026)
• Release-Zeitplan für Agave 4.3
• Zeitplan des Feature-Gate-Trackers
• Änderungsprotokoll für Agave 4.3
• Pull Requests für Agave 4.3
• Alpenglow-Upgrade – Solana Foundation