vor 10 Stunden

Analyse: Solanas 250-ms-Slots könnten die Netzwerkstabilität auf die Probe stellen

Why Solana's new 250ms speed boost could actually trigger network instability

CryptoSlate

Die Koordination der Solana-Validatoren begann am 18. September bei Epoch 1037 mit einer Ziel-Slotzeit von 250 Millisekunden zu arbeiten. Das geht aus dem Engineering-Changelog von Solana und einem Bericht von Solana Compass hervor, der den Übergang auf etwa 05:06 UTC datierte. Ein Slot ist das vom Netzwerk angestrebte Zeitintervall, in dem ein Validator einen Block erzeugt. Das kürzere Intervall schafft häufiger Gelegenheiten, Transaktionen zu verbuchen, lässt den Validatoren jedoch weniger Zeit, die Produktion von einem Leader an den nächsten weiterzugeben. Eine frühe Stichprobe vom 20. September über 60 Zeitfenster von jeweils einer Minute erfasste etwa 266 Millisekunden pro erzeugtem Slot. In Epoch 1037 wurden etwa 0,05 % der geplanten Slots übersprungen. Das begrenzte Beobachtungsfenster erlaubt eine ermutigende erste Einschätzung, belegt aber keinen langfristigen Leistungstrend. Der Schritt auf 200 Millisekunden stand am 20. September im Mainnet noch aus, und der Zeitplan für das Feature-Gate von Anza enthielt kein verbindliches Aktivierungsdatum. Auf Solanas Seite zur Reduzierung der Slotzeit heißt es, dass weitere Verkürzungen von einer akzeptablen Netzwerkleistung, einschließlich der Übersprungraten, abhängen. Der Entwurf SIMD-0525 würde das Blockbudget bei 250 Millisekunden von 62,5 Millionen Compute Units auf 50 Millionen bei 200 Millisekunden reduzieren. Beide Einstellungen belassen die nominale Protokollobergrenze bei nahezu 250 Millionen Compute Units pro Sekunde. Kürzere Slots verändern daher Taktung und Latenz direkter als die Kapazität, weil Blöcke häufiger eintreffen, aber weniger zulässige Arbeit enthalten. Der tatsächlich erreichte Transaktionsdurchsatz hängt weiterhin von der Nachfrage, der Planung und davon ab, wie effektiv die Leader den Blockspace füllen. Der Entwurf behält den Turn jedes Leaders bei vier Slots. Damit hat ein Leader bei 250 Millisekunden ein nominales Zeitfenster von einer Sekunde und bei 200 Millisekunden ein Zeitfenster von 800 Millisekunden. Validatoren hätten nach einer Übergabe weniger Zeit, Datenverkehr zu empfangen und mit der Produktion zu beginnen. Eine technische Analyse der Solana Foundation maß eine mediane Zeitstrafe für die Dauer des ersten Slots von etwa 28 Millisekunden, wenn aufeinanderfolgende Leader weniger als 500 Kilometer voneinander entfernt waren, und von 122 Millisekunden, wenn sie mehr als 8.000 Kilometer voneinander entfernt waren. Die größere Strafe entspricht 61 % eines Ziel-Slots von 200 Millisekunden. Die Kennzahl vergleicht den ersten Slot eines Leaders mit dessen späteren Slots und erfasst mehr als nur die Netzwerklatenz. Solanas Changelog vom 18. September nennt pessimistische Weiterleitung an den nächsten Leader als eine technische Reaktion für den Fall, dass eine Transaktion ihr vorgesehenes Ziel verfehlen könnte. Client-Teams testen außerdem die Block- und Transaktionsausführung anhand von Konformitäts-Binärdateien über verschiedene Implementierungen und Versionen hinweg. Der Entwurf behält in seiner 200-Millisekunden-Phase einen Schwellenwert von 250 Millisekunden für das Zurückstellen der Reparatur bei. Diese Verzögerung ist länger als ein Ziel-Slot. Dabei handelt es sich um vorausschauende technische Zeitmargen und nicht um Belege für einen aktuellen Ausfall. Der Routing-Ausfall bei TeraSwitch am 12. August ereignete sich vor der Einstellung auf 250 Millisekunden und wurde nicht durch sie verursacht. Laut dem Vorfallbericht von TeraSwitch verloren 12 Standorte die Erreichbarkeit, und ein Standort in Miami wurde zur Eindämmung des Problems entfernt. Solana Compass maß 28,83 % des Netzwerk-Stakes als etwa 33 Minuten lang säumig. Die Solana Foundation erklärte, dass die Blockproduktion fortgesetzt wurde und weiterhin Transaktionen verbucht wurden. Unabhängige Daten mit Stand vom 7. September setzten Solanas stakebasierten Nakamoto-Koeffizienten auf 18 und den größten Validator auf nahezu 4 % des aktiven Stakes. Ein Anbieterbericht für dasselbe Datum setzte den Anteil von TeraSwitch auf 22,1 % des aktiven Stakes. Die Foundation erklärte separat, dass TeraSwitch im vergangenen Jahr 38 % des Stakes beherbergt hatte, bevor sein Anteil auf unter 30 % reduziert wurde. Diese Zahlen haben kein gemeinsames Datum und keine gemeinsame Methode, weshalb die Messung vom 7. September das aussagekräftigere aktuelle Bild und keine kontinuierliche Reihe darstellt. Eine stakegewichtete Abfrage vom 20. September ordnete rund 87,4 % des Stakes Client-Versionen der Reihe 4.x, 7,3 % der Reihe 0.x und 5,3 % der Reihe 26.x zu. Die Versionsnummern der Hauptversionen sind nur grobe Anhaltspunkte für Software aus den Familien Agave, Frankendancer und Firedancer, weil sie nicht jede Scheduler-Variante oder jeden nachgelagerten Build unterscheiden können. Stake-Konzentration, Client-Abstammung und Hosting-Anteil messen unterschiedliche Ausfallrisiken. Schnellere Slots schaffen diese Konzentrationen nicht, aber kleinere Margen bei Übergaben und Reparaturen können dazu führen, dass sich korrelierte Störungen stärker auswirken. Eine belastbarere Entscheidung über 200 Millisekunden würde auf anhaltenden Messungen der Slotdauer, der Übersprungraten, der Transaktionsverbuchung und der Leader-Übergaben beruhen. Diese Messungen sollten idealerweise nach Client-Familie und Infrastruktur-Anbieter aufgeschlüsselt werden, um schwächere Kohorten oder längere Randbereiche zu erkennen, die in einem netzwerkweiten Durchschnitt verborgen bleiben. Alpenglow folgt einem separaten Zeitplan, weil es sich um ein Konsens-Upgrade mit dem Ziel einer Finalität von etwa 150 Millisekunden handelt, während die Slotzeit die Taktung der Gelegenheiten zur Blockproduktion bestimmt. Solanas offizielle Seiten nennen für Alpenglow unterschiedliche Planungsfenster, darunter ein Ziel für Q3 und ein Zeitfenster im Oktober für Agave 4.3; keine der beiden Seiten nennt einen genauen Aktivierungstag. Die zentrale Prüfung für 200 Millisekunden besteht darin, ob Weiterleitung, Leader-Übergänge, Reparatur und unterschiedliche Client-Implementierungen über einen längeren Beobachtungszeitraum sowie unter geografisch und infrastrukturell ungünstigeren Bedingungen Schritt halten können.

This content is an AI-generated summary/analysis for informational purposes only and does not constitute investment advice.