Making Reth Faster on BNB Chain: From Faster Sync to Validator Performance
BNB Chain is advancing its Reth-based execution client through a series of performance improvements designed to support the network's demanding block-production requirements. The development of BSC-Reth has focused on reducing synchronization delays, improving state-root computation and optimizing validator operations.
The work addresses three characteristics that make BNB Smart Chain (BSC) particularly demanding: larger blockchain snapshots, higher observed transaction throughput and much shorter block intervals than Ethereum. BSC's reference snapshot size is approximately 6.6 TB, compared with 1.6 TB for Ethereum. Its observed transaction throughput over a one-hour window reached 246.7 transactions per second, versus 30.81 for Ethereum. BSC also targets a 0.45-second block interval, compared with Ethereum's 12 seconds.
These differences require an execution client that can process transactions, access state data and complete block production within a much tighter timeframe. BSC-Reth's development has therefore involved adapting Reth's architecture to BSC-specific execution and validator requirements.
Why BSC Requires a Different Approach to Reth
Reth is an execution client implemented in Rust, with a modular architecture that provides a foundation for customization. However, adapting it to BSC exposed performance bottlenecks involving state-root computation, storage access and block-production scheduling.
The initial BSC-Reth development focused on improving full-node synchronization. Its optimizations included parallel sparse-trie processing, build configuration adjustments and runtime tuning. Sparse tries allow the client to load relevant data when needed and update hashes along modified paths instead of rebuilding the entire structure.
Three techniques were particularly important: lazy loading and incremental updates, overlapping state prewarming and proof fetching with transaction execution, and parallel processing of independent subtries.
Build-level tuning also played a role. Benchmark configurations used maximum-performance optimization through link-time optimization, CPU-specific code generation with target-cpu=native, accelerated hashing through asm-keccak and the jemalloc memory allocator.
Faster Synchronization Through Parallel Processing
BSC-Reth also uses parallel prewarming to prepare data before it is needed during execution. The process speculatively executes transactions, populates account, storage and bytecode caches, and initiates trie-proof prefetching. Preparing these resources alongside normal block execution can reduce waiting time for state and proof data.
Early synchronization benchmarks showed improvements in several latency measurements compared with BSC-Geth. The results included:
Benchmark metric | BSC-Geth | BSC-Reth |
|---|
Block-insert latency (p95) | 110 ms | 71.6 ms |
Execution latency (p95) | 87.6 ms | 56.5 ms |
Validation latency (p95) | 9.05 ms | 11.2 ms |
BSC-Reth recorded approximately 34.9% lower block-insert latency and 35.5% lower execution latency. However, its validation latency remained higher: 11.2 milliseconds compared with 9.05 milliseconds for BSC-Geth. This showed that faster execution did not automatically eliminate the cost of preparing and calculating state roots.
The remaining work included reducing trie-data retrieval overhead and improving how unchanged portions of the state tree were reused. The BSC-Reth performance report provides further details about the development and benchmark results.
Why Validator Performance Was More Difficult
Full-node synchronization was only the first milestone. Validators also need to prepare and persist state roots while producing blocks within BSC's short timing windows. This made state access, trie processing and scheduling important parts of the optimization process.
An intermediate development stage integrated Geth's TrieDB into BSC-Reth. The team then introduced trie-node prefetching during block production, adjusted execution budgets around validator turn boundaries and modified scheduling to leave more time for state-root completion. RocksDB index and cache settings were also tuned to improve trie-node reads and writes.
These changes improved validator performance, but further bottlenecks remained. Cache misses could force state and trie reads onto the critical execution path. Faster transaction execution also shortened the time available for concurrent trie prefetching, leaving more work for block finalization. Additional overhead came from slice copying, node expansion and memory management.
BSC-Reth also provides FastNode for applications that primarily need access to the latest state. It retains REVM's fast execution while skipping state-root calculation and verification to reduce processing overhead.
Reth 2.0 Improvements Strengthen the BSC Integration
Further progress came from incorporating upstream Reth improvements into BSC-Reth. The Reth 2.0 announcement highlighted three relevant developments: Sparse Trie Cache, partial proofs and Storage V2.
Sparse Trie Cache reuses trie nodes across blocks. The Reth team reported that this reduced the remaining state-root computation after execution to 1–2 milliseconds on Ethereum mainnet benchmarks. Partial proofs retrieve only missing trie segments, cutting proof requests per block by 50%. Storage V2 removes duplicate plain-state tables, moves historical changesets into static files and keeps lookup indexes in RocksDB. The team reported roughly 20 times faster persistence for Gigagas-sized blocks compared with Storage V1.
Bringing these improvements into BSC required additional engineering. The integration added parallel state-root computation to the Parlia miner, allowing state-root work to overlap with transaction execution. It also accounted for BSC-specific state conditions, including unpersisted parent state and system transactions.
Other changes included sharing engine thread pools and changeset caches, starting trie prefetching earlier during out-of-turn backoff periods, and adopting Storage V2 to replace the separate TrieDB backend. Together, these changes brought validator performance to a level that meets production requirements, according to the development report.
Reth 2.5.1 Delivers Further Throughput Improvements
The next development stage incorporated additional improvements to trie processing and state reuse through Reth v2.5.1. The release also included optional transaction-pool prewarming and sender-recovery caching.
The Reth team reported 5–10% lower mean block-processing latency in v2.5.0 compared with v2.4.1. Separate Ethereum mainnet workload measurements attributed a 7% reduction to prewarming and a 3% reduction to sender-recovery caching. These figures are upstream benchmark results, rather than direct measurements of BSC performance. The Reth release notes provide additional technical details.
BSC's integration work included adapting the miner to upstream state-root interface changes, ensuring system updates entered the incremental state-root pipeline and fixing a fork-recovery issue that could leave validators stuck on persisted forks. Scheduling was also adjusted to give the final block in each validator's turn a modestly longer build window.
Across internal benchmark runs, the Reth 2.5.1 configuration recorded roughly 40% higher throughput than the earlier TrieDB-based configuration. This represents progress toward sustained block production, rather than a reported 40% increase in live network throughput.
What's Next for BSC-Reth?
The next priorities include giving block builders more time, improving state access and execution, and preparing the client for validator deployment.
One planned area of evaluation is BEP-675, which could provide additional block-building time and room for higher gas limits. BNB Chain is also evaluating Block-Level Access Lists (BALs), which identify accounts and storage slots accessed during execution. This information can support state prefetching and parallel execution, potentially reducing disk-access delays and block-processing latency. The network's BidBlock development provides further context on block-production improvements.
Execution performance is another focus. The team plans to evaluate EVM2, which reports execution speeds of up to twice those of REVM. Those gains still need to be assessed under BSC workloads.
The current plan is to begin transitioning existing BSC validators to BSC-Reth by the end of 2026. That rollout will be an important next step in determining how the optimized client performs under production network conditions.
