SOLANA·HUB
EN
Infrastruktur

Vor Alpenglow nennt Jito mehrere Client-Versionen und kündigt BAM-Wartung an

Jitos Changelog vom 9. Oktober nennt vor Alpenglow mehrere Client-Versionen, die nicht übereinstimmen. BAM-Knoten gehen vorher in den Wartungsmodus. Eine Aktivierungsepoche fehlt.

SOLANA·HUB Redaktion
Quelle: Jito

Client-Versionen und BAM-Wartung

Jito hat am 9. Oktober auf X einen Artikel veröffentlicht. Der Titel lautet „BAM Changelog — Sept 23-Oct 9“. Darin stehen die Client-Versionen für die Zeit vor Alpenglow. Die Knoten des Block Assembly Marketplace (BAM) sollen in den Tagen vor der Aktivierung in den Wartungsmodus gehen. Eine bestätigte Aktivierungsepoche nennt der Text nicht.

BAM ist Jitos Schicht für den Bau von Blöcken. Validatoren, die daran hängen, bekommen die Blockzusammensetzung über BAM-Knoten. Im Wartungsmodus fallen sie auf die gewöhnliche Jito-Agave Block Engine zurück. Einen Mainnet-Termin nennt Anza auf der Übersichtsseite nicht. Die abgeschlossene Migration auf dem Testnetz steht in der Meldung zur Testnetz-Aktivierung.

Laut Jito rückt die Aktivierung auf dem Mainnet nach den jüngsten Angaben der Solana Foundation und von Anza für Mitte Oktober näher. Die bestätigte Epoche, der Zeitpunkt der Wartung, die Mindestversion und die Updates zur Wiederherstellung kommen laut demselben Text über Ankündigungen auf Discord. Laut FAQ haben Anza und die Solana Foundation die Version für die Mainnet-Übergangszeit noch nicht festgelegt. Anzas Übersichtsseite nennt kein Datum. Mitte Oktober ist Jitos Einordnung in diesem Changelog, kein Termin aus den genannten Texten.

Hinweis: Dies ist Berichterstattung, keine Anlageberatung.

Welche Versionen der Changelog nennt

Der Artikel vom 9. Oktober nennt für die Übergangszeit mehr als eine Versionsendung. Die Stellen stimmen nicht überein. Ein GitHub-Tag v4.3.0-jito.01 gibt es nicht. Der Link hinter dieser Zeichenkette zeigt auf das Tag v4.3.0-jito.1.

Stelle im ChangelogWas dort steht
ÜberschriftJito-Solana v4.3.0-jito.0 während der Übergangszeit
Aufzählung zum Upgrade„v4.3.0-jito.01“. Der Link zeigt auf v4.3.0-jito.1. Die Mindestversion wird vor der Aktivierung bestätigt.
Aufzählung zu FireBAM und FrankenBAMWährend der Übergangszeit auf v4.3.0-jito.1 des Agave-Clients wechseln. Nach der Aktivierung Version 26.10 oder neuer. 26.09 ist laut Text nicht bereit für Alpenglow.
Abschnitt zu den 200-ms-Slotsv4.3.0-jito.0. Jito nennt sie dort die Version mit den besten Leistungsoptimierungen.
Abschnitt Releasesv4.3.0-jito.0 vom 2. Oktober als empfohlene Mainnet-Version. v4.4.0-beta.0-jito vom 29. September als empfohlene Testnet-Version. FireBAM v26.09.5 vom 30. September als empfohlene Version für Mainnet und Testnet.

Darunter steht eine zweite Tabelle. Die Überschrift sagt, die aktuellen Mindestversionen für das Mainnet-beta seien unverändert:

Client, wie Jito ihn bezeichnetMindestversion
Agave (Jito Agave / Jito BAM)v4.3.0-jito
Firedancer (FireBAM)v26.09.5
Frankendancer (FireBAM)v0.1204.40300

