Table of Contents
Rational
Currently, in BNB Smart Chain (BSC), the predominant client options are Geth and Erigon. Geth holds a market share of 56.2%, while Erigon accounts for 43.8%. As Erigon implements a cutting-edge storage model which is quite different from Geth. At the same time, by validating alongside the Geth client, the Erigon client can also effectively assist in identifying bugs within the Geth implementation. However for the opBNB network, the only supported client is op-geth. Users will be unable to access the opBNB network if op-geth has a problem.
So encouraging and maintaining a more diverse set of clients is an important mission for BNB Chain. A client with totally different implementation(think different programming languages, etc) is what we expected. Rust has caught our attention due to its impressive secure programmability and excellent performance.
Adding support for Reth
BNB Smart Chain has backed two Rust implementations:
- open-bsc which is based on open-ethereum. However, open-ethereum ceased maintenance in 2022.
- bsc-akula which is based on akula. The project ceased maintenance in late 2022.
After that, Paradigm announced Reth: a new full-node implementation of the Ethereum protocol, with an Apache/MIT license, focused on contributor friendliness, modularity, and performance. The performance of Reth 1.0 is promising, and the teams share a clear path towards 1 gigagas per second. Therefore, providing long-term support for BSC and the opBNB network on Reth can not only enhance client diversity on the BNB Chain but also empower the Reth team to build more modularly.
Diversifying BNB Chain’s execution clients with Reth has several extra benefits:
- Increased security: Reth will make the BNB Chain more resistant to attacks.
- Improved efficiency: Reth is being designed to be more storage efficient than Geth.
- Increased scalability: Reth can be easily integrated with Revmc and Execution Extensions, making it more scalable.
- Greater decentralization: Reth will focus on community governance, making BNB Chain more decentralized
Benchmark of Reth on opBNB and BSC
Paradigm revealed their benchmarks results in this post based on the Ethereum network. Due to the numerous differences between opBNB/BSC and Ethereum, we would like to present the initial findings from our latest benchmarking in the sections below.
We benchmark Reth(v1.0.0), op-nodes(v0.4.2) on AWS i4g.4xlarge(16 core 128G) instance with NVMe SSD for opBNB, and lm4gn.8xlarge(32 core 128G) with 2 x 7500 NVMe SSD for BSC.
Stage Sync
The Reth supports Stage Sync which is rearchitected for better performance for the initial sync from genesis and Live Sync. The following table displays the total time to stage sync and storage distribution after catch up on opBNB network:
Benchmark for opBNB Reth v1.0: Stage Sync
| Size | Archive Node | Full node |
| Total | 930G | 655 |
| MDBX | 568G | 293G |
| MDBX Free List | 15.8M | 18.2M |
| Static Files | 362G | 362G |
| Time | Archive Node | Full node |
| Total | 53.38h | 49.9h |
| Headers | 10min | 10min |
| Body | 129min | 129min |
| Sender Recovery | 246min | 246min |
| Execution | 2580min | 2546min |
| Account Hashing | 1min | 1min |
| Storage Hashing | 25min | 21min |
| Merkle | 17min | 18min |
| Transaction Lookup | 22min | 23min |
| Index Storage History | 106min | – |
| Index Account History | 67min | – |
The result shows an encouraging 690 MGas/s result on historical sync in the last 1M blocks (the historical sync numbers represent pure execution time during “backfills”).
For the BSC network, syncing from genesis takes significantly longer, as BSC launched much earlier than opBNB. The process requires approximately 24 days for a full node and about 30 days for an archive node. The result shows an encouraging 621MGas/s (full node) and 516MGas/s (archive node) result on historical sync in the last 500K blocks [~ 40000000 – 40500000]. (the historical sync numbers represent pure execution time during “backfills”).
Given the extended duration required for stage synchronization of the BSC network, the BNB Chain team is developing a segmented snapshot download solution, scheduled for release in the near future. Currently, developers seeking to expedite the process can obtain archive node snapshots from community-maintained repositories. These snapshots offer a faster alternative to syncing from genesis, allowing for quicker node setup and network participation.
The table below presents a comprehensive overview of the current storage requirements and data distribution for both BSC archive nodes and full nodes.
Storage size of BSC Reth v1.0
| Size | Archive Node | Full node |
| Total | 6.89T | 3.75T |
| MDBX | 4.44T | 1.37T |
| MDBX Free List | 188G | 108G |
| Static Files | 2.27T | 2.28T |
Live Sync
For the BSC network, we conducted an observation of the metrics for blocks [40,875,000, 40,880,000], the live sync performance is around 195 MGas per second.
The live sync performance on the opBNB network is not very optimistic. We conducted an observation of the metrics for blocks [30467068, 30429919].
Benchmark for opBNB Reth v1.0: Live Sync
| Archive Node(MGas/s) | Full node(Mgas/s) | |
| Execution + merklization+ Commit DB | 43.65 | 42.69 |
| Execution | 133.80 | 138.63 |
The main reason for the underperformance of Live sync is that mdbx is not a write-friendly database. The commit db at the end of block execution takes up several tens of milliseconds, a challenge that becomes more pronounced for fast-blocking layer 2 solutions like opBNB. We get a similar conclusion with Reth team:
Call for action
Thanks to the Paradigm team for their continuous iterations on Reth, providing the community with a highly scalable, modular, high-performance, and feature-rich client. We stand on the shoulders of giants, enabling us to swiftly launch the Reth supporting BSC and opBNB network versions. The Reth is entering production-ready v1.0.0 now.
The BNB Chain community is invited to take the following actions to support the integration of Reth as a complementary execution client:
- Explore Reth: Familiarize yourself with Reth’s documentation, features, and roadmap. Visit the Reth website or GitHub repository to learn more.
- Join the Discussion: Participate in online forums to share your insights, questions, and suggestions.
- Test and Validate: If you are a node operator, consider running a Reth node on a testnet or mainnet to evaluate its performance and stability.
- Provide Feedback: Share your feedback with the client development team, highlighting any issues, bugs, or potential improvements. Your input is invaluable for shaping the future of Reth and the BNB Chain.
- Spread the Word: Raise awareness about Reth among your peers, colleagues, and fellow BNB Chain enthusiasts. The more people know about this exciting development, the stronger the community support will be.
Together, we can create a more secure, efficient, scalable, and decentralized BNB Chain by embracing Reth as a valuable addition to the execution client ecosystem.
Outlook
In the BNB Chain 2024 tech roadmap, building the highest performance EVM platforms stands as a crucial milestone. Paradigm Reth’s proposal for achieving 1 gigagas per second and beyond shares a similar mission with BNBChain. In the short term, the team will be incorporating the optimization experience we have accumulated on BSC/opBNB Geth into the Reth client, including parallel prefetch, fast finality, multi layer cache.
BNB Chain will continue to expand the usage scenarios of Reth in the long term, such as Reth becoming a validator for BSC and a sequencer for opBNB. Meanwhile, The team is committed to advancing several key features on Reth, like Parallel EVM, State Expiry, Consecutive Blocks, which also match with Paradigm Reth’s vertical scaling goals.
