Solanas Entwickler haben das Alpenglow-Konsens-Upgrade für den 21. Oktober angesetzt, mit dem Ziel einer Finalität von etwa 150 Millisekunden, und bitten Validatoren und Anwendungsbetreiber, sich auf Änderungen während der Mainnet-Übergabe vorzubereiten.
Zusammenfassung
- Solanas Alpenglow-Upgrade ist für den 21. Oktober geplant und zielt auf eine Transaktionsfinalität von etwa 150 Millisekunden ab.
- Quicknode warnt vor einer kurzen Transaktionspause und möglichen Datenstromunterbrechungen während der Übergabe.
- Validatoren müssen kompatible Software verwenden und Vote-Konten für die Aufnahmegebühr von 0,8 SOL finanzieren.
- Einige RPC-Knoten erhalten Finalitätsinformationen möglicherweise später als Validatoren, die direkt am Konsens teilnehmen.
Quicknodes Wartungshinweis identifiziert Mittwoch als den geplanten Aktivierungstag, aber sein neuestes Update warnt, dass die ursprüngliche Schätzung von 14:50 UTC auf 13:20 UTC vorverlegt werden könnte, da die Blockproduktion fortschreitet. Der Anbieter bittet Betreiber, ab 13:00 UTC bereit zu sein, wobei die Konsensübergabe etwa 20 Minuten nach der Aktivierung folgt.
Die aktuelle Upgrade-Seite der Solana Foundation ordnet die Änderung der Epoche 1064 zu und listet Mainnet als noch nicht aktiviert. Ihre aktualisierte Schätzung legt den Beginn der Epoche nahe 13:20 UTC, wodurch die Epochengrenze zum relevanten Auslöser wird statt eines festen Uhrzeittermins.
Solana Alpenglow zielt auf Finalität, nicht auf schnellere Ausführung
Nach Anzas Design ersetzt Votor die Abstimmungs- und Finalitätslogik von TowerBFT. Das Ziel sind etwa 150 Millisekunden unter normalen Netzwerkbedingungen, keine Garantie, dass jede Wallet, Börse oder Handelsanwendung eine abgeschlossene Transaktion innerhalb dieses Zeitraums anzeigt.
Die Foundation sagt, dass Transaktionsausführung, Programmverhalten und Gebührenmechanik unverändert bleiben. Normale Nutzer müssen nicht ändern, wie sie Transaktionen signieren oder genehmigen, während das separate Rotor-Datenverteilungs-Upgrade für eine spätere Version reserviert ist. Ihre Dokumentation trennt den Konsens-Rollout von früheren Reduzierungen der Slot-Dauer, die regeln, wie häufig das Netzwerk Blöcke produziert.
Quicknodes technische Übersicht beschreibt zwei gleichzeitig operierende Abstimmungspfade. Einer kann einen Block in einer einzigen Runde finalisieren, wenn 80 % der Validatoren teilnehmen, während der andere eine zweite Runde verwendet, wenn die Beteiligung 60 % erreicht.
Der Anbieter unterscheidet diesen Prozess von den frühen Bestätigungen, die Nutzer bereits sehen. Seine Übersicht besagt, dass Anwendungen üblicherweise Bestätigungen innerhalb von zwei bis drei Sekunden unter optimistischen Einstellungen anzeigen, bevor das alte System bei etwa 13 Sekunden die vollständige Finalität erreicht.
Die Oktober-Bereitstellung folgt einer früheren Roadmap, die Alpenglow mit Agave 4.3 verknüpfte. Ein Bericht vom 14. August dokumentierte, dass Alpenglow-Code vorhanden war in Agave 4.2 zum Testen, ohne die Mainnet-Aktivierung in dieser Version zu autorisieren.
Bis zum 26. September hatte das Upgrade Devnet nach Testnet erreicht, nachdem am Vortag der Übergang erfolgt war, wie zuvor von crypto.news berichtet. Anwendungsteams konnten dann das neue Konsensverhalten prüfen, bevor sie gegen das Netzwerk bereitstellen, das die Gelder der Nutzer verwaltet.
Händler sehen eine kurze Unterbrechung während der Übergabe
Quicknode warnt, dass neue Transaktionen kurzzeitig aufhören werden, in Blöcke zu gelangen, während das Netzwerk die Konsenssysteme wechselt. Sein Hinweis beschreibt eine Pause von einigen Sekunden, wobei eine längere Unterbrechung möglich ist, wenn der Übergang mehr Zeit in Anspruch nimmt.
Transaktionseinreichungen könnten vorübergehend einen Preflight-Fehler „node unhealthy“ zurückgeben, so der Anbieter. Yellowstone-Datenströme könnten einmalig getrennt werden, während Abonnements, die die früheste verarbeitete Commitment verwenden, Slots anzeigen können, die nie die Bestätigung erreichen.
Der Wartungshinweis empfiehlt bestätigte oder finalisierte Commitment für Daten, die nicht rückgängig gemacht werden dürfen. Quicknode sagt, dass seine bestehenden Solana-Endpunkte bestehen bleiben und sein Team das Netzwerk während der gesamten Änderung überwachen wird.
In der technischen Übersicht des Anbieters ist eine schnellere irreversible Abwicklung relevant für Finanzanwendungen, Unternehmensschatztransfers und Echtzeitdienste. Das Dokument stellt diese Verwendungen als Fähigkeiten der vorgeschlagenen Konsensarchitektur dar, ohne festzustellen, dass einzelne Handelsplattformen am Aktivierungstag neue Abwicklungsrichtlinien übernehmen werden.
Validator-Bereitschaft umfasst Software und Kontoguthaben
Die aktuelle Checkliste der Solana Foundation weist Validatoren an, vor Epoche 1064 Version 4.3.2 von Agave, Jito-Solana oder Harmonic Salsa auszuführen. Firedancer und Frankendancer werden während der Migration laut derselben Anleitung nicht unterstützt.
Betreiber müssen mindestens 0,8 SOL über dem mietfreien Minimum in ihren Vote-Konten halten, um das Validator Admission Ticket zu decken. Die erste Abbuchung bezahlt die Teilnahme an Epoche 1065, und eine unbezahlte Gebühr hindert einen Validator daran, in dieser nächsten Epoche abzustimmen oder Blöcke zu produzieren.
Die Governance-Genehmigung liegt zeitlich vor diesen operativen Anforderungen. Der Vorschlag wurde im September 2025 mit 98,27 % der Stimmen dafür angenommen, so die Berichterstattung über die abgeschlossene Abstimmung. Die Beteiligung entsprach 52 % des Stakes, sodass der Genehmigungsprozentsatz die abgegebenen Stimmen beschreibt und nicht die gesamte Validator-Population.
Diese frühere Abstimmung genehmigte SIMD-0326, den Vorschlag hinter der Konsensüberholung. Der damalige Bericht verzeichnete 1,05 % dagegen und 0,69 % Enthaltungen, wobei die kleine Rundungsdifferenz in den veröffentlichten Zahlen erhalten bleibt.
RPC-Bereitstellung kann hinter dem 150-ms-Ziel zurückbleiben
Die Betreiberdokumentation von Anza erklärt, dass Konsensnachrichten normalerweise unter zugelassenen Validatoren zirkulieren. Ein nicht gestakter Knoten, der den Standardzustellungsweg nutzt, erfährt die Finalität aus Zertifikaten, die in späteren Blöcken mitgeführt werden, was typischerweise bis zu ein produziertes Blockintervall hinzufügt.
Übersprungene oder verzögerte Blöcke können diese Wartezeit verlängern. Ein Knoten, der mit einem zugelassenen Validator verbunden ist, kann Nachrichten direkt empfangen, wobei die Netzwerklatenz zwischen beiden weiterhin Teil der Zustellungszeit bleibt.
Die Devnet-Berichterstattung vom September dokumentierte separate Änderungen für Indexer und Explorer. Kandidatenblöcke müssen bis zur Bestätigung getrennt bleiben, und Validator-Beteiligungsdaten entfernen sich von gewöhnlichen Vote-Transaktionen hin zu Zertifikaten, die an Blockdaten angehängt sind.
Laut diesem Bericht verändert das Entfernen von Vote-Transaktionen die Dashboard-Summen, selbst wenn die Anzahl der Nutzerzahlungen und Trades konstant bleibt. Dienste, die beide Kategorien zählen, müssen ihre Vergleiche zurücksetzen, während Systeme, die Validator-Votes verfolgen, die ersetzenden Zertifikatsdaten lesen müssen.
