Solana (SOL) hat am Freitag die Slot-Zeit im Mainnet auf 350 Millisekunden reduziert – die erste Verkürzung seit dem Start des Netzwerks.
Wichtigste Punkte:
- Die angestrebte Slot-Zeit im Solana-Mainnet sank von 400 auf 350 Millisekunden und gilt seit Epoche 1020.
- Die Anpassung ist der erste von vier geplanten Schritten à 50 Millisekunden hin zu einem Zielwert von 200 Millisekunden.
- Die Compute-Limits pro Slot werden proportional gesenkt, sodass das theoretische Maximum bei rund 250 Millionen Einheiten pro Sekunde bleibt.
Solana senkt Slot-Zeit auf 350 Millisekunden
Jacob Creech, Vice President Technology bei der Solana Foundation, machte die Umstellung mit einem Beitrag auf X öffentlich. „Wir sind in einer neuen Ära von 350 ms“, schrieb er und nannte 300 Millisekunden als nächsten Meilenstein. Ein Tracker der Foundation zeigte kurz darauf durchschnittliche Slot-Zeiten von 360 Millisekunden – ein Rückgang gegenüber den 400 Millisekunden, die im Protokoll seit Genesis verankert waren.
Das entsprechende Feature-Konto wurde bei Slot 440.208.000 aktiviert, dem ersten Slot der Epoche 1019. Wegen einer Verzögerung um eine Epoche blieb das Netzwerk jedoch bis zum Start von Epoche 1020 beim bisherigen Ziel von 400 Millisekunden.
Anza, das Research-Unternehmen hinter dem Agave-Validator-Client, lieferte die Slot-Reduktion im Rahmen des Agave-v4.2-Release aus, das mehrere weitere Protokolländerungen umfasst.
Auch interessant: Binance bietet 300 Mio. Nutzern eine neue Möglichkeit, KI-Agenten für sie handeln zu lassen
Anza- und Helius-Manager über mögliche Durchsatzgewinne
Der zugrunde liegende Vorschlag SIMD-0525 sieht drei weitere Kürzungen um jeweils 50 Millisekunden vor, bis das Netzwerk den Zielwert von 200 Millisekunden erreicht. Jede Stufe wird über ein eigenes Feature-Gate aktiviert. Gleichzeitig werden in dem Dokument die Work-Limits pro Slot in jeder Stufe nach unten angepasst, sodass Validatoren pro Sekunde nicht mehr Rechenlast verarbeiten müssen als heute.
Brennan Watt, CEO von Anza, bestätigte, dass die Slot-Zeiten im Testnet bereits 182 Millisekunden erreicht haben, wobei Explorer-Daten einen Durchschnitt von 193 Millisekunden in der vorangegangenen Stunde zeigen. Dort erfolgt jede Reduktion ungefähr alle zwei Epochen.
Mert Mumtaz, CEO von Helius, erklärte in einem Podcast, dass kürzere Slots in Kombination mit einem höheren Block-Limit den Netzwerkdurchsatz kurzfristig vervierfachen könnten. Das maximale Compute-Limit pro Block sinkt bei 350 Millisekunden auf 87,5 Millionen Einheiten – ein Rückgang gegenüber der Obergrenze von 100 Millionen Einheiten, die das Mainnet im Juli übernommen hatte. Das theoretische Maximum bleibt damit bei rund 250 Millionen Einheiten pro Sekunde.
Validatoren müssen engere Zeitfenster managen
Blockführer behalten weiterhin vier aufeinanderfolgende Slots, ihr Zeitfenster schrumpft damit allerdings von 1,6 auf 1,4 Sekunden. Das verschärft die Anforderungen an Übergabe und Propagation in einem Validator-Set, das bereits durch schnellere Blockproduktion stark gefordert ist.
Zusätzliche Herausforderungen ergeben sich auf der Software-Seite außerhalb der Chain: Manche Client-Konstanten, Explorer und Indexer behandeln die 400-Millisekunden-Slot-Zeit weiterhin als festen Wert, statt sie dynamisch aus dem Cluster zu lesen.
Die Foundation veröffentlichte den gestaffelten Fahrplan im Juni und legte für jede der vier Reduktionsstufen ein separates Gate an. So können Betreiber die Sequenz pausieren, falls die Block-Skip-Rate über das von den Validatoren akzeptierte Niveau steigt. Das Testnet machte am 5. August den ersten Schritt auf 350 Millisekunden. Dort läuft das Netzwerk inzwischen effektiv auf ein Ziel von 200 Millisekunden, während das Devnet bei 300 Millisekunden liegt – mit einem aktivierten 250-Millisekunden-Gate, das jedoch noch nicht greift.
Lesen Sie weiter: MANTRA fällt nach Angriffsversuch mit eingefrorenen Ein- und Auszahlungen um 10 %
