Hello, I'm Jacko, because I started to synchronize the data of the BSc (coin security intelligent chain, hereinafter referred to as BSC) node from Block 0, but I haven't caught up with the latest block. After discussion with others, I finally synchronized the snapshot data of the main network of the BSC node to the latest block. In this article, we will start the BSC master network snapshot data in binary mode to see how long it will take to catch up with the latest block.
- BSC snapshot official: https://docs.binance.org/smart-chain/developer/snapshot.html
- BSC snapshot GitHub: https://github.com/binance-chain/bsc-snapshots
Before starting this document, briefly describe the BSC synchronization:
- Server environment
Server: alicloud server CPU: 8 nucleus Memory: 16 GB Data disk: 1 T Efficient cloud disk Bandwidth: shared 10 M
- software environment
centos 7.7
Since the previous process of synchronizing from Block 0 has been used, about 10 days have passed, and the status data of the BSC main chain node is still not synchronized, this time, the BSC snapshot data is used to test the synchronization again:
I downloaded the snapshot data of BSC at 9 p.m. on July 20, 2021. At that time, the latest data was the snapshot data on July 14, 2021. At the time of writing this article, the latest snapshot data was July 22, 2021;
It took me about a few hours to download the snapshot data. At that time, the extracted data was about 401gb;
At 9:25 a.m. on July 22, 2021, I started the BSC main network node using the downloaded BSC snapshot data, and then silently waited for the synchronization to complete;
Finally, at 18:23 on July 23, 2021, the latest block of the latest BSC main network: 9405825;
After a rough calculation, the BSC snapshot data is used to synchronize the main network node data. The synchronization time is about 8 hours and 58 minutes a day; Note: this synchronization time is only for personal use, and the synchronization time also needs to refer to the current environment.
During this synchronization, the resource usage of the server is as follows:
cpu: 4 nucleus Memory: 12 GB Bandwidth: 2 M Disk: 536 G
Next, stop talking nonsense and start the practical steps immediately
Start BSC primary network snapshot data using binary
1, Download bsc master network snapshot data
- Download bsc master network snapshot data
cd /opt/docker/bsc/ nohup wget https://s3.ap-northeast-1.amazonaws.com/dex-bin.bnbstatic.com/geth-20210714.zip?AWSAccessKeyId=AKIAYINE6SBQPUZDDRRO\&Expires=1628936991\&Signature=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA%3D &
- Decompress the bsc main network snapshot data
unzip geth-20210714.zip\?AWSAccessKeyId\=AKIAYINE6SBQPUZDDRRO\&Expires\=1628936991\&Signature\=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA\=
2, Download BSC binaries
- Download BSC binaries
cd /opt/docker/bsc/server wget https://github.com/binance-chain/bsc/releases/download/v1.1.0-beta/geth_linux
- Grant executable rights
chmod 777 geth_linux
3, Download the master network configuration file and Genesis block file
- Download the master network configuration file and Genesis block file
cd /opt/docker/bsc/server wget $(curl -s https://api.github.com/repos/binance-chain/bsc/releases/latest |grep browser_ |grep mainnet |cut -d\" -f4)
- Unzip the downloaded file
unzip mainnet.zip
- Modify the BSC primary network configuration file
HTTPHost: HTTP-RPC Service connection whitelist. The default value of this parameter is "localhost"，Only local access is allowed, which can be set to:"0.0.0.0" HTTPVirtualHosts: HTTP-RPC Service listening interface,The default value of this parameter is ["localhost"],Can be set to: HTTPVirtualHosts = ["*"]
4, Binary boot BSC main network
- Install the window manager tool under linux: screen
yum -y install screen
- Start the BSC master node
screen -S bsc /opt/docker/bsc/server/geth_linux --config /opt/docker/bsc/server/config.toml --datadir /opt/docker/bsc/server/node --cache 18000 --rpc.allow-unprotected-txs --txlookuplimit 0
Parameter Description:
– config: Specifies the BSC node configuration file
– datadir: Specifies the data directory of the BSC node database and keystore (default: "/ root/.ethereum")
– the larger the internal cache, the more memory is allocated (default: the larger the internal cache, the more data is allocated for each synchronization)
–rpc. Allow unprotected TXS: allow unprotected (non EIP155 signed) transactions to be submitted via RPC
– txlookuplimit 0: disable deleting transaction indexes
- View startup log
cd /opt/docker/bsc/server/node/ cat bsc.log.2021-07-22_09
- Log description
// Preset various configurations of BSC main network nodes:
t=2021-07-22T09:25:01+0800 lvl=warn msg="Sanitizing cache to Go's GC limits" provided=18000 updated=5338
......
// Initialize chain configuration
t=2021-07-22T09:25:02+0800 lvl=info msg="Initialised chain configuration" config="{ChainID: 56 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: 0, Ramanujan: 0, Niels: 0, MirrorSync: 5184000, Berlin: <nil>, YOLO v3: <nil>, Engine: parlia}"
......
// Load the latest header file
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local header" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
// Load the latest complete block
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local full block" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
Load the latest fast block
t=2021-07-22T09:25:02+0800 lvl=info msg="Loaded most recent local fast block" number=9,154,718 hash=0xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td=18,241,589 age=1w8h25m
......
// The synchronization mode is switched from fast synchronization to full synchronization
t=2021-07-22T09:25:03+0800 lvl=warn msg="Switch sync mode from fast sync to full sync"
......
// Start p2p network
t=2021-07-22T09:25:03+0800 lvl=info msg="Started P2P networking" self=enode://878a50bbcf1f6fe820d53315decd1c540de1570c967125561484a2819e7a66c4f1df8157cbcf1979bb3d245aadb3073a86c1d8941793b8984ecd8015be479cdd@127.0.0.1:30311
// Block synchronization start
t=2021-07-22T09:25:13+0800 lvl=info msg="Block synchronisation started"
......
// Synchronize to new data chain
t=2021-07-22T09:25:27+0800 lvl=info msg="Imported new chain segment" blocks=3 txs=793 mgas=115.754 elapsed=8.585s mgasps=13.483 number=9,154,721 hash=0xaa97db3864f0002b4bec4714884dc44dc41f9c834f03ddff2de23fde838ff3b1 age=1w8h25m dirty="7.94 MiB"
5, Query whether synchronization is completed
- View the current latest block
# curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://127.0.0.1:8545
{"jsonrpc":"2.0","id":1,"result":"0x8f8e68"}
- View current synchronization status
# curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' http://127.0.0.1:8545
{"jsonrpc":"2.0","id":1,"result":false}
Note: if the result is false, the synchronization is completed
The above is the main content of this document. In the process of BSC node synchronization, I think of the following two problems, and make some records here:
- 1. The configuration of the node server synchronized from 0 is much higher than that of the other one, and has been synchronized for 10 days. Why does it take more than 1 day for the node started with snapshot data to synchronize to the latest block?
- 2. The node server synchronized from 0 has been synchronizing the block status data, and the snapshot data node starts to synchronize the block after it is started. Why not synchronize the block status data?
The data of BSC node is divided into block data and status data.
The data volume in BSC is not entirely block data, but more status data;
Complete BSC status: refers to the current status of all accounts and balances, as well as the 'memory' of all smart contracts deployed and running in EVM (Ethereum virtual machine);
Therefore, being unable to synchronize to the latest block does not mean being unable to synchronize to the latest block data, but being unable to synchronize to the latest state.
So why don't snapshot data nodes synchronize state data?
By default, when the BSC is started for the first time, the status data needs to be synchronized to the latest block to complete the data synchronization;
The snapshot data already contains the status data synchronized to the latest block, so there is no need to synchronize the status data of the BSC separately, but complete the synchronization together when synchronizing the block data.
The above is all the content shared today.
I hope you can solve your actual needs and problems through the above methods.
If you have any questions during the deployment process, you can scan the following QR code and add my personal wechat. Note: Region - career direction - nickname. Welcome to join the blockchain technology exchange group to learn and communicate with more blockchain technology leaders.
Original is not easy, codeword is not easy. If you think this article is a little useful to you, please like this article, leave a message or forward it, because this will be the driving force for me to output more high-quality articles. Thank you!