Jito-Solana v4.3.0-jito.0 erschienen, Absturz beim Identitätswechsel behoben
Victoria Shinder1 Min. LesezeitDie Jito Foundation hat am 2. Oktober Jito-Solana v4.3.0-jito.0 veröffentlicht, ein stabiles Punkt-Release des Validator-Clients, auf dem der Großteil des Solana-Stakes läuft. Das Changelog nennt vier Backports in die 4.3-Linie: schnelleres Senden des ersten Shreds, das Leeren von Nachrichten übersprungener Banks vor der Serialisierung in Turbine, Builds mit Debug-Symbolen und eine Korrektur der BAM-Tip-Aktualisierung mit vereinfachter Scheduler-Anbindung. BAM ist Jitos Marktplatz für die Blockzusammenstellung.
Zwei weitere Korrekturen wurden am 1. Oktober in die Zweige 4.3 und 4.4 übernommen und stehen nicht in diesem Changelog; sie dürften Betreiber mit einem folgenden Release erreichen.
Die erste behebt einen Absturz. set-identity, der Befehl, mit dem Validatoren den Schlüssel wechseln, mit dem sie Blöcke erzeugen – etwa beim Umschalten auf eine Ersatzmaschine –, konnte die gemeinsame Identität ändern, während die Blockerzeugungsschleife auf eine Benachrichtigung über ihr Leader-Fenster oder auf das Nachspielen des Elternblocks wartete. Die Schleife konnte dann eine andere Identität halten als der eingeplante Leader, und die daraus folgende Panik stoppte den Validator. Die Korrektur, übernommen aus Anzas Agave-Pull-Request 15582, gibt vor dem Anlegen einer Leader-Bank einen Fehler LeaderIdentityMismatch zurück, überspringt das betroffene Fenster und arbeitet spätere Benachrichtigungen weiter ab. Regressionstests decken normale Produktion und schnelle Leader-Übergabe ab.
Die zweite begrenzt, was eine BAM-Konfigurationsantwort einen Knoten kosten kann. Antworten über 64 KiB nach der Authentifizierung werden vor dem Protobuf-Decoding abgelehnt, nur die ersten 32 gültigen, eindeutigen Shred-Empfänger werden behalten, und Warnungen pro Eintrag weichen einer zusammenfassenden Zeile. Eine Verbindung mit übergroßer Antwort behält ihre letzte gültige Konfiguration.
Warum das wichtig ist
Mit dem Identitätswechsel schalten Betreiber im laufenden Betrieb um, ohne Slots zu verpassen – ein Wettlauf, der den Validator genau dabei abstürzen lässt, trifft den Moment, in dem Ausfall vermieden werden soll. Die BAM-Grenze ist die Art Härtung, die zählt, sobald Dritte Konfiguration in die Blockerzeugung einspeisen.