Table of Contents
Data Archive Layer
The concept of a Stateless BSC client was conceived with the primary aim of mitigating BSC`s unbounded state growth. This challenge is more important to BSC compared with ETH because of the BSC’s larger block size and shorter block time. The Archive Data Layer, which is known as the BNB Chronicle is a network built on BNB Greenfield that enhances long-term data availability while maintaining trustlessness and decentralization.
The BNB Chronicle provides RPC endpoints that are fully consistent with BSC full nodes for retrieving block and blob data from the genesis block. Additionally, it has open-sourced a lightweight and stateless BSC client that can connect to both the BSC P2P network and BNB Chronicle. This client can serve historical data requests from BSC nodes on the network, as well as offer local RPC access for querying blocks.
BNB Chronicle does not compete with commercial RPC service providers in terms of performance and functionality. Instead, it enhances the data security of the blockchain network, ensuring that in the future, as blockchain data continues to grow, the BNB Chain network will always have a complete historical dataset. Moreover, this data can be accessed in a decentralized and permissionless manner.
Why do we need the BNB Chronicle
Full Node Storage Challenge
As the BNB Chain grows, running a full node becomes increasingly resource-intensive. According to BNB Smart Chain Annual Storage Report 2024, the total storage size of a BSC full node increased to 2.45TiB. The following visualization shows that block data takes up the majority of the storage.
The substantial block size presents several challenges.
One key issue is the necessity to store all blocks from the genesis block to the most recent, consuming extensive disk space that will only continue to grow. However, executing the most recent blocks does not require access to historical block data. This situation presents an opportunity to explore optimization techniques that could potentially reduce the storage needs of a node by excluding this historical data, like EIP4444 and BEP283.
However, this also raises another question: if full nodes do not store historical blocks, then who will be responsible for storing these historical blocks and providing a decentralized, permissionless query interface?
Permanent Layer 2 DA
Another problem is the long term data availability of layer2. BNB Smart Chain has introduced a major upgrade called BEP336. This upgrade, modeled on Ethereum’s EIP 4844, seeks to significantly reduce costs for Layer 2 rollups by providing a dedicated blob space for rollup data.
The blob space guarantees access to newly created data, but it does not provide access to the entire historical data. For example, BEP336 will discard blob data older than 18 days.
The BNB Chronicle aims to permanently store the historical block and blob data across the Greenfield network. As Greenfield is a decentralized storage network, these historical block data possess characteristics of immutability, resistance to loss, and permissionless access. With the BNB Chronicle in place, BNB Chain’s long-term data availability is greatly enhanced, and there is hope for further reduction in the hardware costs of nodes in the future.
Architecture Design
The BNB Chronicle comprises three main components:
- Block/Blob Indexer: This service continuously indexes blocks and blobs from the blockchain and stores them in Greenfield. It ensures no block is missed and that each stored data is accurate.
- API Server: This component serves requests for historical block and blob data, providing seamless access to the stored data.
- Light Peers: It is a blockchain client that is backed by Greenfield storage but can serve in the P2P network.
The indexer leverages the Bundle Service to combine a range of blocks and blobs into a single bundle and upload to Greenfield. This approach optimizes storage usage, and Greenfield will ensure the data integrity and accessibility.
The indexing process ensures data integrity by running a post-verification process. This process scans all uploaded blocks, conducts validation checks against data already stored in Greenfield, and detects any missing data.
Comparison
Portal Network and EthStorage are similar networks of Ethereum ecosystem that provide long-term data availability. We compared these three networks across various dimensions.
| BNB Chronicle | Portal network | EthStorage | |
| Decentralized | Good | Excelent | Excelent |
| Incentive | No | No | Yes |
| Support historical state query? | Possible in future | Possible in future | No |
| Support Block query? | Yes | Yes | No |
| Support Blob query? | Yes | No | Yes |
| DA Proof | Proof of challenger | No | Data availability sampling (DAS) |
| Data accuracy guarantee | No | No | KZG |
| Access latency | 0.8s – 0.9s | 4.5s-4.8s | 1.2s -1.3s |
Access the BNB Chronicle
The BNB Chronicle supports BSC now and its API is fully compatible with Ethereum API specifications, ensuring ease of integration for developers.
In scenarios where the RPC is inaccessible, direct access to block data stored in Greenfield is necessary, this ensures that data is always accessible in any cases. Users can retrieve the bundle object and extract specific data from it using command line or SDK, check BSC Docs for more details.
You can also explorer the storage in the Greenfield Scan directly:
Outlook
Incentive Mechanism(In Design)
In the future, BNB Chronicle aims to have an incentive and decentralization mechanism, which will enable builders to provide the service for the community.
BNB Chronicle is built on Greenfield, and storing data on Greenfield incurs certain costs, which are currently covered by BNB Chain funding.
Introducing an incentive mechanism not only covers storage costs but also attracts more data uploaders and maintainers, achieving better decentralization.
A viable approach is to fully utilize BNB Chain’s system reward contract and the inherent cross-chain functionality between BSC and Greenfield:
- A small portion of the transaction fees on the BSC network goes into the system reward. We can use these funds, periodically transferring them across chains to the Greenfield network, to pay for BNB Chronicle’s network fees.
- The Greenfield network periodically synchronizes block header information to the BSC network. By submitting Merkle proofs on the BSC network, we can prove the existence of certain files on Greenfield. After proving the files’ existence on Greenfield, both the file submitters and proof submitters can receive rewards.
Historical State
BNB Chronicle currently offers limited functionality, supporting only the querying of blocks and blobs while lacking the capability to access historical blockchain states. However, recent advancements in blockchain technology, particularly the innovative world state storage model introduced in Erigon v3, present a promising solution to this limitation.
The new design in Erigon v3 enables the storage of historical state data in an append-only file format. This approach is ideally suited for integration with Greenfield’s immutable file storage system. By leveraging these advancements, BNB Chronicle has the potential to evolve into a comprehensive, global archive node. This would significantly enhance its utility, providing users with access to not just current blockchain data, but also the entire historical state of the network.
Call for Action for BNB Builders
Data Analysts and Researchers
BNB ChronicleShadownetwork offers a valuable resource for data analysts and researchers who need comprehensive access to historical block data. By leveraging it, they can collect reliable data for analysis, research, and development purposes.
Light Peer
If anyone doesn’t want to trust centralized API service providers and doesn’t want to run a full node, they can run a BNB Chronicle light peer.
Greenfield provides storage for the light peer, which is stateless, meaning it can start and operate quickly. Like a full node, the light peer can handle local block data requests and connect to the network to help other nodes with historical block information.
Node Operators
The Greenfield community has launched several BNB Chronicle light peers capable of serving historical block requests. Node operators requiring full synchronization from the genesis block can simply add these BNB Chronicle light peers to their node’s static peers list.
