BNB Chain: Pflicht-Update v1.8.2 bringt „Jenner“-Hardfork am 8. Dezember

Die BNB Chain erzwingt am 8. Dezember 2026 ein zentrales Netzwerk-Upgrade. Alle Betreiber von Mainnet-Nodes, MEV-Buildern und Sentry-Knoten müssen vor dem Stichtag auf die Release-Version v1.8.2 umsteigen. Das unter dem Namen „Jenner“ geführte Hardfork-Upgrade aktiviert neue Standards für Token und reserviert Netzwerk-Kapazitäten für bestimmte Zahlungen.

Der Zeitplan und die technischen Auflagen

Die Aktivierung im Mainnet ist exakt terminiert. Der Hardfork greift am 8. Dezember 2026 um 02:30:00 Uhr UTC, was dem Unix-Timestamp 1796697000 entspricht.

Das Update ist für alle Knotenbetreiber verpflichtend. Sie müssen die alte Programmdatei durch das neue Binary ersetzen und den Node vor dem Aktivierungszeitpunkt neu starten. Die Entwickler stellen für die Installation SHA256-Prüfsummen für die Mainnet- und Testnet-Archive sowie fertige Geth-Binaries für Linux, Mac, Windows und Linux ARM64 bereit.

Besondere Vorsicht gilt für Betreiber, die noch von den älteren Versionen v1.7.x oder v1.8.0-alpha aktualisieren. Sie müssen zwingend die Upgrade-Notizen der Versionen v1.8.0-alpha und v1.8.1 prüfen. Der Code enthält entfernte Konfigurationsfelder sowie Änderungen bei RPC-Schnittstellen und MEV-gRPC-Einstellungen.

Welche konkreten Auswirkungen ein verpasstes Upgrade hat, lassen die Release-Dokumente offen. Ein Chain-Split oder der temporäre Ausschluss aus dem Konsens sind bei Pflicht-Updates die üblichen Folgen. Auch der aktuelle Anteil der bereits aktualisierten Netzwerkknoten bleibt vorerst unklar.

Die Kernfunktionen: Drei neue BEP-Standards

Das Jenner-Upgrade erfordert den Hardfork primär wegen drei fundamentaler Protokolländerungen, den sogenannten BNB Evolution Proposals (BEP).

Standard	Funktion	Technische Details
BEP-702 (Compliant Asset Standard)	Neue Token-Regeln	Führt CAS20 über Stateful-Precompiles ein. Token-Erstellung benötigt Admin-Freigabe.
BEP-703 (Payment Lane)	Priorisierung von Zahlungen	Reserviert 5 % des Block-Gases für berechtigte BNB-Transfers und gelistete Contracts.
BEP-706 (Millisecond Timestamp)	Präzisere Zeitmessung	Stellt Millisekunden-Blockzeit über Precompile 0x70 bereit. block.timestamp bleibt in Sekunden.

Bei BEP-702 fällt die zentralisierte Kontrolle auf. Die Token-Erstellung unter dem neuen Standard erfordert die separate Freigabe durch einen Administrator, den die Governance ernennt. Wer genau diese Rolle übernimmt, beantwortet die offizielle Ankündigung nicht.

Ähnlich verhält es sich bei BEP-703. Das Netzwerk räumt reinen Zahlungen künftig Vorfahrt ein, indem fünf Prozent des Block-Gases standardmäßig blockiert bleiben. Welche spezifischen Smart Contracts initial auf diese Liste der erlaubten Payment-Contracts kommen, verrät das Update nicht. Die Governance kann diese Liste sowie die Prozentzahl künftig anpassen.

MEV-Verbesserungen greifen ohne Hardfork

Das Release v1.8.2 enthält Anpassungen aus dem BEP-675. Diese betreffen sogenannte MEV-Enhancements und benötigen laut den Entwicklern keine direkte Hardfork-Aktivierung.

Der Fokus liegt auf Geschwindigkeit. Der Transport von BidBlocks erfolgt künftig schneller über die gRPC-Schnittstelle mit RLP-kodierten Binärdaten. Das reduziert den Rechenaufwand für JSON-Parsing und Hex-Konvertierungen. Die alte JSON-RPC-Schnittstelle bleibt als Rückfalloption unterstützt.

Das Netzwerk prüft eingehende Blöcke nun strenger. Das System lehnt BidBlocks mit einer sogenannten Zero-State-Root konsequent ab. Baut ein MEV-Builder fehlerhafte Blöcke und belegen mehrere Validatoren diese Bad-Block-Evidenz, entzieht ihm das System den lokalen SendBidBlock-Zugriff. Diese Sperren bleiben auch nach einem Neustart des Knotens aktiv.

Neue Metriken für fehlerhafte BidBlocks und gesperrte Builder machen diese On-Chain-Aktivitäten künftig sicht- und messbar. Ob es im Vorfeld Testnet-Durchläufe oder spezifische Sicherheitsaudits für diese tiefgreifenden Eingriffe gab, erwähnen die aktuellen Release-Notizen nicht.

Quellen

• BNB Chain Release v1.8.2 (GitHub)