Solana nähert sich nach jüngstem Geschwindigkeits-Upgrade 200-ms-Slots

Laut Blockchain-Daten ging die neue Einstellung am 18. September live und bringt Solana auf vier angestrebte Slots pro Sekunde, verglichen mit rund 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 Endziel von 200 ms zu reduzieren.

Ein Slot ist der Zeitraum, in dem ein designierter Validator einen Block erzeugen kann. Eine Verkürzung dieses Zeitraums gibt Wallets, Börsen und Handelsanwendungen häufigere Aktualisierungen ü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 nominale 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 senkte, wie crypto.news zuvor berichtete.

SIMD-0525 teilte den Prozess in vier Stufen bei 350 ms, 300 ms, 250 ms und 200 ms auf, anstatt direkt zum Endziel überzugehen. Jede Reduzierung erfordert eine separate Feature-Aktivierung, sodass Entwickler und Validator-Betreiber die Netzwerkleistung bewerten können, bevor sie fortfahren.

Bei 250 ms treffen vier Slot-Gelegenheiten pro Sekunde ein. Die kürzeren Intervalle können Anwendungen eine aktuellere Sicht auf Transaktionen und den Netzwerkzustand geben, während die Blockproduktion früher von einem Validator zum nächsten übergeht.

Oracle-basierte Märkte und automatisierte Market Maker gehören zu den Anwendungen, die von dem Vorschlag abgedeckt werden, da ihre Operationen vom Alter der Onchain-Daten abhängen können. Ein kürzeres Intervall reduziert die Zeit zwischen Netzwerkaktualisierungen, während Benutzer Transaktionsstatusänderungen früher sehen können.

Bei Swaps kann das kürzere Timing den Zeitraum zwischen dem Einreichen einer Transaktion und dem Erreichen des Netzwerks verkürzen. Der zugrunde liegende Vorschlag nennt schnellere Bestätigungen und häufigere Aktualisierungen als Vorteile der Reduzierung der Slot-Dauer.

Die Änderung erhöht die rohe Transaktionskapazität von Solana nicht um fast 17 %.

Unter SIMD-0525 werden Ressourcenlimits proportional zur Slot-Dauer reduziert. Über einen bestimmten Zeitraum werden mehr Slots erzeugt, aber jeder Slot darf weniger Berechnung und Daten tragen, wodurch die Menge an Arbeit, die das Netzwerk in Echtzeit verarbeiten kann, ungefähr gleich bleibt.

Bei der im Vorschlag verwendeten Basis von 60 Millionen Compute-Einheiten sinkt das Limit pro Slot, wenn die Uhr schneller wird. Die 250-ms-Konfiguration entspricht einem Limit von 37,5 Millionen Compute-Einheiten, während die geplante 200-ms-Stufe es auf 30 Millionen senken würde.

Schnellere Blöcke ändern die Infrastrukturanforderungen von Solana

Infrastrukturanbieter haben jetzt mehr einzelne Blöcke zu verarbeiten und zu speichern, obwohl die Obergrenze der Verarbeitung nach Wanduhrzeit weitgehend unverändert bleibt.

Anwendungen, die die verstrichene Zeit durch Multiplikation von Slot-Nummern mit einer festen Slot-Dauer berechnen, müssen möglicherweise die schnellere Uhr berücksichtigen. Blockhashes laufen in Echtzeit früher ab, da Slots schneller voranschreiten, was weniger Zeit für Transaktionsprozesse mit Offline-Signierung oder verzögerten menschlichen Genehmigungen lässt.

Das Epochen-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 300-ms-Ziel dauerte eine Epoche ungefähr 36 Stunden. Die 250-ms-Einstellung verkürzt die erwartete Dauer auf rund 30 Stunden. Ein Wechsel zum endgültigen 200-ms-Ziel würde sie auf ungefähr 24 Stunden reduzieren.

Die gestaffelten Slot-Reduzierungen von Solana sind Teil der Agave-4.2-Einführung. Die Client-Veröffentlichung begann im August mit der Aktivierung mehrerer Netzwerkänderungen, darunter niedrigere Onchain-Speichermiete, größere Transaktionen und der Weg zu 200-ms-Slots.

Das gestaffelte Design enthält eine Sicherheitsmaßnahme, die an Block-Skip-Raten gebunden ist. Der Fortschritt zur nächsten Slot-Einstellung kann gestoppt werden, wenn die Skip-Raten über das von den Entwicklern als akzeptabel angesehene Niveau steigen, was Validatoren Zeit gibt, 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, das die maximale serialisierte Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes erhöht. 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-Null-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 die maximale Größe einer Transaktion nicht automatisch erhöhen.

Solana hat die Änderungen unabhängig über Feature-Gates aktiviert. Die Struktur ermöglicht es, dass ein Upgrade fortgesetzt wird, ohne dass die anderen in Agave 4.2 enthaltenen Features gleichzeitig aktiviert werden müssen.

Solana zielt weiterhin auf 200-ms-Slots

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 Leader-Fenster von vier Slots für einen Validator würde folglich auf ungefähr 800 ms sinken. Die Epochendauer würde von rund 30 Stunden unter der aktuellen 250-ms-Einstellung auf ungefähr 24 Stunden sinken.

Solana-Entwickler haben keinen Mainnet-Aktivierungstermin für die letzte Reduzierung genannt. 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 geplanter Konsens-Neugestaltung. Alpenglow soll TowerBFT durch ein Abstimmungssystem namens Votor ersetzen und Onchain-Vote-Transaktionen aus dem Kernkonsensprozess des Netzwerks entfernen.

Das Alpenglow-Konsens-Upgrade zielt auf eine Finalität von ungefähr 150 ms ab. Sein Code wurde zum Testen aufgenommen, während die Mainnet-Bereitstellung an Agave 4.3 gebunden ist und nicht an die Slot-Zeit-Feature-Gates, die für SIMD-0525 verwendet werden.

Alpenglow trat Anfang 2026 in das Community-Validator-Testen ein, sodass Betreiber das Konsensdesign auf einem Testcluster ausführen können, bevor es im Mainnet bereitgestellt wird. Anza hat das System als die größte Konsensänderung in der Geschichte von Solana beschrieben.

Für SIMD-0525 bleibt das Netzwerk auf der 250-ms-Stufe, bis Entwickler das letzte Feature-Gate aktivieren. Die 200-ms-Konfiguration würde eine Einführung abschließen, die bei 400 ms begann und über 350 ms, 300 ms und 250 ms verlief, während die Ressourcenlimits bei jedem Schritt reduziert wurden.