SOLANA·HUB
EN
Infrastruktur

SIMD-0525: Anza schlägt schrittweise Reduktion der Solana-Slot-Zeit auf 200 ms vor

Das Mainnet-beta läuft seit der Grenze zu Epoche 1053 am 9. Oktober 2026 auf 200-ms-Slots. Anza hat die Umstellung bestätigt. Bei 200 ms gelten 50 Millionen CU pro Block.

SOLANA·HUB Redaktion
Quelle: Solana Improvement Documents

Was passiert ist

Brennan Watt von Anza hat am 1. Mai 2026 das Proposal SIMD-0525 “Reduce Slot Times” im offiziellen Solana-Improvement-Documents-Repository veröffentlicht. Das Proposal würde Solanas Ziel-Slot-Zeit in vier Schritten von 400 ms auf 200 ms reduzieren.

Status aktuell: Draft. Der SIMD ist im Repository veröffentlicht — die zugehörigen Feature-Gates sind noch mit dem Hinweis “TBD” markiert. Eine Mainnet-Aktivierung erfordert separate Validator-Voting-Schritte und steht noch aus.

Was vorgeschlagen wird

Vier separate Feature-Gates, jeweils mit Ein-Epoche-Aktivierungs-Verzögerung:

  1. reduce_slot_time_to_350ms
  2. reduce_slot_time_to_300ms
  3. reduce_slot_time_to_250ms
  4. reduce_slot_time_to_200ms

Pro Schritt bleibt Folgendes unverändert: 64 Ticks pro Slot, 4 Slots pro Leader-Window, 432.000 Slots pro Epoche. Was sich ändert: pro Slot werden die Limits proportional reduziert, damit der Pro-Sekunde-Durchsatz auf Validator-Ebene konstant bleibt.

Wichtige Eckwerte aus dem Proposal

Ziel-Slot-ZeitSlots pro JahrEpoche-DauerLeader-WindowMax Block-CUs
400 ms (aktuell)78.892.31448 h1,6 s60.000.000
350 ms90.162.64542 h1,4 s52.500.000
300 ms105.189.75336 h1,2 s45.000.000
250 ms126.227.70330 h1,0 s37.500.000
200 ms157.784.62924 h0,8 s30.000.000

Vote-Kosten bleiben pro Slot gleich — bei 200 ms verdoppelt sich also die Vote-Last pro Wallclock-Stunde. Anza nennt das im “Drawbacks”-Abschnitt explizit als gewollten Trade-off.

Was sich für Nutzer und Devs ändern würde

Nach vollständigem Roll-out auf 200 ms:

  • Confirmation-Latenz halbiert — Anza beschreibt das im Abschnitt “Motivation” als Hauptmotiv.
  • Leader-Window-Dauer halbiert auf 0,8 Sekunden. Reduziert das Worst-Case-Fenster, in dem ein einzelner Leader Transaktionen umordnen oder selektiv ausschließen könnte.
  • Feinere on-chain Zeit-Granularität für Oracle-Konsumenten und Market-Maker, die Freshness in Slots messen.
  • Vote-Kosten pro Wallclock-Tag verdoppeln sich (rund 1 SOL/Tag/Validator).
  • Gossip-Verkehr steigt proportional mit der Slot-Rate.

Bezug zu Alpenglow und zu SIMD-0286

Das SIMD-0525-Proposal respektiert die Interaktion mit Alpenglow: hashes_per_tick wird in Alpenglow-aktiven Banken nicht reduziert — Alpenglows Low-Power-Proof-of-History-Pfad behält sein aktives Hashing-Verhalten.

SIMD-0525 ist außerdem explizit kombinierbar mit dem SIMD-0286-Proposal zur Anhebung der Block-Compute-Units auf 100 Millionen. Falls beide aktiviert werden, würde der 200-ms-Block weiterhin 50 Millionen Compute Units fassen — bei doppelter Frequenz also den Gesamtdurchsatz pro Wallclock-Zeit gleich halten.

Backwards-Compatibility und Risiken

