Hello, everyone. I’m Jack. I started to synchronize the data of BSC (BSC intelligent Chain, hereinafter referred to as BSC) node from block 0 before, but I didn’t catch up with the latest block. In this article, we’ll take a look at how long it takes to catch up with the BSC mainnet snapshot data using binary mode.

• BSC snapshot Official: docs.binance.org/smart-chain…
• BSC snapshot github: github.com/binance-cha…

Before starting this document, let me give you an overview of the BSC synchronization:

• Server environment

Server: ali cloud server CPU: 8 cores memory: 16GB data disk: 1T efficient cloud disk bandwidth: 10M sharedCopy the code

• Software environment

Centos 7.7Copy the code

Since the previous synchronization process started from block 0, about 10 days have passed, but the status data of BSC main chain node still hasn’t been synchronized, so this time we use BSC snapshot data to test synchronization again:

I downloaded the BSC snapshot data at 9pm on July 20, 2021, when the latest data was from July 14, 2021, and at the time of writing this article, the latest snapshot data was from July 22, 2021;

It took me about a few hours to download the snapshot data, which was about 401 GB;

At 9:25 am on July 22, 2021, I started the BSC main network node with the downloaded BSC snapshot data, and then waited silently for the synchronization to complete.

Finally, at 18:23 on July 23, 2021, the latest block of the BSC main network was synchronized: 9405,825 blocks;

According to the calculation, it takes about 1 day, 8 hours and 58 minutes to use the BSC snapshot data to synchronize the data of the primary network node. Note: The synchronization time is for personal use only. The synchronization time depends on the current environment.

The resource usage of the server is as follows:

CPU: 4 cores Memory: 12 GB Bandwidth: 2 M Disk: 536 GBCopy the code

---

Now, without further ado, let’s begin the practical steps

Use binary to start the snapshot data of the BSC primary network

1. Download the snapshot data of the BSC primary network

• Download the snapshot data of the BSC primary network

cd /opt/docker/bsc/ nohup wget https://s3.ap-northeast-1.amazonaws.com/dex-bin.bnbstatic.com/geth-20210714.zip?AWSAccessKeyId=AKIAYINE6SBQPUZDDRRO\&Exp ires=1628936991\&Signature=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA%3D &Copy the code

• Decompress BSC primary network snapshot data

unzip geth-20210714.zip\? AWSAccessKeyId\=AKIAYINE6SBQPUZDDRRO\&Expires\=1628936991\&Signature\=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA\=Copy the code

Download the BSC binary file

• Download the BSC binary

CD/opt/docker/BSC/server wget HTTP: / / https://github.com/binance-chain/bsc/releases/download/v1.1.0-beta/geth_linuxCopy the code

• Grant executable permission

chmod 777 geth_linux
Copy the code

Download the main network configuration file and genesis block file

• Download the main 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)
Copy the code

• Unzip the downloaded file

unzip mainnet.zip 
Copy the code

• Modify the BSC main network configuration file

HTTPHost: Http-rpc service connection whitelist. The default value of this parameter is "localhost" and only local access is allowed. The value can be set to: "0.0.0.0" HTTPVirtualHosts: Http-rpc service listening interface. The default value of this parameter is ["localhost"] and can be set to: HTTPVirtualHosts = ["*"]Copy the code

Start the BSC main network in binary mode

• Install the window manager tool: Screen for Linux

yum -y install screen
Copy the code

• Start the BSC primary network 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
Copy the code

Parameter description:

–config: specifies the BSC node configuration file

–datadir: Specifies the data directory for the BSC node database and keystore (default :”/root/.ethereum”)

–cache: Specifies the maximum amount of memory that can be allocated to the internal cache. The default value is 1024.

–rpc.allow-unprotected -TXs: Allow unprotected (non-EIP155 signing) transactions to be submitted through RPC

— txlooKUplimit 0: disables deletion of transaction indexes

• Viewing startup Logs

cd /opt/docker/bsc/server/node/
cat bsc.log.2021-07-22_09
Copy the code

• The log shows

// Set the BSC main network node configurations:  t=2021-07-22T09:25:01+0800 lvl=warn msg="Sanitizing cache to Go's GC limits" provided=18000 updated=5338 ...... 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}" ...... T = 2021-07-22t09:25:02 +0800 LVL =info MSG ="Loaded most recent local header" number=9,154,718 Hash = 0 = 18241589 age = 1 w8h25m xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td / / 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 = 0 xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td = 18241589 age = 1 w8h25m 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 = 0 xea2f92e829a44069fef71d345fcacf404bb2df44dd14dea45deb0e84682fdfcd td = 18241589 age = 1 w8h25m... T =2021-07-22T09:25:03+0800 LVL =warn MSG ="Switch sync mode from fast sync to full sync"...... T = 2021-07-22t09:25:03 +0800 LVL =info MSG ="Started P2P networking" t= 2021-07-22t09:25:03 +0800 LVL =info MSG ="Started P2P networking" self=enode://878a50bbcf1f6fe820d53315decd1c540de1570c967125561484a2819e7a66c4f1df8157cbcf1979bb3d245aadb3073a86c1d894179 [email protected]:30311 // Block synchronisation started t= 2021-07-22t09:25:13 +0800 LVL =info MSG ="Block synchronisation started" . T = 2021-07-22t19:25:27 +0800 LVL =info MSG ="Imported new chain segment" blocks=3 TXS =793 mgas=115.754 Elapsed = 8.585 s mgasps = 13.483 number = 9154721 hash xaa97db3864f0002b4bec4714884dc44dc41f9c834f03ddff2de23fde838ff3b1 = 0 Age = 1 w8h25m dirty = "7.94 MiB"Copy the code

5. Check whether the synchronization is complete

• View the 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" : "0 x8f8e68}"Copy the code

• View the 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}Copy the code

Note: A result of false means synchronization is complete

---

This is the main content of this document. In the process of BSC node synchronization, I think of the following two problems, and make a note here:

• 1. The server configuration of the node to be synchronized from 0 is much higher than that of the other node and has been synchronized for 10 days. Why is it that the node started using snapshot data is synchronized to the latest block in more than one day?
• 2. The server of the synchronized node from 0 synchronizes the block status data all the time, and the snapshot data node starts to synchronize the block status data. Why not synchronize the block status data?

BSC node data is divided into two types: block data and status data.

The data volume in BSC is not only block data volume, but more status data.

Full BSC status: refers to the current status of all accounts and balances, and the ‘memory’ of all smart contracts deployed and running in EVM (Ethereum virtual machine);

So being unable to synchronize to the latest block means not 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 data synchronization.

The snapshot data already contains the status data synchronized to the latest block, so you do not need to synchronize the status data of the BSC separately. Instead, the block data is synchronized together.

---

That’s all FOR today.

I hope you can solve their own practical needs through the above ways to solve their current problems.

If there is any doubt in the deployment process, you can scan the following TWO-DIMENSIONAL code, add my personal wechat, note: region – career direction – nickname, welcome to hold up, join the blockchain technology exchange group, and more blockchain technology leaders learn to communicate.

Original is not easy, code word is not easy. If you think this article is of some use to you, please give me a like, comment or forward this article, because this will be my motivation to output more quality articles, thank you!