最近在HIVE见证人聊天频道中听到一个好消息，HIVE定于2025年11月19日进硬分叉，升级大版本至1.28.0，为hived提供诸多功能和性能上的改进。
(图源 ：pixabay)
上次硬分叉还是三年前（2022年）10月份的硬分叉27（Hardfork 27），这一转眼就过了三年多，不得不感慨时间飞逝啊。
三年来HIVE区块链底层稳步运转，充分证实了HIVE区块链的稳定性和以及强壮性，这期间HIVE的开发团队以及其它第三方团队、见证人群体基于HIVE底层做不大量的开发工作，推出了许多功能强大、实用性强的二层工具以及DAPP，就不一一表述了。
当然，开发团队也在hived上投入了大量精力，现在繁华终于要借出硕果——HIVE Hardfork 28就要来了。我的脑海里突然冒出来一句话：Make HIVE Great Again!
编译hived 1.28.0
为了迎接这次硬分叉，在hived 1.28.0发布的第一时间我就进行了编译，得益于之前为了温故而知新重新编译hived 1.27.11的经历，此次轻车熟路，顺风顺水。
不过从1.27.x升级到HIVE 1.28.0需要Replay（重播）整个区块链数据，因为内部的 hived 状态格式和数据结构发生了变化。
旧债：压缩block_log
但是在Replay之前，我需要做的一件事就是把之前的非压缩区块链数据（block_log）转换成压缩格式的文件——虽然block_log压缩功能已经推出好多年，而且在我见证人节点以及其它一些节点上我都用的压缩文件，但本地节点我还一直用着非压缩的呢。
但现在也到了必须转换的时候了，因为非压缩文件要多占用500G左右的空间，磁盘空间告急呀。
当前非压缩block_log的空间占用情况：
985G block_log
2.3G block_log.artifacts
好在HIVED的开发团队一直有提供和维护compress_block_log工具，我用这个工具对当前非压缩block_log进行了转换。
看把我大电脑累成啥样了：
也不知道用时多久（不小心睡着了，又没掐时间，结束后打印的报告里时间应该不对。我觉得大概三四个小时吧），终于完成了转化，完成后的体积如下：
498G block_log
2.3G block_log.artifacts
看，果然省了好多。时隔多年，终于把旧债换上了，以后就和非压缩的block_log说白白了，果断删除之，并把压缩后的block_log复制进对应目录。
拆分区块的问题
hived 1.28.0一个重要的改进就是支持拆分区块，将 block_log 文件拆分为多个“部分文件”（每个部分文件存储 100 万个区块），这对于磁盘空间受限的节点非常友好。
你可以只保留最近的100万个区块，甚至保留0个区块来运行所谓的轻节点，比如共识节点或者跑些轻量级应用（点赞机器人、交易机器人等）。
要想应用这些功能，只需设置相应的参数block-log-split即可，对应情况如下
block-log-split= 9999默认值 拆分并保留所有区块
block-log-split= 0共识节点可用 保留0个区块
block-log-split= N轻量应用节点可用 保留N个百万区块
block-log-split=-1不拆分
我的打算是本地节点不拆分（block-log-split=-1 ），共识节点保留0个区块（block-log-split= 0），应用节点保留100W个区块（block-log-split= 1）
关于comments-rocksdb
我觉得这次升级一个最重大的改进就是把评论数据（应该不含评论内容）从共享内存（shared_memory.bin）中移到RocksDB中。
原来所有的数据都在shared_memory.bin，大概要占19G左右的空间，对于想把shared_memory.bin文件完整地放到内存中的节点而言，必须配置内存足够大的主机。（我最早用64G内存的VPS，后来换成32G内存的VPS）。
改进后的shared_memory.bin和RocksDB空间占用情况：
3.9G comments-rocksdb-storage
5.0G shared_memory.bin
实际只占了不到10G的空间，而shared_memory.bin只占了5G空间，完全可以考虑把两者或者两者之一放到内存上去运行。这无疑会节省大量的成本呀。😍
用hived 1.28.0重播区块
有了上述准备工作，设置好相应的参数后就可以replay区块链啦。
UTC时间28日9点开工
中途被我停掉几次看进度（我把输出关得七七八八）
12小时后到了这里
到16个小时后已经重播完成且开始正常同步啦
其实我猜它没用上16个小时，而是因为16个小时后是北京时间的早餐九点多，这时候我刚忙完一堆事，再次看重播进度。
所以重播时间可能在14-15个小时左右，下次设置重播完成后退出，就能看报告时间了。😳 如果我不瞎折腾（来回重启），应该更快。
来关掉重新运行一下，一切正常，好喜欢这个大图标。
至此，本地节点升级已顺利完成。其实是断断续续折腾了三两天天，但是前期的各种测试转换，都是之前欠的旧债。又怪得了谁呢？
对了，顺便感谢一下我的大主机，之前好多操作（编译等）都在AWS的超贵服务器上测试，现在发现在我大主机上搞，快到飞起呀，毕竟是有着I9超强内心以及128G超高内存呢。
就是我的主NVME SSD没挂到CPU旁的接口，速度大打折扣呀。这要是把主NVME SSD挂到CPU旁，相比压缩和重播速度会更胜一筹呢！咦，这个思路不错呀，岂不是又可以折腾了？
关于见证人节点的升级
通过查看见证人列表，截至撰写本文时已经有三个小伙伴在开始运行hived 1.28.0版本的见证人节点啦。
他们分别是
我现在也在VPS上部署了hived 1.28.0版本，准备先跑一两天看看，再切见证人KEY过去不迟。毕竟距离11月19日还有多半个月呢。
嗯，就这么愉快地决定了，我决定回头先折腾我的NVME SSD去，想必很好玩。😍