Das ist die Mindestliste für den laufenden Betrieb. Sie ist nicht die Empfehlung für die Alpenglow-Übergangszeit. Jito verwendet in der Aufzählung „FrankenBAM“ und in der Tabelle „Frankendancer (FireBAM)“. Der Text setzt die beiden Bezeichnungen nicht ausdrücklich gleich.

Der Blog auf bam.dev vom 5. Oktober empfiehlt v4.3.0-jito.0. Die Mindestversion soll laut Blog vor der Aktivierung bestätigt werden. v4.3.0-jito.1 kommt dort nicht vor. FireBAM und FrankenBAM sollen während der Übergangszeit nicht laufen. Nach der Aktivierung nennt auch der Blog Version 26.10 oder neuer und bezeichnet 26.09 als nicht bereit für Alpenglow.

Ein Abruf der Releases am 10. Oktober 2026 zeigt:

  • v4.3.0-jito.0 ist am 2. Oktober 2026 erschienen und ist kein Pre-Release. Der Commit beginnt mit c21f9074. Das ist das Präfix in der Zeile, die Jito zum Prüfen angibt: solana-cli 4.3.0 (src:c21f9074; feat:c9ad34d2, client:JitoLabs).
  • v4.3.0-jito.1 ist am 8. Oktober 2026 erschienen und ist als Pre-Release markiert. In den Änderungen steht „support Alpenglow-aware transaction and bundle buffering“.
  • v4.3.0-jito ohne weitere Endung ist am 21. September 2026 erschienen und ist kein Pre-Release.
  • v4.4.0-beta.0-jito ist am 29. September 2026 erschienen und ist ein Pre-Release.
  • Das Tag v26.09.5 liegt im Repository jito-foundation/firebam. Der Commit ist vom 30. September 2026. Dieselbe Tag-Liste enthielt am 10. Oktober auch v26.09.6, Commit vom 7. Oktober, und v26.10.1, Commit vom 9. Oktober um 21:38 Uhr UTC. Der Changelog vom 9. Oktober, 15:25 Uhr UTC, nennt diese beiden Tags nicht.
  • Die Zeichenkette v0.1204.40300 gibt es als Frankendancer-Mainnet-Release vom 21. September 2026 im Repository firedancer-io/firedancer. Die Notiz dazu lautet „Update Agave submodule to v4.3.0“. Dieselbe Zeichenkette ist auch ein Tag in jito-foundation/firebam, Commit vom 22. September 2026. Die Tabelle im Changelog verlinkt keines der beiden Tags.

Was der Wartungsmodus ändert

Alle BAM-Knoten auf dem Mainnet gehen in den Tagen vor der Aktivierung in den Wartungsmodus. Ein Kalendertag steht nicht dabei. Validatoren, die an BAM hängen, fallen auf die gewöhnliche Jito-Agave Block Engine zurück. MPP, das Maker Priority Plugin, und BAM DBI, Direct Bundle Ingest, sind in dieser Zeit nicht verfügbar. Bundles über die Block Engine laufen weiter. Nach der Aktivierung kommen die BAM-Knoten schrittweise zurück, während die Leistung beobachtet wird.

Ein Produktions-Validator, der mit dev-context-only-utils (DCOU) gebaut ist, spaltet sich bei der Aktivierung vom Netz ab. Das steht im Changelog und im Blog vom 5. Oktober.

Was vor der Aktivierung zu tun ist

