Solana hat seine Ziel-Slot-Zeit von 300 Millisekunden auf 250 Millisekunden reduziert, wodurch sich die Rate, mit der das Netzwerk Slots produziert, um fast 17 % erhöht, ohne dass die Gesamtverarbeitungsobergrenze im gleichen Maße angehoben wird.
Zusammenfassung
- Solana hat seine Ziel-Slot-Zeit von 300 ms auf 250 ms reduziert, wodurch das Netzwerk auf vier Ziel-Slots pro Sekunde kommt.
- Der schnellere Takt verkürzt das Vier-Slot-Leader-Fenster jedes Validators von 1,2 Sekunden auf eine Sekunde.
- Die Gesamtverarbeitungskapazität bleibt weitgehend unverändert, da Rechen- und Datenlimits mit abnehmender Slot-Dauer sinken.
- Die 250-ms-Einstellung verkürzt eine erwartete Solana-Epoche von etwa 36 Stunden auf 30 Stunden.
- Eine abschließende Reduzierung auf 200 ms würde Solana auf fünf Slots pro Sekunde bringen, aber es wurde noch kein Mainnet-Termin festgelegt.
Laut Blockchain-Daten ging die neue Einstellung am 18. September live und bringt Solana auf vier Ziel-Slots pro Sekunde, verglichen mit etwa 3,3 unter der vorherigen 300-ms-Konfiguration. Die Änderung ist die dritte Stufe von SIMD-0525, das darauf ausgelegt ist, die Slot-Zeiten schrittweise von der ursprünglichen 400-ms-Einstellung des Netzwerks auf ein endgültiges Ziel von 200 ms zu reduzieren.
Ein Slot ist der Zeitraum, in dem ein designierter Validator einen Block produzieren kann. Eine Verkürzung dieses Zeitraums gibt Wallets, Börsen und Handelsanwendungen häufigere Updates über den Zustand des Netzwerks.
Validatoren fungieren weiterhin als Leader für vier aufeinanderfolgende Slots. Da jeder Slot nun auf 250 ms ausgelegt ist, ist das nominelle Leader-Fenster eines Validators von 1,2 Sekunden bei der vorherigen Einstellung auf eine Sekunde gesunken.
Solana-Slot-Zeit erreicht 250 ms
Solana begann die aktuelle Einführung im August, als es seine Slot-Zeit zum ersten Mal seit dem Start des Netzwerks von 400 ms auf 350 ms reduzierte, wie crypto.news zuvor berichtete.
SIMD-0525 unterteilte den Prozess in vier Stufen bei 350 ms, 300 ms, 250 ms und 200 ms, anstatt direkt zum endgültigen Ziel überzugehen. Jede Reduzierung erfordert eine separate Feature-Aktivierung, sodass Entwickler und Validator-Betreiber die Netzwerkleistung bewerten können, bevor sie fortfahren.
Bei 250 ms ergeben sich vier Slot-Möglichkeiten pro Sekunde. Die kürzeren Intervalle können Anwendungen eine aktuellere Sicht auf Transaktionen und den Netzwerkzustand geben, während die Blockproduktion schneller von einem Validator an einen anderen übergeht.
Oracle-basierte Märkte und automatisierte Market Maker gehören zu den Anwendungen, die von dem Vorschlag abgedeckt werden, da ihre Abläufe vom Alter der Onchain-Daten abhängen können. Ein kürzeres Intervall reduziert die Zeitspanne zwischen Netzwerk-Updates, während Benutzer Statusänderungen von Transaktionen schneller sehen können.
Bei Swaps kann die kürzere Timing den Zeitraum zwischen der Übermittlung einer Transaktion und dem Erreichen des Netzwerks verringern. Der zugrunde liegende Vorschlag identifiziert schnellere Bestätigungen und häufigere Updates als Vorteile der Reduzierung der Slot-Dauer.
Die Änderung erhöht die Rohtransaktionskapazität von Solana nicht um fast 17 %.
Unter SIMD-0525 werden Ressourcenlimits proportional zur Slot-Dauer reduziert. Über einen bestimmten Zeitraum werden mehr Slots produziert, aber jeder Slot darf weniger Berechnung und Daten tragen, wodurch die Arbeitsmenge, die das Netzwerk in Echtzeit verarbeiten kann, auf etwa demselben Niveau bleibt.
Bei der vom Vorschlag verwendeten Basis von 60 Millionen Compute Units sinkt das Limit pro Slot, je schneller der Takt wird. Die 250-ms-Konfiguration entspricht einem Limit von 37,5 Millionen Compute Units, während die geplante 200-ms-Stufe es auf 30 Millionen senken würde.
Schnellere Blöcke verändern die Infrastrukturanforderungen von Solana
Infrastrukturanbieter haben nun mehr einzelne Blöcke zu verarbeiten und zu speichern, obwohl die Wall-Clock-Verarbeitungsobergrenze weitgehend unverändert bleibt.
Anwendungen, die die verstrichene Zeit berechnen, indem sie Slot-Nummern mit einer festen Slot-Dauer multiplizieren, müssen möglicherweise den schnelleren Takt berücksichtigen. Blockhashes laufen in Echtzeit schneller ab, da Slots schneller voranschreiten, wodurch weniger Zeit für Transaktionsprozesse bleibt, die Offline-Signierung oder verzögerte menschliche Genehmigungen beinhalten.
Das Epoch-Timing ändert sich aus demselben Grund. Solana hält jede Epoche fest bei 432.000 Slots, was bedeutet, dass eine Epoche kürzer wird, wenn die Dauer jedes Slots sinkt.
Beim früheren Ziel von 300 ms dauerte eine Epoche etwa 36 Stunden. Die 250-ms-Einstellung verkürzt die erwartete Dauer auf etwa 30 Stunden. Ein Wechsel zum endgültigen Ziel von 200 ms würde sie auf ungefähr 24 Stunden reduzieren.
Solanas stufenweise Slot-Reduzierungen sind Teil des Agave-4.2-Rollouts. Die Client-Version begann im August mit der Aktivierung mehrerer Netzwerkänderungen, darunter niedrigere Onchain-Speichermiete, größere Transaktionen und der Weg zu 200-ms-Slots.
Das stufenweise Design enthält eine Absicherung, die an die Block-Skip-Raten gekoppelt ist. Der Fortschritt zur nächsten Slot-Einstellung kann gestoppt werden, wenn die Skip-Raten über das von den Entwicklern als akzeptabel erachtete Niveau steigen, wodurch Validatoren Zeit erhalten, unter jeder Konfiguration zu arbeiten, bevor eine weitere Reduzierung aktiviert wird.
Für die 200-ms-Stufe wurde kein Mainnet-Termin festgelegt.
Solana-Upgrades gehen über schnellere Slots hinaus
Das Slot-Timing ist nur ein Teil der Netzwerkänderungen, die über Agave eingeführt werden.
Solana führte separat Transaction V1 ein, wodurch die maximale serialisierte Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes erhöht wird. Das größere Transaktionsformat kann datenintensive Operationen wie Zero-Knowledge-Beweise und komplexe Multisignatur-Anweisungen innerhalb einer einzigen Transaktion aufnehmen.
Transaction V1 ist optional, während Legacy- und Version-Zero-Transaktionen weiterhin unterstützt werden. Anwendungen, die Blöcke lesen, müssen das neuere Format unterstützen, um V1-Transaktionen korrekt zu verarbeiten.
Die Erhöhung der Transaktionsgröße ist von SIMD-0525 getrennt. Größere einzelne Transaktionen bestimmen daher nicht die Slot-Uhr, während kürzere Slots nicht automatisch die maximale Größe einer Transaktion erhöhen.
Solana hat die Änderungen unabhängig über Feature Gates aktiviert. Die Struktur ermöglicht es, dass ein Upgrade voranschreitet, ohne dass die anderen in Agave 4.2 enthaltenen Funktionen gleichzeitig aktiviert werden müssen.
Solana peilt weiterhin 200-ms-Slots an
Die letzte Stufe unter SIMD-0525 würde die Ziel-Slot-Zeit von 250 ms auf 200 ms reduzieren und das Netzwerk auf fünf angestrebte Slots pro Sekunde bringen.
Ein Vier-Slot-Validator-Leader-Fenster würde folglich auf etwa 800 ms fallen. Die Epochendauer würde von etwa 30 Stunden unter der aktuellen 250-ms-Einstellung auf ungefähr 24 Stunden sinken.
Solana-Entwickler haben kein Mainnet-Aktivierungsdatum für die endgültige Reduzierung angegeben. Der Fortschritt hängt vom Netzwerkverhalten unter der aktuellen Einstellung ab, einschließlich der Frage, ob Validatoren akzeptable Block-Skip-Raten aufrechterhalten können.
Die Slot-Reduzierungen sind von Alpenglow getrennt, Solanas geplantem Konsens-Redesign. Alpenglow soll TowerBFT durch ein Votor genanntes Abstimmungssystem ersetzen und Onchain-Abstimmungstransaktionen aus dem Kernkonsensprozess des Netzwerks entfernen.
Das Alpenglow-Konsens-Upgrade zielt auf etwa 150 ms Finalität ab. Sein Code wurde zum Testen aufgenommen, während der Mainnet-Einsatz an Agave 4.3 gebunden wurde und nicht an die für SIMD-0525 verwendeten Slot-Zeit-Feature-Gates.
Alpenglow ging früher im Jahr 2026 in die Community-Validator-Tests über, sodass Betreiber das Konsensdesign auf einem Testcluster vor dem Einsatz im Mainnet ausführen konnten. Anza hat das System als die größte Konsensänderung in der Geschichte von Solana bezeichnet.
Für SIMD-0525 bleibt das Netzwerk auf der 250-ms-Stufe, bis die Entwickler das endgültige Feature Gate aktivieren. Die 200-ms-Konfiguration würde einen Rollout abschließen, der bei 400 ms begann und über 350 ms, 300 ms und 250 ms verlief, während bei jedem Schritt die Ressourcenlimits reduziert wurden.
