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.
Was passiert ist
Brennan Watt von Anza hat am 1. Mai 2026 den Vorschlag SIMD-0525 “Reduce Slot Times” im offiziellen Solana-Improvement-Documents-Repository veröffentlicht. Der Vorschlag 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:
reduce_slot_time_to_350msreduce_slot_time_to_300msreduce_slot_time_to_250msreduce_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 Vorschlag
| Ziel-Slot-Zeit | Slots pro Jahr | Epoche-Dauer | Leader-Window | Max Block-CUs |
|---|---|---|---|---|
| 400 ms (aktuell) | 78.892.314 | 48 h | 1,6 s | 60.000.000 |
| 350 ms | 90.162.645 | 42 h | 1,4 s | 52.500.000 |
| 300 ms | 105.189.753 | 36 h | 1,2 s | 45.000.000 |
| 250 ms | 126.227.703 | 30 h | 1,0 s | 37.500.000 |
| 200 ms | 157.784.629 | 24 h | 0,8 s | 30.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
Der SIMD-0525-Vorschlag 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-Vorschlag 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-sdkstatisch 400 ms annimmt. Apps, die400ms * slotsals 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 Vorschlag nicht genannt.
Beobachter verfolgen Roll-out-Schritte typischerweise über Validator-Client-Releases (Agave, Firedancer) und über das SIMD-Repository auf GitHub.
Keine Anlageberatung. Dieser Artikel beschreibt eine technische Protokoll-Spezifikation im Draft-Stadium. Implementation und Aktivierung sind nicht garantiert.
Quellen
- SIMD-0525 “Reduce Slot Times” — Volltext im Repository (Brennan Watt, Anza, 1. Mai 2026, Status Draft)
- Agave exploratorische Implementation für Halving Slot Times (PR #10740)
- Agave exploratorische Implementation für Leader-Span-Änderung (PR #12154)
- Solana Improvement Documents Repository
- SOLANA·HUB-Pillar: Alpenglow erklärt
- SOLANA·HUB-Pillar: Firedancer und Frankendancer
- SOLANA·HUB-Glossar: SIMD (Solana Improvement Document), Compute Unit (CU)