Solana hat die Ziel-Slotzeit im Mainnet von 400 Millisekunden auf 350 Millisekunden reduziert. Dies ist der erste Schritt in einem Stufenplan, um sie schließlich auf 200 ms zu senken.

Die Änderung trat am Freitag um den Beginn der Epoche 1020 in Kraft und markiert das erste Mal seit dem Start des Netzwerks, dass Solana die Ziel-Slot-Dauer verkürzt hat. Die Zahl mag gering erscheinen, doch dahinter steckt ein erheblicher technischer Aufwand.

Ein Slot ist das Zeitfenster, in dem ein führender Validator einen Block erzeugen kann. Kürzere Slots ermöglichen eine häufigere Blockerzeugung, wodurch sich die Wartezeit für Benutzer und Anwendungen auf Bestätigungen verkürzt. Entscheidend ist die Latenz. Dieses Upgrade ist nicht darauf ausgelegt, den Transaktionsdurchsatz von Solana auf magische Weise zu verdoppeln.

Das Netzwerk geht die Treppe zu 200 ms.

Der Plan stammt aus SIMD-0525, einem Verbesserungsvorschlag für Solana, der vom Anza-Ingenieur Brennan Watt verfasst wurde. Anstatt direkt von 400 ms auf 200 ms zu springen, nutzt das Netzwerk vier separate, funktionsgesteuerte Stufen: 350 ms, 300 ms, 250 ms und schließlich 200 ms.

Solanas offizieller Vorschlag sieht weiterhin 64 Ticks pro Slot, vier Slots pro Leader-Fenster und 432,000 Slots pro Epoche vor. Die Anzahl der Slots bleibt gleich. Die von ihnen repräsentierte Zeitspanne in der realen Welt verkürzt sich jedoch.

• 400-ms-Slots: ungefähr 48-Stunden-Epochen und 1.6-Sekunden-Leader-Fenster
• 350-ms-Slots: ungefähr 42-Stunden-Epochen und 1.4-Sekunden-Leader-Fenster
• 300-ms-Slots: ungefähr 36-Stunden-Epochen und 1.2-Sekunden-Leader-Fenster
• 250-ms-Slots: ungefähr 30-Stunden-Epochen und 1.0-Sekunden-Leader-Fenster
• 200-ms-Slots: ungefähr 24-Stunden-Epochen und 0.8-Sekunden-Leader-Fenster

Die Einführung erfolgt bewusst vorsichtig. Jede Phase hat ihre eigene Funktionsprüfung, und Entwickler können vor der nächsten Reduzierung stoppen, falls sich die Validator-Performance oder die Block-Skip-Rate negativ entwickeln. Eine geringere Latenz ist wünschenswert. Das Mainnet unfreiwillig zu einem Stresstest zu machen, ist weniger sinnvoll.

350 ms werden bereits im Hauptnetz angezeigt.

Erste Live-Messungen deuten darauf hin, dass sich das Netzwerk in die beabsichtigte Richtung bewegt hat. The Block verglich zwei Zeiträume von jeweils 1,000 Zeitschlitzen um den Übergang herum. Ein Zeitraum vor der Änderung dauerte etwa 415 Sekunden, während eine spätere Messung in Epoche 1020 etwa 368 Sekunden dauerte.

Diese Werte variieren naturgemäß, da ein Zielwert von 350 ms nicht bedeutet, dass jeder Slot exakt bei 350 ms landet. Dennoch zeigen sie, dass die Änderung im Mainnet mehr ist als nur eine Konfigurationsdatei, die noch keine Auswirkungen hat. Die kürzeren Laufzeiten sind bereits in der tatsächlichen Blockproduktion sichtbar.

Im selben Bericht wird darauf hingewiesen, dass die Entwickler noch keinen Termin für die Aktivierung des Hauptnetzes für die nächste 300-ms-Phase festgelegt haben. Sie planen, zunächst das Netzwerkverhalten bei 350 ms zu beobachten.

Dies ist keine kostenlose Durchsatzsteigerung.

Eines der häufigsten Missverständnisse bezüglich der Änderung besteht in der Annahme, dass 12.5 % kürzere Zeitschlitze automatisch 12.5 % mehr Netzwerkkapazität bedeuten. SIMD-0525 reduziert bewusst die in jedem Zeitschlitz zulässige Arbeitsmenge, je kürzer die Zeitschlitze werden.

Solana hat kürzlich das Blocklimit im Mainnet auf 100 Millionen Recheneinheiten erhöht. Gemäß dem Vorschlag für kürzere Slots skaliert diese Obergrenze pro Slot auf 87.5 Millionen Recheneinheiten bei 350 ms, 75 Millionen bei 300 ms, 62.5 Millionen bei 250 ms und 50 Millionen bei 200 ms.

