Solanas nächste große Konsensreform, Alpenglow, soll am 21. Oktober 2026 im Mainnet ausgerollt werden – und sie könnte einen Nebeneffekt haben, den kaum einBeobachter erwartet: einen steilen, rein statistischen Rückgang der gemeldeten Transaktionszahl des Netzwerks.

Laut der Alpenglow-Dokumentation der Solana Foundation soll die Epoche 1064 am 21. Oktober gegen 15:00 UTC beginnen. Da sich das Timing der Epochen verschieben kann, ist diese Uhrzeit eine Schätzung und kein fester Aktivierungszeitpunkt. Epochen sind lange Sequenzen von Slots, die Solanas Ledger strukturieren; ihre Grenzen verschieben sich mit der tatsächlichen Blockproduktion – gut zu wissen für alle, die den Rollout in Echtzeit verfolgen. TowerBFT bleibt für die ersten 5.000 Slots der Epoche – etwa 18 Minuten – in Betrieb, danach soll der Alpenglow-Konsens bei Slot 459.653.000 übernehmen.

Das Mainnet-Release steht im Zeichen von Votor, Alpenglows neuem Voting- und Finalitätsprotokoll, das eine Block-Finalität von rund 150 Millisekunden anstrebt – gegenüber rund 12,8 Sekunden unter dem aktuellen TowerBFT-System. Rotor, eine separate Alpenglow-Komponente, die Solanas Turbine-Blockweiterleitung ersetzen soll, ist für ein späteres Release geplant und hat noch kein Mainnet-Datum. Der gestufte Ansatz hält die Oktober-Aktivierung auf Konsensänderungen beschränkt.

Je nach Blickwinkel ein unterschiedliches Upgrade

Der Unterschied ist wichtig. Alpenglow ist so konzipiert, dass das gewöhnliche Wallet-Erlebnis unverändert bleibt, während sich Infrastruktur, die Solana-Daten erzeugt, streamt und interpretiert, grundlegend ändert. Für normale Nutzer ändert sich an der Transaktionseinreichung nichts; die Anpassungsarbeit liegt bei Validator-Betreibern, Infrastrukturanbietern und Datenplattformen.

Votor ersetzt On-Chain-Votes durch Validator-Zertifikate

Konsens ist der Prozess, bei dem die Validatoren einer Blockchain darüber einig werden, welche Blöcke gelten. Unter Solanas aktuellem TowerBFT-Konsens geben Validatoren ihre Votes als On-Chain-Transaktionen ab. Diese Votes akkumulieren sich über 32 Slots, bevor ein Block Finalität erreicht – daraus ergibt sich die rund 12,8-sekündige Wartezeit auf die stärkste Settlement-Garantie.

Votor nimmt diese Votes aus dem Block selbst heraus. Validatoren senden sie direkt aneinander und aggregieren sie zu Zertifikaten, sodass ein Block in einer oder zwei Voting-Runden Finalität erreichen kann.

Das 150-Millisekunden-Ziel bezieht sich darauf, wie lange eine Transaktion bis zur Finalität – also bis zur Unumkehrbarkeit – benötigt. Es bedeutet nicht, dass Solana alle 150 Millisekunden einen neuen Block erzeugt; die Slot-Zeiten wurden separat im Oktober auf 200 Millisekunden gesenkt.

Für Dienste, die vor der Gutschrift einer Einzahlung, der Freigabe von Waren oder dem Abschluss einer Überweisung auf Finalität warten, könnte die Änderung einen Großteil der Verzögerung beseitigen, die durch Solanas eigenen Konsensprozess entsteht. Sie beseitigt nicht Verzögerungen, die durch Risikoprüfungen von Börsen, Bridges, Zahlungsanbieter oder andere Chains entstehen. Der Nutzen ist am größten in Workflows, in denen eine Partei auf eine stärkere Settlement-Garantie wartet, bevor sie die Gegenseite einer Transaktion abschließt. Solanas Delivery-versus-Payment-Escrow-Tool ist ein Beispiel für Infrastruktur, die von schnellerer Finalität profitieren könnte, ohne dass Nutzer ihre Transaktionseinreichung ändern müssen.

Das Entfernen der Votes wird Solanas Transaktionsdaten über Nacht verändern

Die sichtbarste Änderung für Analysten dürfte gar nicht die Finalität sein. Votetransaktionen werden unter Votor nicht mehr in Solana-Blöcken erscheinen. Da diese Votes bislang wie jede andere Transaktion in Blöcken aufgezeichnet wurden, haben Dashboards, die alles in einem Block zählen, sie lange in den bekannten Durchsatzzahlen erfasst – und da Votes einen großen Anteil der gezählten Transaktionen ausmachten, können die Gesamtzahlen der Transaktionen und TPS-Werte nach der Aktivierung stark sinken.