Die beiden Jito-Texte nennen Handlungen, aber kein Datum, bis zu dem sie erledigt sein müssen. Sie sagen „vor der Aktivierung“ und „in den Tagen davor“. Den Zeitpunkt kündigen sie über Discord an.

  • Validatoren, Nutzer von FullSend und Nutzer gewöhnlicher Block-Engine-Bundles: keine Handlung.
  • Nutzer von MPP: Oracle-Updates über TPU oder die Block Engine einreichen.
  • Nutzer von DBI: den bisherigen Einreichungsweg für Block-Engine-Bundles verwenden.
  • Produktions-Builds mit dev-context-only-utils nicht fahren.
  • FireBAM und FrankenBAM während der Übergangszeit nicht fahren. Der Changelog vom 9. Oktober nennt für diese Zeit den Wechsel auf v4.3.0-jito.1. Der Blog vom 5. Oktober und der Release-Abschnitt desselben Changelogs nennen für das Mainnet v4.3.0-jito.0.
  • Auf eine unterstützte Jito-Solana-Version wechseln. Welche Endung das ist, legen die Texte nicht einheitlich fest. Die Mindestversion soll vor der Aktivierung bestätigt werden.
  • Wer prüfen will, ob v4.3.0-jito.0 läuft, soll laut Changelog solana --version ausführen. Die erwartete Zeile ist solana-cli 4.3.0 (src:c21f9074; feat:c9ad34d2, client:JitoLabs).

Die FAQ beantwortet die Frage, ob Jito während der Übergangszeit laufen kann, mit Ja. Laut FAQ läuft Jito Agave (jito-solana) wie gewohnt. In der Übergangszeit ist nur der Block-Engine-Modus aktiv, nicht BAM. Hängt ein Validator normalerweise an BAM, fällt er auf die Block Engine zurück, sobald die BAM-Knoten in den Wartungsmodus gehen. Die Knoten kommen zurück, sobald sie nach der Aktivierung gesund sind.

200-ms-Slots und der Auktionstakt

Laut Changelog wird die Slot-Zeit mit Epoche 1053 auf 200 ms verkürzt, ungefähr um 15:00 Uhr UTC am Freitag, dem 9. Oktober. Wer Jito Agave auf dem Mainnet fährt, soll nach diesem Abschnitt auf v4.3.0-jito.0 sein. Der Auktionstakt von BAM leitet sich aus der Slot-Länge ab und zieht sich automatisch von Runden à 25 ms auf Runden à 20 ms zusammen. Eine Änderung an der BAM-Konfiguration ist nicht nötig.

Der Changelog ist um 15:25 Uhr UTC erschienen und formuliert die Umstellung noch als bevorstehend. Die Umstellung selbst ist getrennt belegt. Anza hat sie am 9. Oktober um 14:42 Uhr UTC bestätigt, ab der Grenze zu Epoche 1053. Das steht in der Meldung zu SIMD-0525. Die Angabe „ungefähr 15:00 Uhr UTC“ ist die Formulierung in Jitos Changelog, nicht die Uhrzeit aus Anzas Bestätigung.

Wie groß BAM laut Jito ist

Zum Stand von Epoche 1050 nennt Jito 164 Mio. SOL bei 385 angebundenen Validatoren, 37 % des Stakes im Netz. Das ist eine Angabe von Jito. Eine frühere Meldung bezog sich auf den Anteil der Validatoren nach Anzahl, nicht auf den Stake: Jito: Mehr als 50 Prozent der Solana-Validatoren betreiben BAM.

Für FireBAM nennt derselbe Abschnitt 7,3 Mio. SOL bei 12 Validatoren, 4,6 % des BAM-Stakes, und bezeichnet das als neuen Höchststand. Auch das ist Jitos Angabe. Den Client haben wir hier beschrieben: Jito FireBAM auf Frankendancer.

Was zu beobachten ist

  • Welche Mindestversion Jito vor der Aktivierung bestätigt, und ob v4.3.0-jito.0, die Zeichenkette v4.3.0-jito.01 und v4.3.0-jito.1 dabei zusammenfallen
  • Wann Discord die Aktivierungsepoche, den Wartungszeitraum und die Wiederherstellung der BAM-Knoten nennt
  • Ob für die Zeit nach der Aktivierung eine FireBAM-Version erscheint, die Jito als 26.10 oder neuer und als bereit für Alpenglow bezeichnet

Quellen

#jito #bam #alpenglow #validator #infrastruktur

Verwandte Artikel