Der Reth-Client der $BNB Chain hat eine Zahl vorzuweisen, die leicht als „beschleunigte Umsetzung“ missverstanden werden kann: BNB Chain gab am 6. November bekannt, dass die Reth-2.5.1-Konfiguration in internen Benchmarks einen rund 40 % höheren Durchsatz als frühere TrieDB-Konfigurationen erreichte. Das bedeutet jedoch keine Steigerung des Gesamtdurchsatzes der Chain gegenüber dem derzeit produktiv eingesetzten Geth. Die Migration der Validatoren soll zudem erst Ende 2026 beginnen.
Ein Blick auf eine andere, ältere Benchmark-Reihe zeigt besser, worin die Kontroverse liegt. Die p95-Latenz beim Einfügen von Blöcken lag bei BSC-Reth bei 71,6 Millisekunden und damit unter den 110 Millisekunden von BSC-Geth. Die p95-Latenz bei der Validierung betrug jedoch 11,2 Millisekunden und lag damit über den 9,05 Millisekunden von Geth. Schnellere Synchronisierung und Ausführung bedeuten nicht, dass Zustandswurzelberechnung, Persistierung und Blockplanung innerhalb des bei BSC rund 0,45 Sekunden kurzen Blockintervalls problemlos abgeschlossen werden können. Der offizielle Artikel räumt ebenfalls ein, dass aufgrund dieser Engpässe noch Verbesserungen an Caching, Vorabruf und Blockerstellung anstehen.
$ETH dient hier als technischer Bezugspunkt: Reth wurde ursprünglich für die Ethereum-Ausführungsschicht entwickelt. BSC hat zwar die Architektur übernommen, steht aber vor anderen Herausforderungen hinsichtlich Zustandsumfang und Blocktaktung. Optimierungswerte von Ethereum lassen sich daher nicht einfach übertragen. $CAKE steht für die Nutzungsseite der On-Chain-Transaktionsanwendungen. Nur wenn sich die Node-Leistung zuverlässig in Transaktionsbestätigungen und Gebühren während Spitzenzeiten niederschlägt, kann der Fortschritt bei der Infrastruktur für solche Anwendungen praktisch relevant sein – und selbst dann wird daraus nicht automatisch Umsatz für CAKE.
Mich interessieren die kontinuierliche Blockproduktion, verpasste Blöcke und die Leistung unter hoher Last nach der Migration mehr als ein einzelner Benchmark-Lauf. Die oben genannten p95-Werte und 40 % stammen aus Tests verschiedener Phasen im technischen Blog von BNB Chain; die Benchmarks lassen sich nicht miteinander verrechnen. Risikohinweis: Interne Leistungstests und künftige Bereitstellungspläne garantieren weder die Leistung im Mainnet noch Token-Erträge.
Ein Blick auf eine andere, ältere Benchmark-Reihe zeigt besser, worin die Kontroverse liegt. Die p95-Latenz beim Einfügen von Blöcken lag bei BSC-Reth bei 71,6 Millisekunden und damit unter den 110 Millisekunden von BSC-Geth. Die p95-Latenz bei der Validierung betrug jedoch 11,2 Millisekunden und lag damit über den 9,05 Millisekunden von Geth. Schnellere Synchronisierung und Ausführung bedeuten nicht, dass Zustandswurzelberechnung, Persistierung und Blockplanung innerhalb des bei BSC rund 0,45 Sekunden kurzen Blockintervalls problemlos abgeschlossen werden können. Der offizielle Artikel räumt ebenfalls ein, dass aufgrund dieser Engpässe noch Verbesserungen an Caching, Vorabruf und Blockerstellung anstehen.
$ETH dient hier als technischer Bezugspunkt: Reth wurde ursprünglich für die Ethereum-Ausführungsschicht entwickelt. BSC hat zwar die Architektur übernommen, steht aber vor anderen Herausforderungen hinsichtlich Zustandsumfang und Blocktaktung. Optimierungswerte von Ethereum lassen sich daher nicht einfach übertragen. $CAKE steht für die Nutzungsseite der On-Chain-Transaktionsanwendungen. Nur wenn sich die Node-Leistung zuverlässig in Transaktionsbestätigungen und Gebühren während Spitzenzeiten niederschlägt, kann der Fortschritt bei der Infrastruktur für solche Anwendungen praktisch relevant sein – und selbst dann wird daraus nicht automatisch Umsatz für CAKE.
Mich interessieren die kontinuierliche Blockproduktion, verpasste Blöcke und die Leistung unter hoher Last nach der Migration mehr als ein einzelner Benchmark-Lauf. Die oben genannten p95-Werte und 40 % stammen aus Tests verschiedener Phasen im technischen Blog von BNB Chain; die Benchmarks lassen sich nicht miteinander verrechnen. Risikohinweis: Interne Leistungstests und künftige Bereitstellungspläne garantieren weder die Leistung im Mainnet noch Token-Erträge.
