Das Netzwerk wechselte den Konsens nach einem kurzen Übergangsfenster
Epoche 1064 begann gegen 13:36 UTC am 21. Okt.. Das Netzwerk-Aktivierungsflag wurde zu Beginn der Epoche aktiv, aber das Netzwerk verwendete weiterhin TowerBFT für die ersten 5,000 Slots. Dieses Übergangsfenster dauerte etwa 18 Minuten.
Alpenglow übernahm gegen 13:54 UTC ab Slot 459,653,000 die Kontrolle. Solana meldete, dass 446 von 654 Validatoren den Übergangsblock zertifiziert haben. Die Verzögerung war geplant und gab den Betreibern einen klaren Zeitpunkt, zu dem sie prüfen konnten, ob das neue Konsenssystem gestartet war.
Votor ersetzt Vote-Transaktionen durch direkte Validator-Nachrichten
Unter TowerBFT, gaben Validatoren ihre Stimmen innerhalb von Transaktionen ab, und die Blockfinalisierung hing davon ab, dass sich Stimmen über 32 Slots hinweg ansammelten. Alpenglow‘s Votor System sendet Stimmen direkt zwischen Validatoren und fasst sie zu Zertifikaten zusammen. Ein Block kann nach einer oder zwei Abstimmungsrunden final werden.
Wallets und gewöhnliche Programme benötigen kein neues Transaktionsformat. Die Solana Virtual Machine, die Konten und das Gebührenmodell bleiben bestehen. Der praktische Nutzen ist die schnellere Gewissheit, dass eine bestätigte Überweisung oder eine Aktion innerhalb einer Anwendung nicht rückgängig gemacht werden kann.
Die Slot-Zeit von 200 Millisekunden ist eine separate Änderung
Solana hat seine Slot-Zeit in einem separaten Oktober-Update von 400 auf 200 Millisekunden reduziert. Die Slot-Zeit beschreibt, wie oft das Netzwerk einen neuen Slot erzeugen kann. Alpenglowetwa 150 Millisekunden beschreibt die Zielzeit für die Finalisierung eines Blocks. Die beiden Werte messen unterschiedliche Teile des Systems.
Das Ziel ist kein festes Ergebnis: Die Block-Finalisierungszeit kann je nach Netzwerkbedingungen und Standort der Validatoren variieren. Börsen und Anwendungen sollten das tatsächliche Verhalten messen, statt 150 Millisekunden als Versprechen für jede Übertragung zu behandeln.
| Detail | Bestätigte Informationen |
|---|---|
| Epoch 1064 begann | Gegen 13:36 UTC am 21. Okt. 2026 |
| Konsens wechselte zu Alpenglow | Gegen 13:54 UTC bei Slot 459,653,000 |
| Zielzeit für die Finalisierung eines Blocks | Etwa 150 ms, verglichen mit etwa 12.8 Sekunden unter TowerBFT |
| Separate Aktualisierung der Slot-Zeit | 200 ms |
| Kompatible Validator-Clients | Agave, Jito-Solana und Harmonic Salsa |
| Validator Admission Ticket | 0.8 SOL pro Epoch vom Vote-Konto |
| Zukünftige Komponente | Rotor Blockverteilungsprotokoll |
Datendienste müssen mehrere Versionen eines Slots unterscheiden
Ein Slot kann vorübergehend mehr als einen Kandidatenblock haben, was Solana als Kandidaten-Banks bezeichnet. Ein bank_id identifiziert einen Kandidaten innerhalb einer Datenverbindung. Indexer müssen diese Versionen getrennt halten, bis eine davon bestätigt ist. Beim Vergleich von Daten verschiedener Anbieter sollten sie den Block-Hash verwenden, weil bank_id Werte sind für jede Verbindung lokal.
Vote-Transaktionen erscheinen nicht mehr in den Blöcken. Dashboards, die diese Votes zuvor als Transaktionen gezählt haben, können daher einen plötzlichen Rückgang der angezeigten TPS auch wenn die Nutzeraktivität unverändert ist. Dies ist eine Änderung der Bilanzierung, kein Beweis dafür, dass das Netzwerk an Traffic verloren hat.
Validatoren benötigen kompatible Software und Guthaben für das Eintrittsticket
Mainnet-Validatoren müssen kompatible Versionen von Agave, Jito-Solana oder Harmonic Salsa. Außerdem benötigen sie mindestens 0.8 SOL über dem rentenbefreiten Minimum im Vote-Konto. Dieser Betrag finanziert das Validator Admission Ticket, in der Dokumentation mit der englischen Abkürzung V-A-T bezeichnet, für die nächste Epoche.
Der Validator Admission Ticket ersetzt die wiederkehrenden Kosten für das Senden von Vote-Transaktionen. Kann das Vote-Konto das Ticket nicht bezahlen, kann der Validator in der folgenden Epoch weder abstimmen noch Blöcke produzieren. Betreiber können künftige Blockeinnahmen auf das Konto leiten, benötigen aber dennoch einen anfänglichen Puffer.
Rotor wird später eingeführt
Das Live-Mainnet-Release enthält Votor. Rotor, der geplante Ersatz für die Turbine-Blockdatenverteilung, wird später kommen und hat kein bestätigtes Aktivierungsdatum. Die Konsensumstellung ist abgeschlossen, aber der breitere Alpenglow Netzwerkplan ist noch nicht vollständig umgesetzt.
Für Nutzer besteht die unmittelbare Verbesserung in einer schnelleren endgültigen Bestätigung. Börsen, Explorer und Datenanbieter müssen nun Kandidaten-Bänke und die überarbeitete Transaktionsanzahl korrekt verarbeiten, damit ihre Dienste die Aktivität des Netzwerks genau anzeigen.
Dieser Artikel dient nur zur Information und ist keine Anlageberatung.
admin_wcAutor · World-CryptMehr von
