BNB Chain’s Reth Tests Report 40% Throughput Gain on BSC

BNB Chain said internal tests of an optimized Reth client on BNB Smart Chain showed 40% higher throughput than an earlier Geth configuration using TrieDB. The company also reported a separate 40% improvement in initial synchronization speed against the current BSC-Geth client.

Those two percentages do not describe the same benchmark or baseline. The throughput figure compares Reth with the earlier TrieDB setup, while the synchronization figure compares it with BSC-Geth. The announcement provides no absolute transaction, gas-processing or completion-time measurements to place either ratio against real network capacity.

What changed in the Reth client?

BNB Chain said TrieDB integration enabled trie prefetching and changes to block-production scheduling. The engineering work also addressed state-root computation and data persistence, all areas that affect how a full node processes and stores chain data.

Earlier revisions added parallel sparse-trie processing and adjusted build settings. BNB Chain said those revisions lowered latency for block insertion, execution and validation during full-node synchronization. If reproduced on production hardware, the benefit would be less time required to synchronize a node and process blocks during catch-up.

The caveat is that the client’s 95th-percentile validation latency remained higher than BSC-Geth’s. A faster average synchronization run therefore does not establish that Reth improves every part of validator operation. The announcement does not disclose hardware, software versions, dataset size, run count or variance for either benchmark. For validators, faster synchronization does not erase the remaining tail-latency disadvantage.

Can validators move to Reth now?

Not yet, according to BNB Chain. The company said Reth can handle both historical and live synchronization, but validator migration “remains under development.” BNB Chain also called 1G gas per second its “long-term target” and supplied no migration date.

That target equals one billion gas processed per second, while the associated goal calls for block times below 750 milliseconds, or three-quarters of a second. Neither figure appears as an achieved result in the announcement. The target matters only if the client sustains that capacity on live BSC workloads without worsening the latency measures that already trail BSC-Geth.

Reth’s planned development includes EVM JIT and ASM Hash optimizations. BNB Chain provided no timeline for those changes and no date for validator migration. The absence leaves open basic adoption questions, including when node operators could deploy the client, how many validators could adopt it, and whether BSC-Geth would remain in production use.

For validators, Reth remains a development-stage client rather than a completed BSC deployment.

What would substantiate the gains?

A meaningful follow-up would disclose absolute before-and-after throughput, synchronization times and validation latency under identical hardware, software and dataset conditions. Independent reproduction would also matter because all reported gains come from BNB Chain’s internal testing. The announcement does not say whether results cover mainnet traffic, a test network or a synthetic workload.

That distinction matters because a 40% relative gain can sound larger than its operational effect once measured in blocks per second or hours required to synchronize a node. BNB Chain’s figures provide direction, but not enough data to calculate either outcome.

The next verifiable checkpoint is a dated validator migration and production benchmarks; until both appear, the 40% results remain an internal development claim rather than a completed change to BSC’s client base.