Solana hat soeben 50 Millisekunden von der Zeit abgezogen, die Validatoren benötigen, um einen Block zu produzieren, und es ist das erste Mal, dass das Netzwerk dies überhaupt getan hat. Das Solana-Slotzeit-Upgrade ging am Freitag im Mainnet live, senkte die Ziel-Slotzeit von 400 Millisekunden auf 350 Millisekunden und leitete damit ein, was Entwickler als einen gestuften, epoche-für-epoche verlaufenden Marsch hin zu einem deutlich schnelleren Ziel von 200 Millisekunden beschreiben.
Summary
Wichtigste Erkenntnisse
- Die Slotzeit des Solana-Mainnets ist von 400 Millisekunden auf 350 Millisekunden gefallen, die erste derartige Reduzierung seit dem Start des Netzwerks.
- Die Änderung wurde als Feature SIMD-0525 bei Slot 440.208.000 in Epoche 1019 aktiviert, nachdem sie am 14. Mai in den Code aufgenommen worden war.
- Drei weitere Kürzungen um jeweils 50 Millisekunden auf 300, 250 und schließlich 200 Millisekunden sind über separate Feature-Gates geplant, die jeweils von gesunden Block-Skip-Raten abhängen.
- Das Upgrade ist als Breaking Change gekennzeichnet, und Solana erklärt, dass Anpassungen beim Indexing für Drittanbieter-Tools noch ausgearbeitet werden.
- Jacob Creech, Vice President of Technology bei der Solana Foundation, bestätigte, dass 300 Millisekunden das nächste Ziel auf der Roadmap sind.
Solana reduziert erstmals die Slotzeit im Mainnet
Die Kernantwort ist einfach: Solana hat die Blöcke schneller gemacht, ohne die zugrunde liegende Struktur des Netzwerks zu verändern. Dies ist die erste Reduzierung der Slotzeit seit der Entstehung von Solana und verkürzt direkt das Zeitfenster, das jeder Validator erhält, um einen Block mit Transaktionen zusammenzustellen und zu übertragen.
Aktivierungsdetails und unmittelbare Auswirkungen
Das Feature, geführt unter SIMD-0525, wurde laut Solanas eigenem Explorer auf Mainnet Beta bei Slot 440.208.000 in Epoche 1019 aktiv. Der Vorschlag selbst wurde am 14. Mai in die Verbesserungsdokumente des Netzwerks übernommen, wodurch Entwickler mehrere Monate Vorlaufzeit erhielten, um die Validator-Software vorzubereiten, bevor der Schalter umgelegt wurde.
Die praktische Auswirkung zeigt sich fast sofort in der Bestätigungsgeschwindigkeit. Eine Momentaufnahme, über die The Block berichtete, ergab, dass ein Abschnitt von 1.000 Slots kurz vor der Änderung 415 Sekunden zur Fertigstellung benötigte, verglichen mit 368 Sekunden für einen ähnlichen Abschnitt, nachdem das Upgrade in Epoche 1020 aktiviert wurde – ein realer Rückgang, der mit dem neuen Ziel von 350 Millisekunden übereinstimmt.
Da jede Epoche auf Solana weiterhin 432.000 Slots enthält, führen schnellere Slots direkt zu schnelleren Epochen. Was früher ungefähr 48 Stunden dauerte, ist jetzt in etwa 42 Stunden abgeschlossen, obwohl sich an der internen Zählweise der Epoche nichts geändert hat.
Technische Grundlagen, die das Upgrade ermöglichen
All dies wäre ohne Arbeiten auf der Validator-Client-Seite nicht möglich gewesen. Solana schreibt Verbesserungen an Turbine, der Blockverteilungsschicht des Netzwerks, und an Replay, dem Prozess, mit dem Validatoren eingehende Blöcke verifizieren und über sie abstimmen, als technische Ermöglicher zu, die eine kürzere Slotzeit im großen Maßstab überlebensfähig gemacht haben.
Diese beiden Systeme mussten schneller werden, bevor das Netzwerk die verfügbare Zeit für einen Leader, einen Block fertigzustellen, ihn über Gulf Stream an den nächsten Leader weiterzugeben und dem restlichen Validator-Set Zeit zum Replay und zur Abstimmung zu geben, sicher komprimieren konnte. Eine Verkürzung dieses Fensters ohne diese Upgrades hätte die Skip-Raten wahrscheinlich erhöht und die Blockproduktion destabilisiert.
Gestufter Ansatz für weitere Slotzeit-Reduzierungen
Solana springt nicht direkt zum Endpunkt. Stattdessen bewegt sich das Netzwerk in vier separaten Stufen von 400 Millisekunden auf 200 Millisekunden, wobei jeder Schritt seine eigene Aktivierung und seine eigene Gesundheitsprüfung erfordert, bevor der nächste ausgelöst werden darf.
Feature-Gate-Mechanismus für zukünftige Upgrades
Jede zusätzliche Kürzung um 50 Millisekunden – sei es auf 300, 250 oder 200 Millisekunden – wird über ein separates Feature-Gate ausgelöst, das in einer späteren Epoche aktiviert wird, anstatt über einen einzigen globalen Schalter. Diese Struktur gibt der Solana Foundation und den Validator-Betreibern Spielraum, zu beobachten, wie sich das Netzwerk bei jeder neuen Geschwindigkeit verhält, bevor sie sich auf die nächste Reduzierung festlegen.
Anza, das Validator-Client-Entwicklungsteam, das aus den ursprünglichen Solana Labs hervorgegangen ist, hat einen vorläufigen Agave-v4.2-Plan vorgelegt, der alle vier gestuften Reduzierungen für eine spätere Aktivierung im Mainnet vorsieht. Für den Schritt auf 300 Millisekunden, der als nächstes ansteht, wurde noch kein Kalenderdatum oder keine spezifische Epoche festgelegt.
Risikokontrollen auf Basis der Block-Skip-Raten
Hier zeigt sich die Vorsicht besonders deutlich. Die Solana Foundation hat klar gemacht, dass das Netzwerk nicht zur nächsten Slotzeit-Reduzierung übergehen wird, wenn die Block-Skip-Raten zu stark ansteigen – was bedeutet, dass zu viele Validatoren ihre zugewiesenen Blöcke nicht rechtzeitig produzieren. Diese eingebaute Bremse ist wichtig, weil kürzere Slots jeden nachgelagerten Prozess komprimieren: Blockfertigstellung, Transaktionsverteilung und Validator-Abstimmung haben alle weniger reale Zeit, um korrekt abzulaufen.
Warum das wichtig ist: Ein gestaffelter Rollout mit einem Skip-Rate-Trigger macht Geschwindigkeit faktisch zu einer überwachten Variablen statt zu einem festen Versprechen. Wenn Validator-Hardware oder -Software bei 300 Millisekunden nicht mithalten kann, kann das Netzwerk einfach auf diesem Niveau pausieren, anstatt weiter voranzudrängen und Instabilität zu riskieren.
Breitere Auswirkungen und Netzwerkeffekte
Schnellere Slots bedeuten nicht automatisch ein in jeder Hinsicht schnelleres Netzwerk, und diese Unterscheidung ist für alle wichtig, die Solanas Durchsatzansprüche verfolgen. Validatoren verarbeiten Slots häufiger, aber jeder einzelne Slot enthält weniger Arbeit, sodass die Änderung in erster Linie Latenz und Bestätigungsgeschwindigkeit verbessert, nicht jedoch die reine Transaktionskapazität. Solana hat im Juli 2025 separat sein Compute-Unit-Limit auf 100 Millionen erhöht – ein eigenes Upgrade, das darauf abzielt, mehr Arbeit in jeden Block zu packen.
Status als Breaking Change und Auswirkungen auf das Indexing
Solana selbst bezeichnet das gesamte Solana-Slotzeit-Upgrade als Breaking Change, und die erforderlichen Indexing-Anpassungen für Drittanbieter-Tools und -Dienste sind noch zu bestimmen. Das ist eine bemerkenswerte Lücke: Solanas eigene Dokumentation beschreibt die Standard-Slotdauer weiterhin als 400 Millisekunden, obwohl der Explorer des Netzwerks bestätigt, dass das erste 350-Millisekunden-Feature-Gate bereits aktiv ist. Entwickler, die auf Indexern, Analyse-Dashboards oder Block-Explorern aufbauen, sollten mit kurzfristigen Reibungen rechnen, während sich die Tools an das neue Timing des Netzwerks anpassen.
Offizielle Stellungnahmen und Einblick in den Upgrade-Pfad
Jacob Creech, Vice President of Technology bei der Solana Foundation, beschrieb den Schritt als die erste Slotzeit-Reduzierung des Netzwerks und bestätigte, dass 300 Millisekunden das nächste Ziel auf der Roadmap sind. Weder Creech noch die öffentliche Upgrade-Seite der Foundation haben diesem nächsten Schritt ein festes Datum zugeordnet, und der Plan hängt ausdrücklich davon ab, wie sich das Netzwerk zunächst bei 350 Millisekunden schlägt.
Es gibt hier auch einen längeren Horizont. Slotzeit und vollständige Finalität sind nicht dasselbe – Solanas Blöcke benötigen heute, selbst bei der neuen Slotfrequenz von 350 Millisekunden, noch etwa 12,8 Sekunden, um vollständig irreversibel zu werden. Eine separate, noch in Entwicklung befindliche Überarbeitung namens Alpenglow zielt darauf ab, dieses Finalitätsfenster schließlich auf etwa 150 Millisekunden zu verkürzen, was eine weitaus größere strukturelle Änderung wäre als die derzeitigen gestuften Slotzeit-Reduzierungen. Das Netzwerk hat außerdem kürzlich den Firedancer-Client von Jump Crypto hinzugefügt, der in einer anderen Programmiersprache als der dominierende Agave-Stack entwickelt wurde und die Vielfalt der Validator-Clients verbessert, während die umfassendere Geschwindigkeitsinitiative weiterläuft.
FAQ
Welche Änderung hat Solana kürzlich an seinem Slot-Timing vorgenommen?
Solana hat seine Slotzeit im Mainnet von 400 Millisekunden auf 350 Millisekunden reduziert, was die erste Reduzierung seit der Entstehung des Netzwerks darstellt.
Wie werden zukünftige Slotzeit-Reduzierungen verwaltet?
Zukünftige Reduzierungen auf 300, 250 und 200 Millisekunden werden separat über Feature-Gates aktiviert und hängen davon ab, dass die Block-Skip-Raten nicht zu hoch werden.
Beeinflusst die Slotzeit-Reduzierung Solanas Epochenstruktur oder Ticks pro Slot?
Nein, das Upgrade ändert weder die Anzahl der Ticks pro Slot noch die Leader-Spanne oder die Anzahl der Slots in einer Epoche.
Warum wird das Upgrade als Breaking Change betrachtet?
Das Upgrade ist ein Breaking Change, weil es Indexing-Änderungen für Drittanbieter-Tools und -Infrastruktur erfordert, auch wenn diese Anpassungen noch zu bestimmen sind.
{„@context“:“https://schema.org“,“@type“:“FAQPage“,“mainEntity“:[{„@type“:“Question“,“name“:“Welche Änderung hat Solana kürzlich an seinem Slot-Timing vorgenommen?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Solana hat seine Slotzeit im Mainnet von 400 Millisekunden auf 350 Millisekunden reduziert, was die erste Reduzierung seit der Entstehung des Netzwerks darstellt.“}},{„@type“:“Question“,“name“:“Wie werden zukünftige Slotzeit-Reduzierungen verwaltet?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Zukünftige Reduzierungen auf 300, 250 und 200 Millisekunden werden separat über Feature-Gates aktiviert und hängen davon ab, dass die Block-Skip-Raten nicht zu hoch werden.“}},{„@type“:“Question“,“name“:“Beeinflusst die Slotzeit-Reduzierung Solanas Epochenstruktur oder Ticks pro Slot?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Nein, das Upgrade ändert weder die Anzahl der Ticks pro Slot noch die Leader-Spanne oder die Anzahl der Slots in einer Epoche.“}},{„@type“:“Question“,“name“:“Warum wird das Upgrade als Breaking Change betrachtet?“,“acceptedAnswer“:{„@type“:“Answer“,“text“:“Das Upgrade ist ein Breaking Change, weil es Indexing-Änderungen für Drittanbieter-Tools und -Infrastruktur erfordert, auch wenn diese Anpassungen noch zu bestimmen sind.“}}]}
Artikel mit Unterstützung künstlicher Intelligenz erstellt und von der Redaktion überprüft.
