Solana bereitet auf dem Mainnet den nächsten Schritt zu kürzeren Slot-Zeiten vor: Ab Epoch 1020 soll das Ziel von bisher 400 Millisekunden auf 350 Millisekunden sinken. Damit will das Netzwerk Blöcke schneller takten. Gleichzeitig senkt Solana aber die Rechenlast, die pro Block erlaubt ist. Der Grund: Die höhere Geschwindigkeit soll nicht dazu führen, dass Validatoren pro Sekunde plötzlich deutlich mehr Arbeit stemmen müssen und das Netzwerk dadurch unter Druck gerät.
Schnelleres Mainnet, aber mit eingebauter Bremse
Die zugehörige Funktion wurde bereits zum Start von Epoch 1019 aktiviert. Wegen einer Verzögerung um eine Epoche bleiben die bisherigen Parameter jedoch zunächst bestehen. Erst in Epoch 1020 wird das Mainnet effektiv mit dem neuen 350-ms-Ziel arbeiten.
Wichtig ist dabei: Solana verkürzt zwar die angestrebte Zeit pro Slot, erhöht aber nicht automatisch das Rechenbudget pro Sekunde. Stattdessen wird das Limit pro Block entsprechend reduziert. So soll verhindert werden, dass die Beschleunigung das Netzwerk überlastet.
Andere Cluster sind bereits weiter. Auf dem Testnet liegt das effektive Ziel schon bei 200 ms, auf dem Devnet bei 300 ms. Dort wurde sogar schon die nächste Stufe in Richtung 250 ms vorbereitet, ohne dass sie bereits wirksam ist. Das zeigt, wie schnell die Umsetzung der verschiedenen Ausbaustufen voranschreitet.
Trotzdem ist Vorsicht bei der Einordnung geboten: Der zugrunde liegende Vorschlag SIMD-0525 gilt weiterhin als Entwurf. Die Aktivierung einer Funktion bedeutet also nicht, dass das komplette Modell bis 200 ms bereits endgültiger Standard ist. Außerdem handelt es sich um Zielwerte für die Slot-Zeit – nicht um eine Garantie für reale Blockproduktion, Bestätigungszeiten oder wirtschaftliche Finalität.
Warum Solana die Compute-Limits pro Block senkt
Der Kern des Konzepts ist einfach: Wenn Slots kürzer werden, muss auch weniger Arbeit in jeden einzelnen Slot passen. Nur so bleibt die theoretische Gesamtlast pro Sekunde ungefähr konstant.
Solana hatte für das Mainnet bereits ein maximales Block-Limit von 100 Millionen Compute Units bei 400 ms aktiviert. Laut SIMD-0525 ergeben sich daraus bei kürzeren Slot-Zeiten die folgenden Beispielwerte:
400 ms: 100 Millionen CUs pro Block
350 ms: 87,5 Millionen CUs pro Block
300 ms: 75 Millionen CUs pro Block
250 ms: 62,5 Millionen CUs pro Block
200 ms: 50 Millionen CUs pro Block
In allen Fällen bleibt die theoretische Obergrenze bei ungefähr 250 Millionen Compute Units pro Sekunde. Das heißt: Obwohl Blöcke häufiger produziert werden, steigt die maximale Rechenarbeit pro Sekunde in diesem Beispiel nicht an.
Das ist ein wichtiger Unterschied. Diese Werte sind keine direkte Vorhersage für den tatsächlichen Durchsatz in Transaktionen pro Sekunde. Wie viel das Netzwerk real verarbeitet, hängt weiter von der Art der Transaktionen, der Auslastung und den Netzwerkbedingungen ab.
Neben dem Compute-Limit pro Block sollen auch weitere Budgets pro Slot reduziert werden, etwa für Account-Schreibvorgänge, Votes, Datenzuweisungen und Shreds. Ziel ist es, mehr Einschubmöglichkeiten für Transaktionen zu schaffen, ohne die Infrastruktur im Hintergrund unbemerkt mit doppelt so vielen Ressourcenanforderungen pro Sekunde zu belasten.
Mehr Tempo erhöht den Druck auf Validatoren und Infrastruktur
Mit kürzeren Slots schrumpft auch das Zeitfenster, in dem ein Leader aufeinanderfolgende Slots kontrolliert. Solana bleibt beim Modell von vier aufeinanderfolgenden Slots pro Leader. Bei 400 ms ergibt das ein Fenster von rund 1,6 Sekunden. Bei 200 ms wären es nur noch 0,8 Sekunden.
Das klingt nach einem kleinen Detail, hat aber große Auswirkungen. Validatoren haben dann weniger Zeit, den vorherigen Block zu empfangen, ihn zu verarbeiten, darauf aufzubauen und Votes rechtzeitig zu verbreiten. Auch Weitergabe und Abstimmung im Netzwerk müssen häufiger im gleichen Zeitfenster stattfinden.
Genau darin liegt der eigentliche Praxistest: Solana will die Latenz senken, ohne dass die Koordination zwischen Validatoren leidet. Jede neue Stufe mit kürzerer Slot-Zeit ist deshalb auch ein Test dafür, ob das Ökosystem mit dem engeren Takt stabil arbeiten kann.
Zusätzlich werden auch die Epochen in realer Zeit kürzer. Die Zahl von 432.000 Slots pro Epoche bleibt gleich, aber ihre Dauer sinkt mit der Slot-Zeit: von etwa 48 Stunden bei 400 ms auf rund 24 Stunden bei 200 ms. Der Slot-Zähler ändert sich also nicht, wohl aber seine Bedeutung in echter Zeit.
Das kann auch Software außerhalb des Validator-Netzwerks treffen. Manche SDKs, RPC-Dienste, Explorer oder andere Off-Chain-Anwendungen rechnen intern noch mit festen 400 ms pro Slot. Wenn ein Dienst Zeitspannen einfach aus der Slot-Anzahl ableitet, kann er nach einer Umstellung falsche Werte anzeigen. Langfristig soll Software diese Parameter deshalb direkt aus dem Cluster beziehen, statt auf feste Konstanten zu vertrauen.
Unterm Strich ist die nächste Änderung für das Mainnet klar: In Epoch 1020 kommt der Wechsel auf 350 ms, nicht sofort der Sprung auf 200 ms. Solana will das Netzwerk schneller machen, ohne die Rechenlast pro Sekunde ausufern zu lassen. Ob das in jeder weiteren Stufe stabil funktioniert, hängt vor allem davon ab, wie gut Validatoren und die umgebende Infrastruktur mit den engeren Zeitfenstern zurechtkommen.
