SIMD-0675-Entwurf: Geo-sensibler Leader-Plan senkt die mittlere Übergabelatenz von 36 auf 17 ms
Serguey Asael Shinder2 Min. LesezeitEin Entwurf für ein Solana Improvement Document, SIMD-0675 „Geo-Aware Leader Schedule“, will ändern, wie der Leader-Plan jeder Epoche entsteht. Verfasst haben ihn Quentin Kniep und Roger Wattenhofer; der Pull Request wurde am 29. September eröffnet und am 15. Oktober erneut aktualisiert, sein Status im Dokument lautet Draft.
Die Idee. Heute ist der Plan eine stakegewichtete Zufallsreihenfolge (SIMD-0180). SIMD-0675 ergänzt einen Nachbearbeitungsschritt, der diesen Plan umsortiert, sodass geografisch nahe Leader in kurzen Läufen aufeinanderfolgen. An der Zahl der Leader-Fenster ändert sich nichts: Jeder Validator behält genau so viele wie im Basisplan. Die Standorte stammen aus den Selbstauskünften der Validatoren nach dem Begleitvorschlag SIMD-0674.
Warum das unter Alpenglow zählt. Mit Alpenglows schneller Leader-Übergabe (SIMD-0630) schickt jeder Leader seinen Block direkt an den nächsten; die Verzögerung zwischen zwei Leadern wird damit von der einfachen Netzwerklatenz zwischen ihnen bestimmt. Die Autoren nennen zwei Probleme einer Zufallsreihenfolge: interkontinentale Sprünge zwischen aufeinanderfolgenden Leadern, laut Entwurf der wichtigste verbleibende Grund, warum eine Epoche länger dauert als vorgesehen, und einen Anreiz zur Zentralisierung – ein Validator an einem stakereichen Standort liegt im Schnitt nahe an seinem Vorgänger und erhält Blöcke früher, was Ballung belohnt und entfernte Betreiber benachteiligt.
Die Konstanten. Der Entwurf setzt RUN_LENGTH = 3 und STAKE_FLOOR = 10%. Jeder Validator erhält einen Radius: die kleinste Entfernung, innerhalb derer mindestens 10 % des gesamten Stakes liegen. Gruppen benachbarter Leader dürfen sich nur innerhalb dieses Radius bilden; das setzt eine Mindestvielfalt je Gruppe und erschwert es einem Angreifer mit wenig Stake, einen ganzen Lauf zu füllen. Längere Läufe senken die Latenz weiter, bedeuten aber mehr Zeit in einer einzigen Rechtsordnung, stärker korrelierte Ausfälle und längere Läufe für einen möglichen Angreifer.
Die Simulation. Auf der Mainnet-Stakeverteilung der Epoche 1038 – 661 Validatoren, Standorte mit Globalping-Messungen korrigiert, 108.000 Leader-Fenster je Epoche, fünf Zufallsstartwerte – sinkt die mittlere Übergabelatenz zwischen ehrlichen Validatoren von heute 36,2 ms auf 17,0 ms bei Läufen von drei; der Median über alle Übergaben fällt von 23,4 auf 4,5 ms. Als nahezu ungünstigsten Fall modellieren die Autoren einen Angreifer mit 5 % des Stakes allein in Sydney, 73 ms vom nächsten Stake in Los Angeles entfernt. Im heutigen Plan haben 94,7 % seiner Läufe die Länge eins; mit RUN_LENGTH = 3 sind es 53,5 % Länge eins, 24,0 % Länge zwei und 22,3 % Länge drei.
Eine Folgeänderung. Weil Übergaben kürzer werden, muss laut Entwurf HANDOVER_COMPENSATION aus SIMD-0630 bei Aktivierung von 25 ms auf 50 ms steigen: In der Simulation wächst die durchschnittliche Zeit vom Empfang des Blocks des Vorgängers bis zum ParentReady-Ereignis von 23,2 auf 46,2 ms. Der Wert solle neu bewertet werden, wenn sich die geografische Verteilung des Stakes verschiebt. Ein Feature-Gate oder Aktivierungsdatum gibt es nicht; das entsprechende Feld im Dokument ist noch ein Platzhalter.
Quelle: Pull Request zu SIMD-0675 — https://github.com/solana-foundation/solana-improvement-documents/pull/675