Ziel ist es, die Arbeitsleistung im Zeitrahmen annähernd konstant zu halten und gleichzeitig die Wartezeit der Nutzer zwischen den Zeitschlitzen zu verkürzen. Validatoren haben weniger Zeit, jeden Zeitschlitz zu bearbeiten, erhalten aber auch proportional weniger Aufgaben innerhalb dieses Zeitschlitzes.

Dies macht es in erster Linie zu einer Verbesserung der Reaktionsfähigkeit. Separate Änderungen an Rechengrenzen, Validierungssoftware und Transaktionsverarbeitung führen zu zusätzlichen Kapazitätserhöhungen.

Kürzere Führungsfenster haben einen Vorteil für die Marktstruktur

Es gibt noch einen weiteren Grund, warum Entwickler kürzere Slots wünschen, der wenig damit zu tun hat, wie schnell eine Wallet "bestätigt" anzeigt.

Ein Solana-Leader kontrolliert derzeit vier aufeinanderfolgende Zeitschlitze. Beim alten Zielwert von 400 ms ergab sich dadurch ein nominelles Zeitfenster von 1.6 Sekunden. Bei 350 ms sinkt es auf 1.4 Sekunden und beim vorgeschlagenen Zielwert von 200 ms auf 0.8 Sekunden.

Dadurch wird die maximale Zeitspanne verkürzt, in der ein einzelner Marktführer Transaktionen verzögern, neu anordnen oder selektiv einbeziehen kann, bevor ein anderer Validator an der Reihe ist. Für Händler, Market Maker und latenzempfindliche Anwendungen kann die Verkürzung dieses Zeitfensters sowohl die Marktstruktur als auch die Benutzerfreundlichkeit verbessern.

Kürzere Slots ermöglichen zudem eine präzisere On-Chain-Zeitmessung für Systeme, die die Aktualität von Slots messen, darunter Oracle-Konsumenten und automatisierte Market-Making-Anwendungen. Laut Solanas eigener Upgrade-Dokumentation können Market Maker durch die sinkende Latenz engere Spreads anbieten.

Finalität ist ein separates Projekt

Solana kann alle paar hundert Millisekunden Slots erzeugen, ohne dabei so schnell einen irreversiblen Abschluss zu erreichen. Derzeit dauert es noch etwa 12.8 Sekunden, bis der vollständige Abschluss erreicht ist.

Hier kommt Alpenglow ins Spiel. Die separate, in Entwicklung befindliche Konsensrevision zielt darauf ab, die Finalität auf etwa 150 ms zu reduzieren. Sollte diese Änderung wie geplant im Hauptnetz implementiert werden, würde sie eine deutlich größere Veränderung der Zeit bedeuten, die das Netzwerk benötigt, um einen Block als endgültig zu behandeln.

Beide Ansätze verfolgen das übergeordnete Ziel der Latenzreduzierung, sollten aber nicht verwechselt werden. SIMD-0525 verkürzt die Zeitschlitze im Rahmen des aktuellen Verfahrens. Alpenglow ändert das Konsens- und Finalisierungssystem selbst.

Warum Händler das beachten sollten

Für normale SOL-Inhaber wird eine Reduzierung der Slot-Zeit um 50 ms wahrscheinlich nicht über Nacht einen großen Unterschied machen. Der Nutzen für die Investition ist eher kumulativ.

Solana hat jahrelang mit Geschwindigkeit, niedrigen Gebühren und hoher On-Chain-Aktivität konkurriert. Eine Verkürzung der Slot-Zeiten ohne Destabilisierung der Validatoren würde die Position des Netzwerks im Handel, bei Zahlungen und Anwendungen, bei denen Latenz eine wichtige Rolle spielt, stärken. Das Erreichen von 200 ms würde die Ziel-Slot-Dauer gegenüber den ursprünglich festgelegten 400 ms halbieren.

Das technische Risiko steigt mit zunehmendem Zeitdruck, weshalb die stufenweise Einführung so wichtig ist. Die nächsten Meilensteine ​​sind nicht automatisch erreicht, nur weil die 350-ms-Version live gegangen ist. Die Entwickler planen, auf 300 ms, dann auf 250 ms und schließlich auf 200 ms zu wechseln, sofern die Netzwerkleistung weiterhin zufriedenstellend ist.

Solana hat den ersten wichtigen Schritt im Mainnet erfolgreich abgeschlossen. Es ist schneller, die Verbesserung ist messbar, und der Weg zu 200 ms ist nicht länger nur ein Vorschlag auf GitHub. Der spannendere Test beginnt jetzt: Können Validatoren die Taktung weiter verkürzen, ohne im Gegenzug die Zuverlässigkeit einzubüßen?

---------------

Autor: Sebastian Marrow
Europäische Nachrichtenredaktion
Aktuelle Crypto News