$BNB チェーンのRethクライアントには、「すぐに高速化が実現する」と誤解されかねない数字がある。BNB Chainは11月6日、内部ベンチマークでReth 2.5.1の構成が初期のTrieDB構成よりスループットを約40%向上させたと発表した。ただし、これは稼働中のGethと比較したチェーン全体のスループット向上を示すものではなく、バリデーターの移行も2026年末に開始する計画にすぎない。

まず、別の旧ベンチマークを見ると、議論の争点がより明確になる。BSC-Rethのブロック挿入のp95レイテンシは71.6ミリ秒で、BSC-Gethの110ミリ秒を下回った。一方、検証のp95は11.2ミリ秒で、Gethの9.05ミリ秒を上回った。同期と実行が速くても、状態ルートの計算、永続化、スケジューリングのすべてが、BSCの約0.45秒というブロック間隔の中で余裕をもって完了するとは限らない。公式記事も、こうしたボトルネックがあるため、今後キャッシュ、プリフェッチ、ブロック構築のスケジューリングを改善する必要があると認めている。

$ETH は技術的な参照点となる。RethはもともとEthereumの実行レイヤー向けに開発されたが、BSCはそのアーキテクチャを採用しつつ、異なる状態規模とブロック生成ペースに対応しなければならない。そのため、Ethereumでの最適化率をそのまま当てはめることはできない。$CAKE はオンチェーン取引アプリの利用側を表す。ノード性能の安定がピーク時の取引承認や手数料の体感に結びついて初めて、インフラの進展がこうしたアプリに実質的な意味を持つ可能性がある。もちろん、それが自動的にCAKEの収益につながるわけでもない。

私がより注目するのは、単発のベンチマーク結果ではなく、移行後の連続したブロック生成、ブロック欠落、高負荷時の挙動だ。上記のp95と40%という数字は、BNB Chainの技術ブログに掲載された異なる段階のテスト結果であり、同じ基準で混同してはならない。リスクに関する注意：内部性能テストも将来の導入計画も、メインネットでの性能やトークンの収益を保証するものではない。