共计 4843 个字符,预计需要花费 13 分钟才能阅读完成。
大家好,我是杰哥,因为之前从 0 块开始同步 BSC(币安智能链,下文简称 BSC)节点的数据,始终没有追上最新区块,通过和他人一起探讨,最终应用 BSC 节点主网快照数据同步到了最新区块。那么这篇文章就和大家一起应用二进制的形式启动 BSC 主网快照数据,来看看这次须要多久的工夫能够追上最新区块。
- BSC 快照官网:https://docs.binance.org/smar…
- BSC 快照 github:https://github.com/binance-ch…
本篇文档开始之前,大略阐明一下本次 BSC 同步的状况:
-
服务器环境
服务器:阿里云服务器 CPU:8 核 内存:16GB 数据盘:1T 高效云盘 带宽:共享 10M
-
软件环境
centos 7.7
因为后面应用从 0 块开始同步的过程,大略 10 天过来了,BSC 主链节点的状态数据仍旧没有同步实现,所以本次应用 BSC 快照数据再次测试同步一下:
我是在 2021 年 7 月 20 日早晨九点下载的 BSC 的快照数据,过后最新的数据是 2021 年 7 月 14 日的快照数据,编写这篇文章时,最新的快照数据是 2021 年 7 月 22 日的;
我大略破费了几个小时就将快照数据下载下来了,过后解压后的数据是:401 GB 左右;
在 2021 年 7 月 22 日早上 9 点 25 分时,我利用下载好的 BSC 快照数据启动了 BSC 主网节点,而后就始终默默的期待同步实现;
终于,在 2021 年 7 月 23 日 18 点 23 分,同步到了最新 BSC 主网的最新区块:9405825 块;
大略计算了一下,此次利用 BSC 快照数据同步主网节点数据,同步工夫大概破费了: 1 天 8 小时 58 分钟 ;注:本次同步工夫仅为集体应用的工夫,同步工夫还需参考过后环境。
本次同步,服务器的资源应用状况如下:
cpu:4 核
内存:12 GB
带宽:2 M
磁盘:536G
接下来废话少说,马上开始实操步骤
应用二进制启动 BSC 主网快照数据
一、下载 bsc 主网快照数据
-
下载 bsc 主网快照数据
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 &
-
解压 bsc 主网快照数据
unzip geth-20210714.zip\?AWSAccessKeyId\=AKIAYINE6SBQPUZDDRRO\&Expires\=1628936991\&Signature\=C6kD8aUdzCmpPwQ7HHRFyn%2FXknA\=
二、下载 BSC 二进制文件
-
下载 BSC 二进制文件
cd /opt/docker/bsc/server wget https://github.com/binance-chain/bsc/releases/download/v1.1.0-beta/geth_linux
-
授予可执行权限
chmod 777 geth_linux
三、下载主网配置文件及创世区块文件
-
下载主网配置文件及创世区块文件
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 mainnet.zip
-
批改 BSC 主网配置文件
HTTPHost: HTTP-RPC 服务连贯白名单,此参数的值默认为 "localhost",仅容许本地可拜访,可设置为:"0.0.0.0" HTTPVirtualHosts:HTTP-RPC 服务监听接口, 此参数的值默认为 ["localhost"], 可设置为:HTTPVirtualHosts = ["*"]
四、二进制启动 BSC 主网
-
装置 linux 下的窗口管理器工具:screen
yum -y install screen
-
启动 BSC 主网节点
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
参数阐明:
–config:指定 BSC 节点配置文件
–datadir:指定 BSC 节点数据库和密钥存储库的数据目录 (默认:”/root/.ethereum”)
–cache:设置最大调配给外部缓存的内存,默认:1024(设置越大,每次同步的数据越多,耗费的内存也越大)
–rpc.allow-unprotected-txs:容许通过 RPC 提交不受爱护的(非 EIP155 签名)交易
–txlookuplimit 0 : 禁用删除事务索引
-
查看启动日志
cd /opt/docker/bsc/server/node/ cat bsc.log.2021-07-22_09
-
日志阐明
// 预置 BSC 主网节点各种配置: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}" ...... // 加载最新的 header 文件 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 // 加载最新的残缺的区块 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 加载最新的 fast 区块 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 ...... // 同步模式由疾速同步切换为全同步 t=2021-07-22T09:25:03+0800 lvl=warn msg="Switch sync mode from fast sync to full sync" ...... // 启动 p2p 网络 t=2021-07-22T09:25:03+0800 lvl=info msg="Started P2P networking" self=enode://878a50bbcf1f6fe820d53315decd1c540de1570c967125561484a2819e7a66c4f1df8157cbcf1979bb3d245aadb3073a86c1d8941793b8984ecd8015be479cdd@127.0.0.1:30311 // 区块同步开始 t=2021-07-22T09:25:13+0800 lvl=info msg="Block synchronisation started" ...... // 同步到新的链数据 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"
五、查问是否同步实现
-
查看以后最新区块
# 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"}
-
查看以后同步状态
# 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}
注:后果为 false 为同步实现
以上就是本篇文档的次要内容了,在本次 BSC 节点同步过程中,想到以下两个问题,在这里稍做一下记录:
- 1. 从 0 开始同步的节点服务器配置远高于另外一台,并且曾经同步了 10 天,为什么应用快照数据启动的节点只用了 1 天多就同步到最新区块了呢?
- 2. 从 0 开始同步的节点服务器始终在同步区块状态数据,而快照数据节点启动后,就开始同步区块了,为什么不须要同步区块状态数据了呢?
BSC 节点的数据分为:区块数据 和 状态数据两种。
BSC 中的数据体量并不齐全是区块数据量,更多的是状态数据;
残缺的 BSC 状态:指的是所有账户和余额的以后状态,以及在 EVM(以太坊虚拟机)中部署并运行的所有智能合约的‘内存’;
所以始终无奈同步到最新的区块指的不是无奈同步到最新的区块数据,而是无奈同步到最新的状态。
那么为什么快照数据节点不必同步状态数据了呢?
因为 BSC 默认第一次启动时,须要将状态数据同步到最新的区块,能力实现数据的同步;
而快照数据中曾经蕴含同步到最新区块的状态数据,所以不须要再去独自同步 BSC 的状态数据,而是在同步区块数据时,一起就实现同步了。
以上,就是明天分享的全部内容了。
心愿大家通过以上形式能够解决本人的理论需要,解决本人目前所遇到的问题。
如果在部署过程中有任何疑难,能够扫描上面的二维码,增加我的集体微信,备注:地区 - 职业方向 - 昵称,欢送来撩,退出区块链技术交换群,与更多的区块链技术大佬学习交换。
原创不易,码字不易。感觉这篇文章对你有点用的话,麻烦你为本文点个赞,留言或转发一下,因为这将是我输入更多优质文章的能源,感激!