Solana hat den Abstand zwischen den Blöcken im Mainnet auf 350 Millisekunden verkürzt – das schnellste seit dem Start des Netzwerks gemessene Blockintervall –, während die Entwickler weiterhin an einer weiteren Reduzierung auf 200 Millisekunden arbeiten. Das Update wurde in Solanas Ankündigung auf X näher erläutert und folgt der im Mai erfolgten Genehmigung des technischen Vorschlags SIMD-0525 – einer Änderung, die in erster Linie die Netzwerklatenz verringern und nicht den Durchsatz erhöhen soll.

Wie die Slot-Verkürzung funktioniert

Solana unterteilt die Zeit in kurze Intervalle, die als Slots bezeichnet werden; während jedes Slots erzeugt ein bestimmter Validator, der sogenannte Leader, einen Block. Da jedem Leader vier aufeinanderfolgende Slots zugewiesen sind, verkürzt die Senkung der Slot-Zeit von 400 Millisekunden auf 350 Millisekunden das Leader-Rotationsintervall von 1,6 Sekunden auf 1,4 Sekunden. Sollte das Netzwerk das 200-Millisekunden-Ziel schließlich erreichen, würde jeder Leader vier Slots mit einer Gesamtdauer von 0,8 Sekunden kontrollieren.

Die kürzeren Slots sollen es ermöglichen, dass Transaktionen schneller durch das Netzwerk laufen, was die Nutzererfahrung für dezentrale Anwendungen, Zahlungen und dezentrale Finanzen verbessern könnte. Die Änderung erhöht jedoch nicht die Anzahl der Transaktionen, die in einen einzelnen Slot passen, sodass es sich im Wesentlichen um eine Verbesserung der Latenz und nicht um eine Erhöhung des Durchsatzes handelt.

Kürzere Leader-Rotationen könnten auch die Zeitspanne verkürzen, in der ein einzelner Validator die Blockproduktion kontrolliert. Solanas Entwickler argumentieren, dass dies Möglichkeiten für Validatoren einschränken könnte, Transaktionen gezielt zu verzögern oder selektiv zu filtern, was die Widerstandsfähigkeit des Netzwerks gegen Zensur verbessern könnte.

Ein vierstufiger Weg zu 200-Millisekunden-Blockzeiten

Solana plant, die Blockzeit in vier Schritten von jeweils 50 Millisekunden zu senken – von 400 ms auf 200 ms. Das Netzwerk wird für jede Reduzierung ein Feature Gate verwenden, damit die Entwickler die Stabilität überwachen können, bevor die nächste Stufe eingeleitet wird. Jede Änderung ist an eine anschließende Epoche von 432.000 Slots gebunden und kann verschoben werden, wenn sich die Netzwerkbedingungen verschlechtern, etwa wenn zu viele Blöcke übersprungen werden.

Solana hat Verbesserungen an Turbine, seinem System zur Blockweitergabe, und an Replay, das Validatoren zur Überprüfung und Abstimmung über Blöcke nutzen, als die Faktoren genannt, die die kürzeren Slots ermöglicht haben.

Getrennter Entwicklungspfad von Alpenglow

Die kürzeren Slot-Zeiten sind getrennt von Solanas Arbeit an Alpenglow zu sehen, einem neuen Konsensprotokoll, das eine schnellere Transaktionsfinalität zum Ziel hat. Derzeit benötigt Solana rund 12,8 Sekunden, um Finalität zu erreichen, während Alpenglow darauf ausgelegt ist, dies auf etwa 100 bis 150 Millisekunden zu verkürzen.

Anders als kürzere Slots, die den Abstand zwischen den Gelegenheiten zur Blockproduktion verringern, soll Alpenglow den Konsensprozess selbst verbessern. Der vorgeschlagene Entwurf soll zudem die Finalität aufrechterhalten, wenn 20 % der Validatoren böswillig handeln und weitere 20 % offline sind.

Da Änderungen der Slot-Zeit und Änderungen der Finalität unterschiedliche Teile des Netzwerks betreffen, werden sie auf getrennten Wegen entwickelt. Diese Unterscheidung ist für Nutzer und Entwickler relevant, die beobachten, wie sich Solanas Execution Layer und Konsens-Layer parallel weiterentwickeln, da die praktische Wirkung einer schnelleren Blockproduktion nicht mit einer schnelleren Finalität gleichzusetzen ist.

Zusammen genommen zeigen die Upgrades, dass die Arbeit daran fortgesetzt wird, das Netzwerk reaktionsschneller zu machen, ohne die grundlegende Einschränkung zu ändern, dass die Blockkapazität pro Slot gleich bleibt. Für Anwendungen, die auf schnelle Bestätigungen angewiesen sind, sind diese Timing-Details Teil davon, wie Solana seine Infrastruktur positioniert, während es sowohl bei der Leistung als auch bei der Belastbarkeit weiter iteriert.