Solana hat seine Ziel-Slot-Zeit zum ersten Mal seit dem Start des Netzwerks von 400 Millisekunden auf 350 ms reduziert und damit einen vierstufigen Plan gestartet, der die Slots letztendlich auf 200 ms senken könnte.
Zusammenfassung
- Solana hat seine Ziel-Slot-Zeit zum ersten Mal seit dem Start des Netzwerks von 400 ms auf 350 ms reduziert.
- Die Änderung ist die erste Stufe von SIMD-0525, das weitere Reduzierungen auf 300 ms, 250 ms und 200 ms plant.
- Kürzere Slots sollen die Bestätigungslatenz reduzieren, während die Ressourcengrenzen des Netzwerks proportional angepasst werden.
- Die verbleibenden Stufen sind für Agave v4.2 geplant, obwohl der Aktivierungszeitplan vorläufig bleibt.
Jacob Creech, Vizepräsident für Technologie der Solana Foundation, kündigte die Änderung am 21. August an und sagte, das Netzwerk sei in „eine neue Ära von 350 ms“ eingetreten, bevor er hinzufügte: „Nächster Halt: 300 ms.“
Die durchschnittlichen Slot-Zeiten lagen zum Zeitpunkt des Schreibens laut Solanas Slot-Zeit-Explorer bei etwa 360 ms, verglichen mit dem ursprünglichen Ziel von 400 ms.
Die Änderung ist der erste Schritt unter SIMD-0525, einem Solana-Verbesserungsvorschlag, der vier schrittweise kürzere Slot-Konfigurationen bei 350 ms, 300 ms, 250 ms und 200 ms einführt. Der Vorschlag wurde am 14. Mai genehmigt und zusammengeführt.
Anstatt sofort zum endgültigen Ziel überzugehen, plant Solana, jede Reduzierung separat zu aktivieren, um Validator-Betreibern und Client-Entwicklern die Möglichkeit zu geben, das Netzwerkverhalten zu testen, während die Blockproduktion schneller wird.
Solanas Slot-Zeit beginnt ihre Bewegung in Richtung 200 ms
Die Solana Foundation sagte im Juni, dass die Reduzierung der Slots von 400 ms auf 200 ms die Latenz verringern und Bestätigungen schneller zu den Benutzern gelangen lassen würde.
Unter SIMD-0525 ändert das erste Feature-Gate das Slot-Ziel auf 350 ms. Spätere Aktivierungen würden es auf 300 ms, dann auf 250 ms und schließlich auf 200 ms bringen.
Alle vier Stufen sind derzeit für Agave v4.2 geplant, den von Anza entwickelten Validator-Client, obwohl der Rollout-Zeitplan vorläufig bleibt und sich je nach Tests ändern kann.
Kürzere Slots bedeuten, dass Blockproduktionsmöglichkeiten häufiger zwischen Validatoren wechseln. SIMD-0525 behält die 64 Ticks pro Slot und das Vier-Slot-Leader-Fenster des Netzwerks bei, aber die Menge an Echtzeit, die jedes Leader-Fenster darstellt, sinkt mit jeder Reduzierung.
Beim vorherigen Ziel von 400 ms gab vier Slots einem Leader ein nominales Fenster von 1,6 Sekunden. Ein 350-ms-Slot reduziert diese Zahl auf 1,4 Sekunden, während 300 ms sie auf 1,2 Sekunden senken würden. Beim endgültigen Ziel von 200 ms würde ein Vier-Slot-Fenster etwa 800 ms dauern.
Der Vorschlag besagt, dass die Reduzierung der Zeit, die von einem Leader kontrolliert wird, auch den Zeitraum verringern kann, in dem Transaktionen verzögert oder neu geordnet werden könnten, bevor ein anderer Validator die Gelegenheit erhält, Blöcke zu produzieren.
SIMD-0525 erlaubt dem Netzwerk nicht einfach, nach dem Wechsel von 400 ms auf 200 ms doppelt so viel Arbeit zu leisten. Die Ressourcengrenzen werden proportional angepasst, wenn die Slot-Dauer sinkt, sodass die Verarbeitungsanforderungen über einen bestimmten Zeitraum nicht allein deshalb steigen, weil mehr Slots produziert werden.
Bei der ursprünglichen Basislinie von 60 Millionen Compute-Units, die im Vorschlag verwendet wurde, würde das Limit pro Slot bei 350 ms auf 52,5 Millionen CUs, bei 300 ms auf 45 Millionen, bei 250 ms auf 37,5 Millionen und bei 200 ms auf 30 Millionen fallen.
Schnellere Slots ändern Bestätigungen und Epochen-Timing
Die Bestätigungslatenz ist einer der Hauptbereiche, die von der Änderung betroffen sind, da Solana mehrere Teile des Netzwerkbetriebs in Slots misst.
Da Validatoren schneller durch Slots wechseln, können slotbasierte Bestätigungsschwellen in weniger Echtzeit erreicht werden. Anwendungen, die Slotnummern verwenden, um zu bestimmen, wie aktuell Blockchain-Informationen sind, können auch feinere Zeitintervalle erhalten.
SIMD-0525 identifiziert Oracle-Nutzer und automatisierte Market Maker unter den Anwendungen, die von den kürzeren Intervallen profitieren könnten, insbesondere wenn Entscheidungen vom Alter der On-Chain-Daten abhängen.
Die Epochendauer wird ebenfalls sinken, da Solana plant, 432.000 Slots pro Epoche beizubehalten.
Eine Epoche mit 400-ms-Slots hat eine nominale Dauer von etwa 48 Stunden. Der Wechsel auf 350 ms reduziert dies auf etwa 42 Stunden, während 300 ms eine Epoche auf etwa 36 Stunden bringen würden. Bei 250 ms sinkt die Zahl auf etwa 30 Stunden, bevor sie bei Aktivierung von 200-ms-Slots etwa 24 Stunden erreicht.
Solanas jährliche Slot-Berechnungen werden zusammen mit der Änderung angepasst, sodass die Protokollausgabe weiterhin auf der realen Zeit basiert und nicht einfach steigt, weil jedes Jahr mehr Slots anfallen.
Der unter Solanas Alpenglow-Konsenssystem vorgeschlagene Validator-Admission-Ticket ist ebenfalls darauf ausgelegt, mit kürzeren Epochen zu skalieren. SIMD-0525 legt fest, dass ein Kostenpunkt von 1,6 SOL pro Epoche bei 400 ms auf 1,4 SOL bei 350 ms sinken würde, gefolgt von 1,2 SOL, 1 SOL und 0,8 SOL in den nachfolgenden Stufen.
Der Vorschlag besagt, dass die Anpassungen darauf abzielen, die Validatorkosten trotz der kürzeren Epochen bei etwa 0,8 SOL pro Tag zu halten.
Solanas Leistungsverbesserungen gehen über Slot-Zeiten hinaus
Die Einführung der Slot-Zeiten erfolgt, während Solana-Entwickler an mehreren Änderungen an der Validator- und Konsensinfrastruktur des Netzwerks arbeiten.
Wie zuvor von crypto.news berichtet, trat Alpenglow im Mai in die Community-Validator-Testphase ein, nachdem Anza das Konsensdesign auf einem Testcluster bereitgestellt hatte.
Alpenglow ist darauf ausgelegt, Bestätigungszeiten auf etwa 150 ms zu bringen und gleichzeitig Proof of History und On-Chain-Abstimmungstransaktionen aus Solanas Kernkonsensprozess zu entfernen. Anza hat das geplante Upgrade als die größte Konsensänderung in der Geschichte von Solana bezeichnet.
Das System führt ein Abstimmungsdesign namens Votor ein, das Off-Chain-Validator-Kommunikation und Signaturaggregation nutzt, um einen Konsens zu erzielen. Seine Entwicklung ist getrennt von SIMD-0525, obwohl sich beide Projekte darauf konzentrieren, die für Netzwerkoperationen erforderliche Zeit zu reduzieren.
Die Validator-Software ist im Jahr 2026 ebenfalls vielfältiger geworden. Jump Cryptos Firedancer-Mainnet-Rollout begann im Mai nach jahrelanger Entwicklung mit der Produktion von Blöcken und bietet eine unabhängig gebaute Alternative zu Solanas bestehenden Validator-Implementierungen.
Jump Crypto riet den Validatoren damals, nicht in großem Umfang auf Firedancer zu migrieren, bis Sicherheitsaudits abgeschlossen seien. Der Client wurde sowohl entwickelt, um die Leistung zu verbessern, als auch um das Risiko zu verringern, das entsteht, wenn eine Blockchain stark von einer einzigen Validator-Softwareimplementierung abhängt.
Später in diesem Monat offenbarte Coinbase ein Multi-Client-Setup mit Jito und Firedancer in seiner Solana-Validator-Infrastruktur. Seine Validator-Architektur unterstützte zu diesem Zeitpunkt etwa 40,48 Millionen gestakte SOL, was etwa 9,52 % des gestakten Angebots des Netzwerks entspricht, so der Q1-Validator-Leistungsbericht der Börse.
Solana führte im Juli eine weitere Netzwerkänderung ein, als es ein On-Chain-Governance-Framework startete, das es Validatoren ermöglicht, stake-gewichtete Abstimmungen über Solana-Governance-Vorschläge durchzuführen. Unter dem neuen Governance-Prozess durchlaufen Vorschläge, die 15 % anfängliche Unterstützung erhalten, einen 11-Epochen-Prozess mit Diskussion, einem Stake-Snapshot und formeller Abstimmung.
Ein Vorschlag wird angenommen, wenn die Ja-Stimmen mindestens 66,67 % des teilnehmenden "Dafür"- und "Dagegen"-Stakes ausmachen, während technische Änderungen weiterhin über den bestehenden SIMD-Prozess laufen können, ohne zuvor eine Governance-Abstimmung zu erhalten.
Die nächste Slot-Reduzierung würde Solana auf 300 ms bringen
Mit der jetzt aktiven 350-ms-Einstellung identifiziert SIMD-0525 300 ms als nächste Stufe in der Sequenz.
Die Änderung würde das nominale Vier-Slot-Führungsfenster von 1,4 Sekunden auf 1,2 Sekunden reduzieren und eine Epoche von etwa 42 Stunden auf 36 Stunden senken.
Weitere Feature-Aktivierungen würden Solana dann auf 250 ms und 200 ms bringen. Jede Konfiguration wird aus den Basiswerten des Netzwerks berechnet, anstatt die gerundeten Grenzen der vorherigen Stufe zu verwenden, ein Design, das verhindern soll, dass sich Rundungsunterschiede über aufeinanderfolgende Reduzierungen ansammeln.
Die Tests der Solana-Infrastruktur wurden fortgesetzt, während diese Phasen vorbereitet werden. Im Juli erreichte die Netzwerkaktivität ebenfalls Rekordniveaus, da tokenisierte Vermögenswerte auf Solana expandierten, wobei tokenisierte Aktienaktivitäten zu einer erhöhten Nutzung in der gesamten Kette beitrugen.
Für SIMD-0525 erfordert jedoch jede weitere Slot-Reduzierung weiterhin die entsprechende Funktionsaktivierung. Nach der neu aktivierten 350ms-Einstellung identifizierte Creech 300ms als nächstes Ziel des Netzwerks.