Anza markiert SIMD-0525 explizit als “consensus-breaking change” — Validatoren müssen das Feature implementieren, sonst riskieren sie Konsens-Bruch. Plus:

  • SDK-Konstanten werden mit Chain-Realität auseinanderlaufen, solange solana-sdk statisch 400 ms annimmt. Apps, die 400ms * slots als Wallclock-Konvertierung verwenden, müssen ihre Logik anpassen.
  • Blockhash-Expiry wird in Wallclock-Zeit kürzer, weil sie in Slots gezählt wird.
  • Staged Roll-out ist Teil der Sicherheits-Strategie: jede Stufe soll unter Produktionsbedingungen beobachtet werden, bevor die nächste aktiviert wird.

Einordnung

SIMD-0525 ist ein klassischer Performance-Iterationsschritt im Kontext der laufenden Solana-Verbesserungen (Alpenglow, Firedancer, P-Token, SIMD-0286). Die schrittweise Strategie reduziert das Risiko gegenüber einem direkten Sprung auf 200 ms. Konkrete Mainnet-Aktivierungs-Timeline wurde von Anza im Proposal nicht genannt.

Beobachter verfolgen Roll-out-Schritte typischerweise über Validator-Client-Releases (Agave, Firedancer) und über das SIMD-Repository auf GitHub.

Update (7. August 2026): erste Stufe läuft auf Devnet und Testnet

Aus dem Draft ist ein laufender Rollout geworden: Laut Solana-Changelog vom 6. August ist das erste Feature-Gate — 350-ms-Slots — auf Devnet und Testnet aktiv. Einen Tag später meldete Anza-CEO Brennan Watt Messwerte vom Testnet: acht Stunden durchgehend stabile 350-ms-Slots, höhere Vote-Durchsätze und eine unauffällige Skip-Rate von rund 0,85 Prozent; weitere Lasttests sind laut Watt geplant. Ein Mainnet-Termin für die erste Stufe steht weiterhin aus — der Rollout-Pfad läuft über die Agave-4.2-Feature-Aktivierungen.

Update (10. August 2026): 300-ms-Stufe auf dem Testnet

Der Rollout beschleunigt: Watt meldete am 10. August, dass auf dem Testnet bereits die zweite Stufe — 300-ms-Slots — aktiv ist. Die Epochen schrumpfen damit auf rund 36 Stunden (exakt der Wert aus der Proposal-Tabelle oben), was den Weg zur nächsten Stufe von 250 ms zusätzlich verkürzt, weil Feature-Gates pro Epoche aktiviert werden.

Update (18. August 2026): das Mainnet ist dran — 350 ms ab Epoche 1020

Die erste Stufe erreicht die Produktion: Laut Watt ist das 350-ms-Gate auf dem Mainnet aktiviert und wird mit Epoche 1020 effektiv — Feature-Gates durchlaufen den Takt pending → aktiviert → effektiv mit einer Epoche Verzögerung. Watts ausdrücklicher Hinweis für die Übergangsphase: SDK-Konstanten wie DEFAULT_MS_PER_SLOT sind noch nicht aktualisiert — Anwendungen, die Wallclock-Zeit aus fest kodierten 400 ms pro Slot ableiten (genau der Risiko-Punkt aus dem Backwards-Compatibility-Abschnitt oben), rechnen bis zur Anpassung falsch. Timing-sensitive Apps, Indexer und RPC-Konsumenten sollten die eigene Slot-Zeit-Annahme prüfen, bevor die Stufe greift.

Update (21. August 2026): der Countdown läuft — mit Live-Monitor und angepassten CU-Limits

Der Umschalt-Moment steht unmittelbar bevor: Solana hat unter solana.com/200ms einen Live-Monitor geschaltet, der die verbleibenden Slots auf dem 400-ms-Takt, gemessene Slot-Zeiten und die Client-Verteilung direkt vom Mainnet zeigt; zum Zeitpunkt dieses Updates zählt er die letzten Slots vor Epoche 1020 herunter. Es ist die erste Verkürzung der Slot-Zeit seit dem Mainnet-Start.

