Was passiert gerade mit Solana?
Das Solana-Netzwerk schließt die schrittweise Beschleunigung der Blockerstellung ab. Ziel ist es, neue Blöcke doppelt so häufig wie bisher zu produzieren, was zu sogenannten 200-Millisekunden-Slots führt. Ein Slot ist das Zeitfenster, in dem ein bestimmter Validator (Leader) das Recht hat, einen Block zu erstellen.
Laut CoinDesk handelt es sich um einen siebenwöchigen Prozess, dessen letzter Schritt näher rückt. The Defiant berichtet, dass die finale Reduzierung auf 200-Millisekunden-Slots geplant ist. Das genaue Datum für den Start des letzten Schritts unterscheidet sich in den geprüften Quellen in Details, weshalb wir es als Punkt belassen, den man beobachten muss.
Warum werden die Limits pro Block verkleinert?
Hier ist ein wichtiges Detail, das in Schlagzeilen leicht verloren geht. Laut The Defiant werden zusammen mit der Verkürzung der Slots auch die Rechenlimits pro Block verkleinert. Mit anderen Worten: Ein einzelner Block verträgt weniger Berechnungen, aber da doppelt so viele Blöcke entstehen, sollte die Gesamtkapazität des Netzwerks erhalten bleiben.
Es handelt sich also nicht automatisch um eine Verdopplung des Durchsatzes. Es geht um eine feinere Verteilung derselben Kapazität auf eine größere Anzahl kürzerer Blöcke.
Was bedeutet das für Validatoren?
Die Verkürzung der Slots hat direkte Auswirkungen auf die Node-Betreiber (Validatoren). Laut CoinDesk und The Defiant sieht die Realität wie folgt aus:
| Bereich | Auswirkung |
|---|---|
| Produktionsfenster | Kürzer, also weniger Zeit für die Zusammenstellung eines Blocks |
| Abstimmung | Häufiger, da sie durch die höhere Blockfrequenz erforderlich wird |
| Kosten | Höhere Betriebskosten und strengere technische Anforderungen |
CoinDesk weist ausdrücklich darauf hin, dass Validatoren mit höheren Kosten und engeren Betriebsfenstern konfrontiert sind. Für kleinere oder schlechter ausgestattete Betreiber kann das Druck auf die Infrastruktur bedeuten.
Wie passt der geografische Vorschlag zur Beschleunigung hier hinein?
Parallel dazu taucht ein Vorschlag auf, der die Übergabe zwischen Validatoren weiter beschleunigen möchte. Laut CryptoSlate wurde er von den Forschern Roger Wattenhofer und Quentin Kniep vorgelegt. Die Idee ist einfach: Validatoren, die physisch nah beieinander sind, nacheinander anzuordnen, um die Verzögerung bei der Übergabe (Handover) zwischen aufeinanderfolgenden Leader-Fenstern zu verkürzen.
Ein Leader-Fenster ist der zugewiesene Abschnitt, in dem der jeweilige Validator Blöcke produziert. Die Autoren haben laut CryptoSlate in einer Simulation die durchschnittliche Übergabeverzögerung zwischen ehrlichen Validatoren von 36,2 Millisekunden auf 17,0 Millisekunden gesenkt, und zwar ohne dass irgendein Validator mehr Leader-Fenster erhält.
Sinn ist es, die Abhängigkeit der Geschwindigkeit vom Betrieb in der Nähe der größten Stake-Konzentrationen (Anteile) zu verringern.
Wo liegt der Haken beim geografischen Vorschlag?
Dies ist der Teil, bei dem Vorsicht geboten ist. CryptoSlate weist darauf hin, dass der Plan auf von den Validatoren selbst gemeldeten Standorten beruht. Dabei kann das Netzwerk diese physischen Standorte nicht überprüfen. In die Reihenfolge der Blockproduzenten fließt somit ein nicht überprüfbarer physischer Input ein, was eine potenzielle Schwachstelle ist, die man im Auge behalten muss.
Wichtige Unterscheidung: Die Verkürzung der Slots in Richtung 200 ms ist ein laufender Prozess des Netzwerks. Der geografische Vorschlag ist ein Vorschlag von Forschern, kein bestätigter Bestandteil der Umsetzung. Diese beiden Dinge sollten wir nicht verwechseln.
Was wissen wir noch nicht?
Die geprüften Quellen beschreiben weder das genaue Datum des finalen Schritts noch die konkreten Zahlenwerte der neuen Rechenlimits pro Block, noch ob und wann der geografische Vorschlag in die Praxis umgesetzt wird. All das bleibt offen.
Was man bei ähnlichen Upgrades beobachten sollte
Bei Netzwerkänderungen dieser Art ergibt es Sinn, harte Daten statt Versprechen zu beobachten: die reale Rate ausgelassener Slots (Skip Rate), die Stabilität des Netzwerks nach der Umsetzung, die Anzahl aktiver Validatoren (ob kürzere Fenster und höhere Kosten jemanden verdrängen) und ob die Gesamtkapazität nach der Verkleinerung der Limits pro Block tatsächlich erhalten geblieben ist.