Solana steht vor der ersten Verkürzung seiner Blockzeit seit dem Mainnet-Start: Ab Epoche 1020 sinkt die Zielslotzeit von 400 auf 350 Millisekunden. Der Schritt ist Teil eines mehrstufigen Fahrplans, der die Netzwerklatenz schrittweise bis auf 200 Millisekunden senken soll, ohne dabei die Rechenlast pro Sekunde zu erhöhen.
Für Anleger ist der Zeitpunkt relevant, weil SOL aktuell ohnehin im Fokus steht: Die Kryptowährung notiert bei 94,23 US-Dollar und legte laut CryptoSlate innerhalb von 24 Stunden um 4,52 Prozent zu.
Der Auslöser: Epoche 1020 bringt 350ms auf das Mainnet
Das Feature für die 350-Millisekunden-Slots wurde bereits zu Beginn von Epoche 1019 aktiviert, greift aber wegen einer eingebauten Verzögerung von einer Epoche erst in Epoche 1020. Bis dahin bleibt das Mainnet technisch bei einem effektiven Ziel von 400 Millisekunden, wie aus dem zugrunde liegenden Verbesserungsvorschlag SIMD-0525 hervorgeht.
Das Aktivierungs-Slot lag bei 440.208.000, dem ersten Slot der Epoche 1019. Der Vorschlag selbst trägt noch den Status Entwurf – die Feature-Aktivierung zeigt also, dass eine konkrete Netzwerkänderung durch das System läuft, nicht dass das gesamte 200ms-Design bereits final beschlossen ist.
Die Zielzeiten sind zudem von der tatsächlich beobachteten Blockproduktion, der Bestätigungslatenz und der wirtschaftlichen Finalität zu unterscheiden.
Warum die Compute-Grenze trotzdem stabil bleibt
Der eigentliche Kern des Vorschlags liegt in der Arithmetik: Kürzere Slots bedeuten automatisch weniger Rechenkapazität pro Block, wenn die Obergrenze nicht angepasst wird. SIMD-0525 skaliert deshalb die maximalen Compute Units (CUs) pro Block proportional mit – von 100 Millionen CUs bei 400ms auf 87,5 Millionen bei 350ms, weiter bis auf 50 Millionen bei 200ms.
Rechnet man das auf die Sekunde um, bleibt die theoretische Obergrenze bei allen Stufen nahezu konstant – rund 250 Millionen CUs pro Sekunde. Solana schafft damit mehr Gelegenheiten zur Transaktions-Einplanung, ohne den Validatoren stillschweigend mehr Arbeit pro Sekunde aufzubürden.
| Zielslotzeit | Beispielhafte maximale CUs pro Block | Theoretische CUs pro Sekunde | Leader-Fenster mit vier Slots |
|---|---|---|---|
| 400ms | 100 Millionen | 250 Millionen | 1,6 Sekunden |
| 350ms | 87,5 Millionen | 250 Millionen | 1,4 Sekunden |
| 300ms | 75 Millionen | 250 Millionen | 1,2 Sekunden |
| 250ms | 62,5 Millionen | 250 Millionen | 1,0 Sekunde |
| 200ms | 50 Millionen | 250 Millionen | 0,8 Sekunden |
Diese Obergrenze ist keine Prognose für den Transaktionsdurchsatz. Die tatsächliche Nutzung hängt von Arbeitslast und Netzwerkbedingungen ab; die 100 Millionen CUs dienen als Beispiel für die maximale Blockkapazität und sind keine allgemeingültige Basis für jeden Grenzwert.
Engere Zeitfenster für Validatoren
Die Verkürzung wirkt sich auch auf die sogenannten Leader-Fenster aus. Da jedem Leader weiterhin vier aufeinanderfolgende Slots zugewiesen werden, schrumpft das nominale Zeitfenster von 1,6 Sekunden bei 400ms auf 1,4 Sekunden bei 350ms – und perspektivisch auf 0,8 Sekunden bei 200ms.
Das lässt Validatoren weniger Zeit, den vorherigen Block zu empfangen, zu replizieren, darauf aufzubauen und Votes zu platzieren, bevor das Netzwerk weiterzieht. Vote- und Gossip-Ereignisse finden innerhalb derselben Zeitspanne häufiger statt, während Block-Packing und Turbine kleinere, an die Slotzeit angepasste Budgets einhalten müssen.
Auch die Epochendauer verkürzt sich dadurch: Bei unveränderten 432.000 Slots pro Epoche sinkt die nominale Dauer von rund 48 Stunden bei 400ms auf 42 Stunden bei 350ms und auf 24 Stunden bei vollständig umgesetztem 200ms-Ziel.
Testnet ist bereits weiter, Devnet folgt
Während das Mainnet gerade erst auf 350ms umstellt, läuft das Testnet laut CryptoSlate bereits mit einem effektiven Ziel von 200 Millisekunden. Das Devnet befindet sich bei 300ms und hat das nächste Gate auf 250ms bereits aktiviert, ohne es wirksam werden zu lassen.
Die weitere Umsetzung ist gestaffelt angelegt. Jede Stufe verbindet das Ziel geringerer Latenz mit der Frage, ob Validatoren und die umgebende Infrastruktur die engeren Abstimmungs- und Weitergabezeiten bewältigen können.
Was das für SOL-Anleger bedeutet
Für die technische Entwicklung bedeutet die Umstellung vor allem häufigere Gelegenheiten zur Aufnahme von Transaktionen bei einer ungefähr konstanten theoretischen Compute-Obergrenze pro Sekunde. Ob sich dies in der Praxis in höherem Durchsatz niederschlägt, hängt jedoch von Arbeitslast und Netzwerkbedingungen ab.
Mit jeder weiteren Verkürzung werden zugleich Anwendungen und Dienste außerhalb der Validatoren wichtiger. SDKs und Off-Chain-Annahmen können noch an einer Slotzeit von 400 Millisekunden ausgerichtet sein. Anwendungen, RPC-Clients und Explorer, die aus Slotabständen auf verstrichene Zeit oder Aktualität schließen, müssen sich daher an den effektiven Timing-Parametern des Clusters orientieren.
Für Mainnet ist zunächst die Umstellung auf 350 Millisekunden in Epoche 1020 entscheidend, nicht ein unmittelbarer Sprung auf 200 Millisekunden. Der Erfolg der weiteren Stufen hängt davon ab, ob Validatoren und die begleitende Infrastruktur ihre Koordinationsspielräume bei kürzeren Zeitfenstern erhalten können.
Zuletzt aktualisiert am 22. August 2026
Fragen und Antworten
Sie haben eine Frage? Unser Experten-Panel beantwortet gerne Ihre Fragen.