Eine wichtige Zahlen-Aktualisierung gegenüber der Proposal-Tabelle oben: Die Tabelle stammt aus dem Mai und rechnet mit der damaligen 60-Millionen-CU-Basis. Seit der Anhebung auf 100 Millionen CU gilt die proportionale Skalierung auf der neuen Basis — bei 350 ms sinkt das Block-Limit also auf rund 87,5 Millionen CU, sodass der Durchsatz pro Sekunde bei etwa 250 Millionen CU/s konstant bleibt. Das Prinzip der Tabelle gilt unverändert, die absoluten CU-Werte sind auf die 100M-Basis zu beziehen.

Update (25. August 2026): 350 ms sind Alltag — 300 ms stehen an, ab Epoche 1024

Der Umschalt-Moment ist vollzogen: Seit Epoche 1020 läuft das Mainnet auf 350-ms-Slots — die erste Verkürzung seit dem Netzstart ist damit produktiv. Und der Rollout hält Tempo: Laut Watt ist die zweite Stufe — 300 ms — bereits pending und wird mit Beginn von Epoche 1024 effektiv, nach aktuellem Epochen-Takt etwa drei Tage nach der Ankündigung (um den 28. August). Es bleibt beim Sicherheits-Mechanismus des Plans: Steigen die Skip-Raten auffällig, pausiert die Progression.

Update (18. September 2026): 300 ms seit Ende August, jetzt 250 ms

Zwei weitere Stufen sind durch. Die 300-ms-Stufe wurde laut offizieller Upgrade-Übersicht der Foundation am 25. August mit Epoche 1023 aktiviert und griff wie angekündigt ab Epoche 1024. Am 18. September folgte die 250-ms-Stufe: Der offizielle Solana-Changelog vom selben Tag führt sie unter den Mainnet-Feature-Gates. Die Upgrade-Übersicht der Foundation führte 250 ms zum Redaktionszeitpunkt noch als ausstehend; wir stützen uns auf den Changelog.

Was das konkret heißt: Das Netz zielt jetzt auf vier Slots pro Sekunde statt rund 3,3. Weil der Leader-Plan bei vier aufeinanderfolgenden Slots bleibt, schrumpft das Zeitfenster eines Leaders von 1,2 auf 1,0 Sekunden, und eine Epoche dauert rechnerisch rund 30 statt 36 Stunden. Die Gesamtkapazität bleibt dabei grob gleich, weil jeder Slot proportional weniger Arbeit trägt. Die letzte Stufe, 200 ms, ist auf Devnet und Testnet aktiv, hat für das Mainnet aber noch keinen Termin. Maßgeblich bleibt laut Foundation die Skip-Rate: Steigt sie zu stark, geht es nicht weiter.

Update (28. September 2026): Die Foundation legt Messdaten zu den Stufen vor

Die Solana Foundation hat ausgewertet, wie sich die Stufen von 400 auf 250 ms ausgewirkt haben. Die wichtigsten Befunde:

  • Skip-Rate: Sie blieb laut Foundation über alle Stufen stabil und niedrig und zeigt keinen Zusammenhang mit der kürzeren Slot-Zeit.
  • Vote-Latenz: Sie stieg mit jeder Stufe, am stärksten in Asien und Südamerika. Im Netzdurchschnitt stimmen Validatoren laut Foundation aber weiterhin für Slot N im Slot N+1 ab.
  • Verlorene Vote-Credits: Bei 250 ms verloren Validatoren, gleich gewichtet, 1,636 Prozent ihrer Vote-Credits, nach Stake gewichtet 0,0874 Prozent. Bei 400 ms lagen die Werte bei 2,105 und 0,262 Prozent. Validatoren mit mehr Stake verlieren laut Foundation anteilig weniger Credits als der Durchschnitt aller Validatoren. Vote-Credits bestimmen die Staking-Rewards.