Das wäre eine Änderung der Erfassung, kein Beleg dafür, dass Solana plötzlich Nutzer oder Anwendungsnafrage verloren hat. Ein Dashboard, das Alpenglow-Nachher-Zahlen weiter mit Vorher-Werten vergleicht, ohne seine Basiswerte anzupassen, könnte fälschlich einen Einbruch der Netzwerkaktivität melden.

Bevor man nach dem 21. Oktober daraus schließt, „Solana-Transaktionen sind gesunken, also ist die Solana-Nutzung gesunken“, sollte man prüfen, ob das Dashboard die Votetransaktionen vor dem Upgrade in seinem historischen Basiswert enthält. Ist das der Fall, ist die offizielle Transaktionszahl nicht direkt vergleichbar. Solanas eigene Empfehlung sagt Indexern und Durchsatz-Dashboards, ihre Daten neu zu basieren, und Tools, die die Partizipation bislang über das Parsen von Vote-Programm-Instruktionen gemessen haben, müssen auf die Zertifikate im Block-Footer von Alpenglow umstellen.

Nach dem Upgrade eine Palette von Aktivitätskennzahlen nutzen

Keine einzelne Kennzahl kann die Netzwerknafrage beschreiben. Sobald die Votetransaktionen verschwinden, wird die sauberste Lesart eine Kombination mehrerer Maße sein, statt den Gesamt-TPS als alleiniges Urteil zu behandeln:

• Non-Vote-Transaktionen: ein direktes Maß für Transaktionen außerhalb der Validator-Abstimmungen.
• Aktive Gebührenzahler: ein besserer Indikator für die Breite der Partizipation als reine Transaktionszahlen.
• Anzahl und Wert von Stablecoin-Transfers: nützlich zur Verfolgung von Zahlungs- und Settlement-Aktivität.
• DEX-Volumen und eindeutige Trader: zusammen geben sie mehr Kontext als das Volumen allein.
• Gebühreneinnahmen: hilfreich ergänzend zu Nutzerkennzahlen, bewegen sich aber auch mit Gebührenbedingungen und Handelsintensität.

Dieser Ansatz macht Vergleiche nach dem Upgrade ehrlicher. Sinkt der Gesamt-TPS, während Non-Vote-Transaktionen, aktive Gebührenzahler und Anwendungsvolumen stabil bleiben, hat das Netzwerk seine Buchführung geändert – nicht unbedingt seine Nachfrage.

Woran sich zeigt, ob der Rollout funktioniert hat

Der erste Test ist die realisierte Finalität. Das Netzwerk muss zeigen, dass Blöcke nahe am angegebenen Ziel Finalität erreichen, ohne nennenswerte Instabilität oder einen Anstieg übersprungener Slots.

Der zweite ist die operative Bereitschaft. Validatoren müssen auf unterstützte Agave-basierte Clients migrieren; Firedancer und Frankendancer werden während der Übergangszeit nicht unterstützt. Indexer und RPC-/Geyser-Nutzer müssen zudem das neue Feld bank_id verarbeiten, da ein Slot mehr als einen Kandidatenblock enthalten kann.

Der dritte ist die Datenkontinuität. Explorer, Analyseplattformen und Medienberichte müssen zwischen weniger Validator-Votes und schwächerer Anwendungsnafrage unterscheiden, bevor sie aus Solanas Transaktionscharts nach dem Upgrade Schlüsse ziehen.

Schnellere Finalität – und ein veralteter TPS-Basiswert

Alpenglows unmittelbares Versprechen ist deutlich schnellere Finalität, ohne dass normale Nutzer ihre Transaktionen anders einreichen. Die weniger offensichtliche Folge: Sobald die Validator-Votes aus den Blöcken verschwinden, müssen die vertrauten Solana-Aktivitätsstatistiken neu gesetzt werden. Nach dem 21. Oktober sollte ein Rückgang der offiziellen Transaktionszahlen zuerst als Frage der Messung behandelt werden. Nur ein gleichzeitiger Rückgang der Non-Vote-Aktivität, der aktiven Gebührenzahler und der Nutzung auf Anwendungsebene würde die Schlussfolgerung stützen, dass die Nachfrage selbst nachgelassen hat.\nDieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Timing und Leistung der Mainnet-Aktivierung hängen von Netzwerkbedingungen und Implementierungsreife ab.

Quelle: Coindoo