还记得我们之前学习过实测block_log
修复以及hive区块链Replay嘛?我们通过block_log.index
获取指定区块在block_log
中的位置,然后对两个文件进行相应的截短,达到修复的目的。
(图源 :pixabay)
这个主要依据就是block_log.index
中保存有每个区块数据在block_log
中的位置信息(8个字节):
+----------------+----------------+-----+-------------------+
| Pos of Block 1 | Pos of Block 2 | ... | Pos of Head Block |
+----------------+----------------+-----+-------------------+
(block_log.index文件信息)
然而在测试中,我发现一个有趣的问题,就是在没有block_log.index
的情况下,replay HIVE区块链,竟然也会打印出当前区块号信息。
Reveal spoiler
那么这个区块信息是如何得出的呢?这就要从block_log
的文件格式说起了,block_log
的内容排列如下:
+---------+----------------+---------+----------------+-----+------------+-------------------+
| Block 1 | Pos of Block 1 | Block 2 | Pos of Block 2 | ... | Head Block | Pos of Head Block |
+---------+----------------+---------+----------------+-----+------------+-------------------+
(block_log文件信息)
也就是说排列规则是区块数据后跟着这个区块数据在文件中的位置。知道这个规则后,如果文件未被损坏,那么我们就可以直接读取最后边8个字节,计算出当前区块在block_log中的位置。
不过,这依旧让我百思不得其解,文件格式中也没有区块号数据啊。那么区块号是如何得出来的呢?后来一想,哎,我不是傻嘛?这里边既然有区块数据,那么区块号当然是包含在区块中啦。
可是新问题来了,尽管我知道这里边包含区块数据,甚至我可以根据位置信息读出对应的区块数据,然而这就是一串二进制比特数据,我该咋解读啊?
就好比我已经读出了第一个区块(创世块)的数据,但是根本不知道这串数据都代表啥?
Reveal spoiler
好在有https://hiveblocks.com/可供参考,上述内容对应的block信息如下:
Reveal spoiler
好吧,还是没啥眉目,不过大体上应该是把上述信息,以byte流的形式写进block_log文件。所以如果我没猜错的话,第一排数据就是previous(前一个块的ID),第二排包含时间数据,之后紧接见证人信息。
代码中整个block数据定义为:signed_block
,亦即如下代码:
Reveal spoiler
而它又是从signed_block_header
以及block_header
逐级继承得来:
Reveal spoiler
好,扯得有点远了,总之,前20个字节(160/8
)就是previous id(前一个块的ID),而这里边包含着前一区块的区块号,区块号可以通过id算取。
将区块号包含至id,以及从id中获取区块号的代码如下:
Reveal spoiler
至此,不考虑区块的其它信息,从理论上,我们已经能从block_log
读出的区块byte数据中获取区块号了。整体思路就是:
- 读取区块数据
- 读取前20个字节,获取previous id
- 从previous id获取前一区块的区块号
- 在获取的区块号上+1,就是当前区块号了
(图源 :pixabay)
至于到底咋读出来,容我先休息一下,且听下文分解吧,对于我这种菜鸟而言,学习实在是太累了,还是出去玩或者喝酒省事呀。
看到O哥每天还在不断地学习,实在是敬佩。对我这种菜鸟而言,以后请O哥喝喝酒吃吃饭就可以了。
对于我这种菜鸟而言,学习实在是太累了,还是出去玩或者喝酒省事呀🙈
看到那么多密密麻麻的字,头好大。
真不知道你们程序员的生活是什么样的 。
应该密集恐惧症的人当不了程序员
膜拜👍👍👍