Chains
BNB Beacon Chain
BNB ecosystem’s staking & governance layer
Staking
Earn rewards by securing the network
Build
Explore
Accelerate
Connect
Careers🔥
Explore Opportunities on BNB Chain
State growth is one of the biggest challenges facing blockchains today. For a high-throughput network like BNB Smart Chain (BSC), that challenge compounds quickly.
As one of the industry’s most active networks, BSC’s state has expanded more than 30× faster than Ethereum.
Between January 2024 and May 2025, the full node snapshot grew from 2.45TB to 3.43TB.
This 3.43TB of storage is split roughly as follows:
As BSC’s popularity grew, the rate of state expansion tripled. Including block data, the total state size is projected to reach 2.5–3.0 TiB within three years.
To handle this growth without compromising performance, BSC has developed Scalable DB — a storage model that maintains high throughput under massive data loads and sets the foundation for parallel blockchain execution.
In short, Scalable DB is how BSC stays fast as the chain (and its data) keep growing.
State expiry is often proposed as a solution to blockchain state explosion, and BSC has conducted detailed research on it through the BSC-State-Expiry initiative.
The concept is based on EpochMap metadata, which tracks state access history. If a trie node hasn’t been accessed for two Epochs, it can be pruned. This model also includes a Rent System that records rent balances at the account level, allowing contracts to remain exempt from expiration.
A prototype was implemented to trim expired states using EpochMap metadata, while expired data could still be accessed via RemoteDB for mining and syncing.
However, internal benchmarks revealed significant performance overhead. Instead, the focus has shifted to scaling the data layer itself through Scalable DB.
Given BSC’s current focus on throughput, reliability, and sustained network performance, state expiry will be revisited in the future, but it is not the optimal solution at this stage.
Without state expiry, the growing on-chain data volume creates pressure on the single-database design of the current BSC client.
Currently, all BSC node data (excluding ancient archives) is stored in a single PebbleDB instance, where key prefixes distinguish data types.
As data expands, this approach encounters several limitations:
To overcome these bottlenecks, BSC engineers began redesigning the data layer for horizontal scalability.
BSC will adopt a multi-database architecture combined with state sharding, providing horizontal scalability and consistent high performance.
The BSC client will divide storage into multiple databases. This separation isolates read/write operations, improves parallelism, and enables fine-tuned performance for each data type.
Handles recent blocks, reorg logic, consensus data, and chain metadata.
Stores archived block data, which is reorg-proof and used for full sync or historical data retrieval.
Holds historical transaction indexes, such as the TransactionIndex (277GB and growing).
Because deletion requires scanning historical data, future versions may make this optional, allowing IndexDB to be removed entirely.
Stores flattened state data (including snap journals and metadata) derived from TrieDB for faster state queries in the EVM.
Reducing the LSM tree depth improves I/O efficiency—experiments show a ~5% reduction in read latency on NVMe disks when SnapDB size reaches ~1.5 TiB.
Contains the complete world state trie, following the PBSS schema format.
Contract code is also stored here, with average key-value sizes of ~8KB.
Trie nodes undergo frequent overwrites along ordered paths, making compaction costly if stored alongside hashed data.
By separating TrieDB, compaction becomes simpler, reducing latency and improving database efficiency.
Preserves the historical state of PBSS for exception handling and data recovery, storing the state history of the most recent 360,000 blocks.
Together, these databases distribute workload evenly, reduce contention, and provide a foundation for future scalability.
On top of the multi-DB structure, BSC will introduce state sharding for both SnapDB and TrieDB.
This approach distributes data horizontally, significantly improving write performance and overall scalability.
Each shard will rely on its own disk, enhancing I/O throughput and reducing compaction pressure.
Account keys are generated from hash(address) and storage keys from hash(slot), creating uniformly distributed 256-bit keys.
This allows a sharding algorithm to evenly distribute state data across shards.
Trie nodes stored using PBSS can be efficiently sharded based on trie paths.
Because trie paths are evenly distributed, this approach ensures balanced data distribution and optimal I/O performance.
This ensures that even as the state grows exponentially, performance scales linearly.
Ensuring consistency across shards is a classic distributed systems challenge.
BSC addresses this using a Saga-based distributed transaction approach.
When data is submitted to ShardingDB:
This guarantees all-or-nothing transactions and ensures data consistency even after failure recovery.
In the current BSC client, the state and trie prefetchers already execute transactions in parallel by caching state data.
With state sharding, these reads and writes can now occur concurrently across shards.
Multiple threads can submit state and trie updates to different shards in parallel, collecting write results after execution, which significantly improves total throughput.
Because Scalable DB involves multiple databases, memory management becomes critical.
By implementing a shared cache mechanism, BSC improves resource utilization across all databases.
This optimization allows block caches, filter caches, and index caches to be shared between shards, offering significantly better read/write performance compared to isolated memory allocation.
In essence, Scalable DB uses memory more intelligently, every byte serves multiple databases.
To validate Scalable DB, the team benchmarked the new architecture against the traditional single-DB setup.
Test Setup:
These results confirm Scalable DB’s readiness for mainnet-scale performance and its ability to sustain high throughput as the network grows.
Scalable DB is designed to support BSC’s next generation of performance, scalability, and reliability.
As state growth continues, this architecture ensures the network remains fast and efficient — even under massive data loads.
Scalable DB marks a major leap in BNB Smart Chain’s evolution—built for growth, engineered for speed, and designed to last.
Website | Twitter | Telegram | Facebook | dApp Store | YouTube | Discord | LinkedIn | Build N' Build Forum