Was genau ändert sich?
Solana verkürzt die Ziel-Blockproduktionszeit (Slot Time) im Mainnet von 400 Millisekunden auf 350 Millisekunden. Laut dem Bericht von CryptoSlate wurde diese Änderung zu Beginn der Epoche 1019 aktiviert, doch wegen der sogenannten Verzögerung um eine Epoche (One-Epoch Delay) behält das Netzwerk die bestehenden Parameter bei, und das neue 350-ms-Ziel wird faktisch erst ab Epoche 1020 wirksam.
Zur Klärung der Begriffe: Slot Time ist das Zielintervall, in dem ein Block produziert werden soll. Eine Epoche ist ein längeres Zeitfenster, das aus vielen Slots besteht und nach dessen Ablauf bestimmte Parameteränderungen angewendet werden. Compute Units (Recheneinheiten) sind das Maß dafür, wie viel Rechenaufwand ein Block enthalten darf.
Warum wird gleichzeitig das Rechenlimit pro Block gesenkt?
Das ist der Kern der ganzen Geschichte. Laut CryptoSlate erhalten Blöcke zwar ein kürzeres Zielintervall für die Produktion, aber kein größeres erlaubtes Rechenvolumen pro Sekunde. In der Praxis bedeutet das: Wenn Blöcke häufiger produziert werden, muss jeder einzelne Block "leichter" sein, damit die Gesamtbelastung von Netzwerk und Validatoren pro Zeiteinheit in etwa konstant bleibt.
Die Logik ist einfach: Eine reine Beschleunigung der Blöcke ohne Anpassung des Rechenlimits würde mehr Rechenaufwand pro Sekunde bedeuten, was die Validatoren belasten und die Stabilität des Netzwerks gefährden könnte. Die Senkung des Limits pro Block ist also eine Absicherung, kein Nebeneffekt.
Wie weit sind die Testnetze dabei?
Laut CryptoSlate ist der Rollout andernorts weiter als im Mainnet:
| Netzwerk | Stand der Ziel-Blockzeit |
|---|---|
| Mainnet | Übergang von 400 ms auf 350 ms (faktisch ab Epoche 1020) |
| Testnet | effektives Ziel 200 ms |
| Devnet | Ziel 300 ms, aktivierte Schwelle 250 ms, aber noch nicht wirksam |
Testnet und Devnet dienen also als Vorstufe, in der aggressivere Werte getestet werden, bevor sie in den Mainnet gelangen.
Woher stammt diese Änderung?
CryptoSlate verweist auf den Solana-Changelog vom 6. August, in dem diese Parameter beschrieben sind. Die schrittweise Verkürzung der Blockzeit ist Teil einer breiteren langfristigen Bemühung von Solana um eine geringere Netzwerklatenz.
Was ist bislang unklar?
Aus der verfügbaren Quelle geht weder das genaue Kalenderdatum hervor, wann Epoche 1020 eintritt, noch der konkrete Zahlenwert, um wie viel genau das Rechenlimit pro Block gesenkt wird. Ebenso wenig ist aus dieser Quelle belegt, welche reale Auswirkung die Änderung auf die Transaktionslatenz, die Gebühren oder die Netzwerkstabilität für Endnutzer haben wird. Das wird sich erst am Verhalten des Mainnets nach Epoche 1020 zeigen.
Worauf sollte man bei dieser Art von Änderungen achten?
Bei Anpassungen von Blockchain-Parametern auf Protokollebene lohnt es sich, drei Dinge zu beobachten: ob die Änderung tatsächlich in der angekündigten Epoche aktiviert wird, ob es zu ungeplanten Ausfällen oder einer Verlangsamung der Blockproduktion kommt und ob sich der Durchsatz (Anzahl der Transaktionen pro Sekunde) real verändert oder stabil bleibt. Gerade weil Solana hier den Rechenaufwand pro Sekunde bewusst konstant hält, sind die zentralen zu überprüfenden Metriken eher Latenz und Stabilität als der reine Durchsatz.
charliedesk hält diese Änderung fest, um sie später mit dem vergleichen zu können, was auf dem Netzwerk nach Epoche 1020 tatsächlich passiert.