Solana wird voraussichtlich noch in dieser Woche „Alpenglow“ – das Anza als das größte Konsens-Upgrade in der Geschichte des Projekts bezeichnet – in das öffentliche Testnetz überführen.
In einem Beitrag vom Dienstag deutete Brennan Watt, CEO von Anza, an, dass das Upgrade in Epoch 1042 im Testnetz live gehen werde, was laut Daten von Solana Beach in weniger als zwei Tagen erwartet wird.
Dieser Schritt markiert den ersten formellen Schritt einer Migration, bei der TowerBFT, das bestehende Konsenssystem von Solana, schlussendlich durch Alpenglow ersetzt wird. Das Upgrade läuft bereits seit mehr als vier Monaten auf einem dedizierten Community-Cluster, auf dem die Betreiber den Migrationsprozess wiederholt durchgespielt haben.
Von 12,8 Sekunden auf 150 Millisekunden
Die wichtigste Änderung durch Alpenglow betrifft die Geschwindigkeit, mit der Solana die Finalität erreicht – den Zeitpunkt, ab dem das Netzwerk eine Transaktion gemäß seinen Konsensregeln als unwiderruflich betrachtet.
Anza schätzt, dass Alpenglow die Finalität von etwa 12,8 Sekunden auf rund 100 bis 150 Millisekunden verkürzen kann. Dies könnte die Art und Weise verändern, wie Börsen, Brücken und Händler mit Solana-Transaktionen umgehen, da diese Dienste oft auf die Finalität warten, bevor sie Einzahlungen gutschreiben, Vermögenswerte freigeben oder Zahlungen bestätigen.
Das Upgrade ersetzt TowerBFT durch Votor. Anstatt Konsensstimmen als Blockchain-Transaktionen zu erfassen, tauschen Validatoren ihre Stimmen direkt aus. Votor kann einen Block über einen von zwei Abstimmungswegen finalisieren. Der eine Weg ist nach einer Runde abgeschlossen, wenn 80 % des Stakes teilnehmen, während der andere zwei Runden benötigt, sobald die Teilnahme 60 % erreicht. Durch den Wegfall der On-Chain-Abstimmung wird zudem Blockspeicherplatz freigegeben, der derzeit durch den Konsensverkehr belegt ist.
Wie Solana den Konsens wechseln wird, ohne den Betrieb zu unterbrechen
Alpenglow erfordert keine neue Chain, keinen Netzwerk-Neustart und keine Token-Migration. Solana wird den Konsens wechseln, während das Live-Netzwerk weiterläuft.
Die Migration erfolgt in vier Schritten. Zunächst wird das „Alpenglow“-Feature-Gate an einer Epochengrenze aktiviert. Zu diesem Zeitpunkt findet noch keine Migration statt.
Dann, 5.000 Slots später, wird die Migrationsgrenze erreicht. Blöcke enthalten keine Benutzertransaktionen mehr, sondern ausschließlich Stimmen. Dies schafft einen sicheren Rollback-Punkt, da Validatoren Blöcke nach der Grenze verwerfen können, ohne Benutzertransaktionen zu verlieren.
Die Validatoren führen TowerBFT weiter aus, bis ein Block Stimmen von 82 % des Stakes erhält. Der letzte Vorfahr dieses Blocks vor der Grenze wird zum Alpenglow-Genesis-Block.
Anschließend unterzeichnen die Validatoren eine BLS-Genesis-Stimme. Sobald 82 % des Stakes beigetragen haben, entsteht das Genesis-Zertifikat.
Schließlich führen die Validatoren ein Rollback aller Daten nach dem Genesis-Block durch, übergeben den Konsens an Votor und setzen die Verarbeitung von Benutzertransaktionen fort. TowerBFT wird außer Betrieb genommen, während Alpenglow ab dem Genesis-Block die Kontrolle übernimmt.
Agave 4.3 führt den ersten Test an
Validatoren, die an der Testnetz-Migration teilnehmen, müssen Agave v4.3.0 ausführen. Anza empfahl am 21. September Agave v4.3 für alle Mainnet-Beta-Validatoren, nachdem eine schrittweise Einführung stattgefunden hatte, die zunächst Betreiber mit einem Anteil von 10 % und anschließend von 25 % des Stakes umfasste.
Anzas aktueller Zeitplan nennt den 28. September als vorläufigen Termin für die Aktivierung der in Agave 4.3 enthaltenen Funktionen im Mainnet-Beta. Dies stellt jedoch kein bestätigtes Startdatum für das Alpenglow-Mainnet dar.
Firedancer unterstützt die Alpenglow-Migration nicht
Firedancer und Frankendancer unterstützen die Alpenglow-Migration derzeit nicht. Testnet-Betreiber, die einen dieser Clients nutzen, müssen vor der Aktivierung des Feature-Gates auf Agave v4.3.0 umsteigen.
Die Situation hat zudem Bedenken hinsichtlich der Client-Vielfalt aufkommen lassen. Mike MacCana, zuständig für Entwicklerbeziehungen bei QuickNode, äußerte Bedenken darüber, dass das Netzwerk während der Migration auf einen einzigen Client angewiesen ist.
Das Firedancer-Team plant, die Unterstützung für Frankendancer einzustellen, sobald Alpenglow das Solana-Mainnet erreicht – was voraussichtlich mit Version 4.3 geschehen wird –, und begründet dies mit dem damit verbundenen Wartungs- und Sicherheitsaufwand. Das Team wird sich stattdessen auf den vollständigen Firedancer-Client konzentrieren.
Timothy Garcia, Leiter der Validator-Beziehungen bei der Solana Foundation, bezeichnete die Aktivierung des Testnets als das Ende einer Ära für Frankendancer, würdigte jedoch den Client für seinen bedeutenden Einfluss auf das Ökosystem.
Wie geht es weiter?
Nach dem Testnetz wird „Alpenglow“ das Devnet durchlaufen, bevor es die Mainnet-Beta-Phase erreicht. Jeder Cluster muss denselben Migrationsprozess durchlaufen, bevor die nächste Phase beginnt.
Das Upgrade bleibt zudem unabhängig von den Verbesserungen der Slot-Zeit bei Solana. Die Slot-Zeit von Solana sank kürzlich unter SIMD-0525 auf 250 Millisekunden, während in einer zukünftigen Phase 200 Millisekunden angestrebt werden.
Alpenglow verändert stattdessen, wie schnell Validatoren die Finalität erreichen. Wenn die Migration in jeder Phase erfolgreich verläuft, wird Solana zu einem Netzwerk übergehen, in dem die Blockfinalität in etwa 150 Millisekunden erreicht werden kann, ohne dass sich die Art und Weise ändert, wie Nutzer Transaktionen senden oder wie Anwendungen diese ausführen.
Mehr dazu auf SolanaFloor
X fügt Cashtags einen „Trade“-Button hinzu und macht $BTC und $SOL für US-Nutzer mit einem Klick erreichbar
Cryptopunks, Boogles und zkSnarks verzeichnen Millionen an Handelsvolumen, während die NFT-Märkte wieder aufleben
So handeln Sie auf Solana wie ein Profi
