最近bitshares网络激活了代号湄公河的6.0版本，新增了好多激动人心的特性比如P2P质押借贷、无抵押借贷（闪电贷）等，想起我还在本地运行着一个bitshares节点呢，打算拿来学习一下BTS6.0。
结果打开我的本地节点一看，咦，竟然卡住了好久，仔细想想也不意外，6.0版本是协议升级，也就是我们在HIVE上常说的硬分叉(Hard Fork)，新版本被激活，而我的本地节点是5.0.1版本，当然要卡住啦，所以要将其升级到6.0.1才能继续愉快地玩耍。
根据节点运行的方式，升级有好多方法，比如说使用Docker、或者直接使用编译好的二进制文件，不过我还是喜欢从源码编译这种方式（好吧，其实是我不知道如何使用其它方式）。
编译的方式很简单啦，按如下步骤操作即可：
git clone https://github.com/bitshares/bitshares-core.git
cd bitshares-core
git checkout <LATEST_RELEASE_TAG>
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make witness_node cli_wallet
上述指令中，需要将<LATEST_RELEASE_TAG>替换成最新发布版本号，撰写本文时，最新版本号是6.0.1。
按上述指令，会在相应路径中生成如下两个目标文件：
build/programs/witness_node/witness_node
build/programs/cli_wallet/cli_wallet
进入相应目录中，然后使用如下指令查看一下版本信息：
./witness_node --version
返回信息如下：
这说明我编译的没啥问题。
然后使用scp指令将上述两个文件复制到本地机器对应账户的bin目录中，替换掉原有的程序。在scp之前，可以先用tar指令将程序打包压缩一下，这样传输会比较快，且节省网络带宽。
关掉之前运行的（卡住状态的）witness_node，再重新执行witness_node指令，就会发现节点自动开始replay。
我撰写本文时，进展如下：
为了方便查看，截屏只截取部分内容，这是其中一条信息：
3420978ms th_a db_management.cpp:141 reindex ] [by size: 21.08850% 20009480004 of 94883379836] [by num: 43.47800% 28410000 of 65343387]
我发现，replay时除了有按区块数量的进度，还有一个按区块文件( blocks)体积的进度。
这个功能比较好，因为区块有大有小，甚至早期区块可能有很多不包含任何交易的空块。所以单纯按区块数估算进度是非常不准确的，按体积则相对准确多啦。
好期待hived的replay功能也加上按区块文件体积显示进度的功能，那样就能大致估算出replay完成的时间啦。
看了一下，半个小时左右，按区块文件体积replay完成了大概20%，所以全部完成大概需要2.5小时，也就是说还需要2个小时左右，两个小时后我再来瞧瞧。
接着写，原本打算两小时后瞧瞧replay进度，结果因为太晚太困，一不小心睡着了，等我醒来已经是第二天了。
登录本地机器一看，replay早已完成，哎，也不知道自己估算的时间是否准确，不过想必应该差不太多。
下次有版本升级还是要及时升级的好，如果我在硬分叉前及时升级并replay，节点就不会卡住啦，好在我还没在上边跑什么业务，否则损失大了。
不过好在升级是顺利完成了，以后又可以愉快地玩耍了。有小伙伴一起来玩嘛？