In the 24 hours of July 28, Binance Smart Chain (BSC) processed 12.9 million transactions. This number and the below numbers are all from the great BSC network explorer bscscan.com powered by the Etherscan team.
This means 150 transactions per second (TPS) processed on the mainnet, not in isolated environment tests or white paper. If we zoom in, we will also notice that these were not light transactions as BNB or BEP20 transfers, but heavy transactions, as many users were “fighting” each other in the “Play and Earn”, which is majorly contributed by GameFi dApps from MVBII. The total gas used on July 28 was 2,052,084 million. If all these were for a simple BEP20 transaction that typically cost 50k gas, it could cover 41 millions transactions, and stand for 470 TPS.
This is a great achievement, completed by the validators, tens of thousands of BNB delegators, developers, dApp builders and most importantly, the BSC users. Congratulations and massive thanks to all of you participating in the BSC Ecosystem!
On the other hand, with the flood of volume, the network experienced congestion on July 28 for about 4 hours, and many low spec or old version nodes could not catch up with processing blocks in time.
The dev community, including the developers from Binance, dApp project teams and infrastructure project teams, have been working hard to improve the capacity of BSC. The efforts were focused on optimization of EVM, P2P networking, and storage systems. The upcoming improvement is expected not only to benefit the BSC community but also feedback to all EVM related blockchains, including Ethereum.
Some of the short-term enhancements below can address the existing challenges while the community finds a better solution.
A new version of beta client is released which has better performance in order to handle the high volume. Please feel free to upgrade and raise bug reports on Github if you encounter any. Please note this is just a beta version, some known bug fix is on the way. Click here to download the beta client.
To improve the performance of nodes and achieve faster block times, we recommend the following specifications.
– 2T GB of free disk space, solid-state drive(SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms
– 12 cores of CPU and 48 gigabytes of memory (RAM)
– m5zn.3xlarge instance type on AWS, or c2-standard-8 on Google cloud.
– A broadband Internet connection with upload/download speeds of min. 10 megabyte per second.
2. Fullnode operators
1T GB of free disk space, solid-state drive(SSD), gp3, 3k IOPS, 125MB/S throughput, read latency <1ms. (if start with snap/fast sync, it will need NVMe SSD)
– 8 cores of CPU and 32 gigabytes of memory (RAM).
– c5.4xlarge instance type on AWS, c2-standard-8 on Google cloud.
– A broadband Internet connection with upload/download speeds of 5 megabyte per second
If you don’t need an archive node, choose the latest snapshot and rerun from scratch from there.
Although we climbed a new peak, there are higher ones ahead. As more and more users are using BSC, a larger throughput is required and we believe that BSC has the potentia to achieve this. The gas ceiling limit will be gradually raised further, and any constructive suggestion will be more than welcome.
If you have a suggestion or want to propose some improvements, please visit our Github.
If you encounter any bugs, please report them here.