Zur letzten Stufe schreibt die Foundation, die Diskussion um 200 ms sei inzwischen zunehmend eine philosophische und ökonomische Frage, keine rein technische. Ein Mainnet-Termin für 200 ms steht weiter nicht fest.

Update (9. Oktober 2026): Mainnet ist an Epoche 1053 auf 200-ms-Slots umgestellt

Das Mainnet-beta ist an der Grenze zu Epoche 1053 auf Slots von 200 Millisekunden umgestellt. Anza hat das am 9. Oktober 2026 bestätigt. Die Ziel-Slot-Zeit ist von 250 auf 200 Millisekunden gesunken. Anza fasst die Reihe als 400, 350, 300, 250 und 200 Millisekunden zusammen.

Anza schreibt, die Feature-Gates aus SIMD-0525 wirken eine Epoche nach ihrer Aktivierung. Der Post nennt dazu drei Epochen:

  • Epoche 1051: Aktivierung ausstehend
  • Epoche 1052: Feature aktiv
  • Epoche 1053: 200-ms-Slots gelten

Die Upgrade-Seite der Solana Foundation, Stand Oktober 2026, führt in der Spalte zur Slot-Zeit-Änderung „Scheduled for epoch 1052“. Bei den früheren Stufen nennt dieselbe Spalte die Epoche, in der die neue Slot-Zeit galt. Dieselbe Seite erklärt, dass ein Gate zu Beginn einer Epoche aktiviert und die neue Slot-Zeit erst an der folgenden Epochengrenze gilt. Das ist die Ein-Epochen-Verzögerung aus SIMD-0525. Die Slot-Zeit gilt seit dem ersten Slot von Epoche 1053. Anza hatte das am 7. Oktober angekündigt und am 9. Oktober bestätigt. Auf Devnet und Testnet läuft die 200-ms-Stufe laut Foundation bereits. Der wöchentliche Solana-Changelog vom 1. Oktober 2026 nennt diese Mainnet-Ankündigung nicht.

Seit der Umstellung liegen fünf Slots in einer Sekunde. Das Leader-Fenster liegt bei 0,8 Sekunden statt 1,0 Sekunden. Eine Epoche dauert rund 24 statt 30 Stunden. Der Blockhash bleibt 150 Blöcke gültig und läuft in der Uhrzeit kürzer ab. Die Foundation rechnet bei 200 ms mit etwa 30 Sekunden, bei 250 ms mit etwa 38 Sekunden. Jede Stufe bleibt an die Skip-Rate gebunden. Steigt sie zu stark, stoppt die Verkürzung. Den Schritt verfolgt die Foundation unter solana.com/200ms.

Zum Compute-Limit: CoinDesk nennt am 9. Oktober 30 Millionen Compute Units pro Block bei 200 ms und 37,5 Millionen bei 250 ms. Das sind die Tabellenwerte in SIMD-0525 auf der Basis von 60 Millionen. SIMD-0286 hat das Block-Limit am 29. Juli 2026 mit Epoche 1009 auf 100 Millionen angehoben, bevor die Slot-Zeit-Stufen begannen. SIMD-0525 verlangt, diese aktive 400-ms-Basis mit dem Verhältnis der Slot-Zeit zu skalieren. Für die 100-Millionen-Basis nennt das Proposal 62,5 Millionen Compute Units bei 250 ms und 50 Millionen bei 200 ms. Agave rechnet in cost_limits genauso: Der Tabellenwert wird mit 100 multipliziert und durch 60 geteilt, solange das 100-Millionen-Feature aktiv ist. Der Test in slot_params.rs erwartet dann 50 Millionen Compute Units bei 200 ms. Die Tabelle vom Mai weiter oben zeigt die unskalierte 60-Millionen-Basis. Auf dem Mainnet gilt die skalierte Grenze: 50 Millionen Compute Units pro Block.

Die 200-ms-Stufe ist auf dem Mainnet-beta seit der Grenze zu Epoche 1053 am 9. Oktober 2026 umgestellt.

Quellen

#simd-0525 #anza #performance #infrastruktur #alpenglow

Verwandte Artikel