In the past 16 months, BSC, or more generally known as the BNB blockchain ecosystem, has established itself to be the most accessible and the most accessed platform for decentralized applications and open finance. This has encouraged and inspired a wider developer audience and decentralized citizens tremendously.
Throughout 2021, BSC achieved a couple of milestones such as over 2M daily active users and highest daily transaction recorded is over 16M transactions far superseded other industry players. As BSC grows, it experiences a couple of challenges such as network congestion and the community has difficulties managing their full node to sync with the latest block.
Hence in 2022 , BSC development teams and community pioneers would like to take the chance to cherish the outlook of the future development directions of the BNB blockchain ecosystem, and to demonstrate the resilience and persistence of the BNB spirits: for the builders and for the users.
The team would like to take this opportunity to list some of the key aspects that should be researched and implemented in the coming months and years, in order to boost the capacity for both users and application integrations. Please note this is not the whitepaper or a detailed technology specification, but only technical goals to inspire the way for the BNB ecosystem to grow. These goals are so ambitious and need more help from developers, researchers and users from the BSC community to input together. We expect the community will gather around the BNB Foundation and advance these dimensions via many work groups.
We strongly believe that the progress of these domains will not only benefit the BNB ecosystem, but also other blockchain communities as well.
All the below directions are marked with a 1-byte index in hex, so that the community can refer that with âOutlook2022.0xâ in the following discussions.
0x00 BSC Throughput Boost
Though many have challenged that BSC chose to scale up the capacity by shorter block time and larger block gas limit. There is strong faith that there is still room to improve the capacity of the current PoSA based BSC.
Based on the past research and investigation, storage has been commonly considered as the major bottleneck. The 17TB data of a BSC archive node / 2TB for a full node on one machine is not sustainable. As a result, storage optimization is the main focus as well.
0x01 Erigon Based BSC Client or Another Storage Model
Erigon, a.k.a the previous âturbo-gethâ, has been striving hard to improve the storage system of Ethereum/Geth in the past 3 years and now blossomed into beta status. Its new storage model with the new database, MPT generation methodology and staged sync has been proven to run much more efficiently than Geth for the large storage. Creating a BSC client based on Erigon will certainly improve the efficiency of the BSC archive node by reducing the storage size and improving the sync time.
Ankr is already contributing to the task. The full node binary is ready to run while the validator mode is being worked on.
Besides the instant benefits, the new storage model of Erigon may also set a better cornerstone for the other storage related optimizations.
One shortcoming of Erigon is that it doesnât support Snapshot Sync yet, which is a must for BSC node runners. The BSC community will work with Erigon to overcome this in 2022.
0x02 Distributed Node
For high performance computing, it is almost impossible to only rely on one node nowadays. The principle of BSC is to allow the node runners to use multiple servers with common hardware specs to support the network, instead of one âbare-metalâ super machine.
Running different functions of a blockchain client on different processes or machines are not new. Erigon proposes to run the RPC function in a standalone process on the same or different machine. The Merge of ETH 2.0 will also decompose the consensus and execution layers onto different client softwares.
A typical blockchain client comprises many functionalities, P2P networking, consensus, RPC service, execution layer etc. Even zooming in these parts, e.g. the execution layer, is composed of many steps, such as the computing of transactions, the state persistence and the generation of different MPT(Merkle Patricia Trie) roots. Decoupling the functions onto different processes and machines can take advantage of the better computing and storage capacity. Some community members have started some trials. However, distributing the node also poses great challenges, especially on synchronization between the distributed sub-nodes without losing the blockchain network security, i.e. the full node operators can easily run the suite of processes to keep the network running with the same level of security but much more capacity.
A straightforward approach may be to arrange the tasks in a âsynchronized, distributed, assembly lineâ (SDAL), due to the sequential characteristics of the blockchain. Some change may be required on the consensus logic to make this type optimization easier. This is also discussed in other blockchains that break sequencing, execution and storage (settlement) into different components.
0x03 Ephemeral Client and Hot/Cold Data Segregation
One foreseeable problem of the current public blockchain is that it stores ALL the data FOREVER. It is very likely that only 20% of the state in the EVM blockchain is still useful, while 80% may not be used much anymore. BSC has more than 121 million unique addresses in Dec. 2021, while daily active addresses are only over 2 million. Many data were created on the blockchain for just one time use and the creators do not bother with calling the SELF DESTRUCT instruction. But the data will be there forever, and accumulated only to break the bones of the archive node.
Ideally there should be an âEphemeral Clientâ, which is a mode between a âfull nodeâ and a âlight clientâ:
- Ephemeral Client starts with a much smaller snapshot of the blockchain, which only contains state of the accounts and contracts that are active in the past 2 weeks or 1 months, with only recent block bodies, headers and receipts, with all other data excluded;
- The excluded accounts and contracts will only be presented as intermediate node of MPT, so that they can still be used to calculate the new MPT;
- Ephemeral Client can work in a similar way as a full node, in the sense that it will execute all the transactions and verify all the data. It should load the excluded data during the execution from another full node or the Portal Network, or even pre-load the excluded data based on the transactions in the mempool.
Apparently sometimes the ephemeral clients may run slower than a full node, but it is a trade-off to make it much easier to run, and run faster.
Deriving from this concept, it is natural to consider separating the hot data from the cold data, which has been a classic technique used in the computing industry. If the EVM blockchain is considered as a âworld computerâ, the memory of the node should be the registers, while the storage can be the RAM (yes, with MPT used in a similar way as ECC in RAM). RAM has never been big enough, so that the data has to be swapped out onto local or/and remote disks. The EVM blockchain needs such âlocal or/and remote disksâ too.
This is not an easy problem to solve:
- Data location is not part of the consensus. It may be easy to mark the data as âswap-outâ or âofflineâ and reach the consensus, but the more important issue is to reach the implicit consensus that âmy proposed block has some transactions that swap in data from the offline modeâ. The short blocking time may not be enough from other validators to respond.
- Some contracts may have a very big storage, which is a great help to swap it out, but very challenging to swap it in as a whole back to âonlineâ.
One potential solution may be:
- Swap the data out by the unit of account and contract when they have not been changed for a long time, and put this as an transaction to get consensus;
- Swap in data by a deterministic set size, which may not be as large as the whole contract data.
- The swapped-in data can be passed in as extra calldata on the block, and the other validators can execute the transactions and verify the data as a âstateless clientâ if they cannot load the data in time.
- The transaction senders will pay extra gas to run any transaction that requires swapping in the data.
A new data layer may emerge due to the requirement to store the cold data.
0x04 EVM Parallelization
Running transactions in parallel for Ethereum has been studied for several years. Solana goes with a native design to enable this as much as possible so that it can take advantage of the powerful GPU.
Based on the analytics of BSC data, the CPU has not been the No.1 bottleneck but the storage is. Even though the EVM parallelization will take better usage of multiple cores of the modern CPUs, the primary goal is to increase the parallelism of storage operation to maximize the SSD usage (even the SATA ones).
In order to maintain backwards compatibility and not change the account structures as Solana does, the most straightforward method is heuristic based, i.e. try-and-rerun-the-failed. The full nodes can do some preprocessing to categorize the transactions in the blocks and mempool into different concurrent workers before actually running them. A lower level instrument monitor will be planted at the storage level, if the race condition is detected, and relevant transactions will be put back into the main worker to rerun in order to generate the correct state. Block producers may even place some hints for others to run the blocks in the most efficient way via the P2P network, though the hint itself is not part of the block.
Besides the parallelization within one block, BSC inherits one limit from Ethereum that the block proposer has to wait until it applies all the previous blocks before it can execute any transactions in its block to propose at its turn. If the previous block proposers send the block late, or the blocks are delayed due to slow network etc, the proposer may not have enough time to execute enough transactions into their blocks and have to propose an empty block or even miss its turn. Tendermint is a good example that solves the above issue. The block proposer on Tendermint network only needs to assemble the block without executing them. How to control the gas used within one block without executing transactions is a difficult topic on the EVM network.
How to run transactions in parallel even among different blocks will be very rewarding here, but it will be very difficult as well.
0x05 EVM JIT Compilation
Using JIT compilation in EVM was proposed and discussed in the early days of Ethereum. When popular dApps dominate the network, such as OpenSea and Uniswap on Ethereum, and PancakeSwap on BSC, and one GameFi dApp had a few million transactions per day, the idea is fascinating that these applications can be compiled into native instructions and able to run faster. This benefits even the compilation is not done âjust-in-timeâ but offline.
However, this is a very challenging feature because it touches the very low level of EVM and can be quite prone to error and security issues. Here is just a placeholder for the talented developers to conquer in the later stage.
0x10 User Experience
Besides the limitation of the block gas limit cap, the other major factor that can impact BSC capacity is the rate of fork. Fork and re-organization of the blockchain can be very costly for both validators and fullnode.
0x11 Fast Finality
Although BSC is designed to produce blocks every 3 seconds, it is recommended to wait until more than half of the validator set has produced new blocks on the block before the block can be confirmed in a probabilistic manner. This will cost at least 3x11 = 33 seconds after the block is visible on the network.
As the validator set is well known every 24 hours, BSC can get a faster consensus on the longest chain based on the âattestationâ from more than a certain percentage of the validator set considering it is the longest chain.
This essentially requires altering the âParliaâ consensus mechanism of BSC. A BEP candidate has been proposed by the community at [WIP] BEP-97: Introduce Fast Finality Mechanism by KeefeL ¡ Pull Request #126 ¡ binance-chain/BEPs ¡ GitHub .
0x20 Decentralization Further
0x21 Candidate ValidatorSet
In order to decentralize the network further, more validators should be introduced. Besides increasing the anti-censorship, it always increases the robustness and availability of the network. BSC should survive even if more than half of the validator set were censored or taken down in a hostile way.
Meanwhile BSC has 21 active validators and many inactive validators. The inactive validators have no reward so the incentive for the runner to ensure the node quality and the delegation from the BNB holders are not enough.
BSC will introduce more validators, e.g. another 20 inactive validators, into the validator set as backups, which will be called âCandidatesâ.
Candidates will produce blocks and charge gas fees in BSC mainnet, but in a much less chance than the official validator set of 21 elected. The unavailable candidates will be slashed as well though in a smaller size. A decent motivation is expected to be maintained so that the candidate validators are willing to ensure the quality and help secure BSC.
In an extreme case, if a majority of the active 21 validators get attacked and offline, Candidate Validators can report to Binance Chain about the stale blocking, resume it and eventually propose a re-election of active validator set.
0x22 Temporary Maintenance Mode for Validators
Due to the design of âParliaâ consensus, the absence of the validator, even if it is due to scheduled maintenance, will cause instability and capacity of BSC due to the extra waiting time and chain reorganization.
Here a âTemporary maintenanceâ mode should be introduced, which is supposed to last a few minutes to half an hour. The validator can claim to the network about its planned maintenance. Its seat will be temporarily dropped from the block producing rotation, though it will still be slashed.
0x30 Sharding and Multi-chain
The sections above all focus on how to improve BSC as the single blockchain. However, the BNB community has never believed in the âone-chain-fits-allâ theory. As the decentralized computing infrastructure, the blockchain will bear the same principle of diversification among generalization and specialization. Also the blockchain is a computing resource, which is scarce as other resources. No users will expect their favorite games and/or social media applications to contend computing resources from their financial ledger and business transactions, let alone they expect all these applications to charge the same price.
The team strongly believe sharding and multiple blockchain are the future for the non-stop increasing demand for decentralized computing power and storage. This is consistent with many of the blockchain industry, such as ETH2.0, and multi-chain strategy in Polkadot, Cosmos and Avalanche.
The cross-shard and cross-chain communication will be the key topic. Here 2 types of sub-chains are discussed below, which are both initial proposals and call for comments.
0x31 BSC Application Sidechain (BAS)
BSC Application SideChain is an infrastructure introduced to help developers and practitioners to build and run their own blockchain as their internal value system for a massive user application, while still maintaining a close connection with BSC.
The âmassive user applicationâ here means a sustainable dApp with 1 million daily active users. dApps with such size are expected to have an obviously endogenous economic and social ecosystem, and can run on a standalone base system. The typical types of such applications that have been seen so far are GameFi and SocialFi.
From technical perspective, BAS is defined as:
- The sidechain runs as a PoS network, separately and independently from BSC, i.e. all BAS will keep running even BSC is down.
- The sidechain is fueled by its dedicated own application token as gas.
- The application gas token and its relevant tokens can easily go onramp to / offramp from BSC, without additional trust setup or key management.
- No BSC tokens, including BNB and BEP20 issued on BSC, should be transferred onto BAS under the same security model as BASâ own tokens. It is encouraged that all tokens should be traded on BSC for better liquidity and security setup.
- Potential shorter blocking time than BSC.
A typical BAS will be a fork of BSC, which still runs an EVM compatible, PoSA based network. It can get all the features BSC has and continuously inherit all the performance enhancements.
BAS Infra
In large chance, BAS runs with a smaller validator set than BSC, as the application owners decide. These validators can be run by the application owners or any stakeholders of their community. As the main assets on the BAS are the application-centric, the community and the developers of the application should work well as/with these validators to protect the security of the BAS. BAS will support staking. The staking and validator election logic will be handled by system contracts, which will rebase every N epochs.
Community infrastructure providers can help with the basic setup on:
- RPC API and archive nodes
- Simple blockchain explorer solution
BSC/BAS Cross-chain
One of the most common growth paths of BAS is a big game studio invests its next masterpiece of high potential with the blockchain base; while the other can be a good GameFi dApp got a large amount of users from BSC and wants to expand with larger capacity, cheaper fees and tighter control on the model. The two paths both need a place to dispatch their tokens and trade their assets with the potential users base, and BSC can naturally be the one. So cross-chain asset flow is a must-have requirement.
However, as the security of the BAS is guaranteed by PoS validators elected via the designated way that application owners specify, it may not be the same level as BSC itself. So the cross-chain asset flow should focus on the assets that application owners can/should endorse.
The new asset type for such flow should be defined by new BEPs and deployed by application owners. Let it be BEP120 in this document.
The cross-chain communication for BEP120 token transferring will be built-in based on the above and below descriptions:
- The BEP120 tokens can be created on both BAS and BSC, and binded via cross-chain package.;
- Smart contracts will work on BAS and BSC to handle the binding between BAS to BSC and also serve as vaults to lock the local assets on BAS in order to mint the corresponding on BSC;
- BAS validators should run Relayers, which may be built-in to the side chain tool set. The relayers will submit transactions with the cross-chain package and attestations onto BSC and BAS, where smart contracts will handle the cross-chain package after verifying the attestations. Particularly, if BAS is BSC fork, the relayers can use validator consensus key to attest the cross-chain package, while the contract on BSC can verify the attestment and also potential validator set change messages.
If BAS supports EVM, the openness and programmability can enable the applications to create more evolvable capability. While the interaction of the local assets with BSC assets are encouraged to happen on BSC, BSC can help BAS in the below aspects:
- Platform to distribute the applications, either through IDO or airdrop to attract users
- Reuse the existing DeFi lego to centralize token liquidity
- Channel to connect with other cross-chain bridges and centralized exchanges
0x32 BSC Partition Chain (BPC)
A BPC introduces another sub space with a new validator set, a new computing engine, and a new ledger. Essentially it works as a âshardâ or a âlayer 2â to off load part of the data, computing and transactions from BSC.
As indicated in the name, while BSC serves the major financial related dApps, BPC presents an additional partition to accommodate more generic applications which expects more on-chain transactions for intensive user interactions and require less gas fees.
BPC will support almost all the functionality of BSC:
- It will use BNB as the gas and for the staking
- It will have similar infrastructure such as RPC full node, archive node and blockchain explorer as BSC;
- All tokens, including BNB and BEP20, can bind and flow freely between BSC and BPC natively.
BPC starts with a fork of the BSC code base, assembled as a PoSA blockchain. Anyone can create themselves as a validator for one or more particular BPC on Binance Chain, which serves as the âbeacon chainâ here. The validators can call for delegation in order to be elected into the validator set of BPC. The election can work in the similar way as BSC and refreshes every 24 hours.
On day 1, there may be only one BPC established, as the pioneer and experiment for the technology. There can be more BPCâ as the network develops. Also as different services can be moved around different servers, new technologies should be developed to allow dApps to move around BSC and BPCs in the future days.
BPC Security
BPCâ security will be first guaranteed by the validator set of BPC. The individual unstable or/and malicious validators will be marked and slashed eventually, which follows the same logic as the current BSC. Furthermore, as BPC usually gets staked with less BNB, its security will be guaranteed by another layer of attestation and validation. The goal is to detect the scenarios that majority of the BPC active validators are not trustful and recreate the network with other candidate validators. A proposal is discussed in the later sections.
BSC/BPC Cross-chain
It is considered that there will be no direct cross-chain communication among multiple BPC, or multiple BAS, or between BPC and BAS. These communications will have to go through BSC. The major reason for this is more from a token economy point of view. It is expected that BSC will be specialized for DeFi related applications and exercise the network effect by concentrating all the liquidity.
The cross-chain package between BPC and BSC will be wrapped as special transactions, and will focus on token assets, literally BNB, BEP20 tokens and NFTs, instead of any type of state data change. The cross-chain token actions usually have two types. One is âbindâ, which will peg the token on the local blockchain to the same token on the other blockchain; the other is âtransferâ, which will move the token asset between the two blockchain, literally lock/burn the amount of tokens on the source blockchain and release/mint the same amount of tokens on the target blockchain.
As the tokens on BSC, which usually has high stake, flow onto BPC, which usually has less stake, an attestation and verification logic should be there to justify to both sides about the transfer.
Beacon Chain Attestation
Binance Chain serves the validator set update for both BSC and BPC via cross-chain package. Its validator set should be credible and further enhanced to be so, which may be discussed and evolved in another track.
If the validator set updates are credible, the messages co-signed by more than â of the validators of Binance Chain should be credible too. This makes Binance Chain (BC) de facto the Beacon Chain for BSC and BPC.
In such a sense, BC validators can attest the security of BPC. All the validators should have the responsibility to monitor BPC, attest the blocks and store the canonical chain onto BC for othersâ reference.
Besides, BC validators can also attest the cross-chain communication between BSC and BPC.
For BSC to BPC bind/transfer:
- A system smart contract call will be triggered to burn/lock the asset on BSC and emit the event;
- The BC validators should attest a cross-chain package for this transfer, and submit as a transaction onto BPC after the containing block of BSC is finalized.
- BPC executes the transaction, and the smart contracts verify the attestation and mint/release token out.
For BPC to BSC bind/transfer:
- A system smart contract call will be triggered to burn/lock the asset on BPC and emit the event;
- The BC validators should attest a cross-chain package for this transfer, and submit as a transaction onto BSC after the containing block of BPC is finalized.
- BSC executes the transaction, and the smart contracts verify the attestation and mint/release token out.
BC attesters will share the fees for cross-chain communication. These fees will become part of the income of BC validators, which should be further subject to delegation distribution and also BNB burn on BC.
0x40 Buidling For the Community, With the Community, and By the Community
BNB has been on a journey. BSC is not the end, but another start. BSC is a testimony on how a great ecosystem can be co-built by the community. The same as other blockchain projects, the secret sauce of the success always includes the attitude to be more open, inclusive, collaborative, persistent and down-to-earth.
The research and development of the BNB ecosystem, with BSC as the first major inception point, will go further down the road to embrace the community, open source, and collective intelligence, which are essentially the good part of decentralization.
That is why we put this as a topic to push hard on persistently, for now and for the future.