BNB Chain hat einen Notfall-Patch für seinen BSC-Reth Execution Client veröffentlicht, der einen Fehler im Legacy-Prozess zur State-Root-Berechnung der Software behebt. Das Update, BSC-Reth v0.1.4-hotfix, wurde am 6. November in einem GitHub-Release veröffentlicht und wird Betreibern empfohlen, die sowohl Mainnet- als auch Testnet-Infrastruktur betreiben, wie coinpaper berichtet.

Execution Clients sind die Softwareprogramme, die Nodes ausführen, um Transaktionen zu verarbeiten und den Chain-Status zu verwalten; BSC-Reth ist die Implementierung des Reth Execution Clients durch BNB Chain. Da netzwerkspezifische Clients Code aus dem gemeinsamen Upstream-Projekt übernehmen, fließen Korrekturen aus der gemeinsamen Codebasis in die Releases jedes Netzwerks ein – und, wie dieser Vorfall zeigt, auch Fehler.

Der Fehler bei der State-Root-Berechnung

Das Problem hat seinen Ursprung im Legacy-Pfad zur State-Root-Berechnung, der vom Reth Execution Client geerbt wurde. Unter bestimmten Bedingungen, die Blockchain-Datenstrukturen betreffen, konnte die Software einen falschen State Root erzeugen.

Ein State Root ist eine kryptografische Darstellung des aktuellen Zustands einer Blockchain, die Daten wie Kontostände und Smart-Contract-Speicher umfasst. Nodes verlassen sich auf diese Berechnungen, um zu überprüfen, dass Transaktionen im gesamten Netzwerk konsistent verarbeitet wurden.

Berechnet ein Node einen falschen State Root, kann dies dazu führen, dass er ansonsten gültige Blöcke ablehnt oder ein Ergebnis liefert, das von anderer Netzwerkinfrastruktur abweicht. Derartige Inkonsistenzen können die Zuverlässigkeit der Blockchain-Verifizierung beeinträchtigen.

Was der Hotfix ändert

Der BSC-Reth v0.1.4-hotfix enthält eine Upstream-Korrektur aus dem Reth-Entwicklungsprojekt. Laut Release Notes behebt die Änderung speziell Probleme im Zusammenhang mit inkrementellen State-Root-Berechnungen.

Das Update betrifft Validatoren, Builder für maximal extractable value (MEV), Full-Node-Betreiber und Sentry-Betreiber. Betroffene Betreiber müssen die neue Softwareversion installieren und ihre Nodes neu starten. Das Upgrade erfordert keine Datenbankmigration oder zusätzlichen Hard Fork, wodurch der Rollout in einem routinemäßigen Installations- und Neustartzyklus bleibt und kein koordinierter Protokollwechsel nötig ist.

Base hat die Reth-Schwachstelle ebenfalls behoben

das zugrunde liegende Softwareproblem beschränkte sich nicht auf BNB Chain. Andere Ethereum-kompatible Netzwerke, die betroffene Reth-Implementierungen nutzen, mussten ebenfalls ihre Exposition prüfen.

Das von Coinbase unterstützte Base bestätigte, dass seine Entwickler die Schwachstelle identifiziert und behoben haben. Das Netzwerk deployte nach Prüfung der potenziellen Auswirkungen einen aktualisierten Execution Client und meldete keine Störungen des Netzwerkbetriebs oder der Nutzermittel.

Die Entwicklung ist für Base besonders relevant, da das Netzwerk seine Nutzung von Reth-basierter Infrastruktur zuvor durch das Azul-Upgrade ausgebaut hatte.

BNB Chain stellte außerdem klar, dass sein Netzwerk opBNB nicht betroffen ist, da es den anfälligen op-reth Client nicht verwendet. In diesen Netzwerken hing die Exposition davon ab, welchen Execution Client jede Chain einsetzte – ein Beispiel dafür, wie gemeinsamer Upstream-Code ansonsten unabhängige Ökosysteme verbinden kann.

das neu gepatchte Problem ist von historischen Bridge-Schwachstellen zu unterscheiden, die Notfallinterventionen im Netzwerk erfordert haben. Keine bestätigte Ausnutzung, kein Verlust von Kundengeldern und kein BSC-weiter Shutdown wurden auf den Fehler bei der State-Root-Berechnung zurückgeführt.

Jenner Hard Fork bleibt für Dezember geplant

die Notfall-Softwareveröffentlichung erfolgt, während BNB Smart Chain sich auf sein nächstes geplantes Protokoll-Upgrade vorbereitet, den Jenner Hard Fork. Ein früheres BSC-Reth v0.1.4-Release hatte den Hard Fork für den 8. Dezember 2026 um 02:30 UTC angesetzt.

Anders als der Hotfix vom 6. November umfasst Jenner geplante Protokolländerungen, die erfordern werden, dass Mainnet-Betreiber kompatible Software einsetzen. Der Unterschied ist wichtig: Der neueste Patch behebt ein Softwareberechnungsproblem, ohne neue Netzwerkregeln einzuführen, während das Jenner-Upgrade eine geplante Protokolländerung ist. Für Node-Betreiber ergibt sich praktisch eine Abfolge von zwei getrennten Meilensteinen – jetzt den v0.1.4-hotfix einspielen und anschließend die Client-Kompatibilität für die geplante Dezember-Aktivierung des Forks sicherstellen.

Frühere Sicherheitsvorfälle rund um BNB Chain und Cross-Chain-Exploits haben die unterschiedlichen Risiken von Blockchain-Anwendungen, Bridges und zugrunde liegender Netzwerkinfrastruktur aufgezeigt. Der aktuelle Hotfix behebt ein Problem der Softwarekorrektheit; im Ausgangsmaterial wurde keine bestätigte Auswirkung auf Nutzermittel gemeldet.

Quelle: coinpaper | Original-Recherche: Ethan Collins, Hokanews