SOLANA·HUB
EN
Infrastruktur In Entwicklung

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

Brennan Watt hat SIMD-0525 im Repository veröffentlicht — Solanas Slot-Zeit soll in vier Schritten von 400 ms auf 200 ms fallen. Status aktuell Draft, vier Feature-Gates definiert, Vote-Kosten verdoppeln sich am Ende des Rollouts.

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.

Keine Anlageberatung. Dieser Artikel beschreibt eine technische Protokoll-Spezifikation im laufenden Rollout. Implementation und Aktivierung auf dem Mainnet sind nicht garantiert.

Quellen

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

Verwandte Artikel