以太坊 区块结构

区块由两部分组成:区块头(header)和 区块体(body)。

1. 区块结构

1.1  区块结构图

preview

1.2 区块头(header)

区块头存储了区块的元信息,用来对区块内容进行一些标识,校验,说明等。

通用字段:

  • ParentHash: 父区块的哈希值。
  • Root:世界状态的哈希,stateDB的RLP编码后的哈希值。
  • TxHash(transaction root hash):交易字典树的根哈希,由本区块所有交易的交易哈希算出。
  • ReceptHash:收据树的哈希。
  • Time:区块产生出来的Unix时间戳。
  • Number:区块号。
  • Bloom:布隆过滤器,快速定位日志是否在这个区块中。

公链场景:

  • Coinbase:挖出这个块的矿工地址,因为挖出块所奖励的ETH就会发放到这个地址。
  • Difficulty:当前工作量证明(Pow)算法的复杂度。
  • GasLimit: 每个区块Gas的消耗上线。
  • GasUsed:当前区块所有交易使用的Gas之和。
  • MixDigest: 挖矿得到的Pow算法证明的摘要,也就是挖矿的工作量证明。
  • nonce:挖矿找到的满足条件的值。
  • Uncle:叔块是和以太坊的共识算法相关。

1.3 区块体(Body)

区块体包括这个区块打包的所有交易,在一些链的设计中,并不像以太坊区分header和body,而是整合在一起。

2. 区块存储

以太坊在存储区块的时候,区块头和区块体其实是分开存储的,其实也很容易理解,分开存储可以提供更多的灵活性,比如不用保存全部区块数据的轻节点。

2.1 区块头存储

以太坊通过如下方式将区块头转换成键值对存储在LevelDB中;

headerPrefix + num + hash  -> rlp(header)
Tips: num是以大端序的形式转换成bytes的,其中headerPrefix的值是 []byte("h")

2.2 区块体存储

区块体的存储方式也是类似;

bodyPrefix + num + hash -> rlp(block)
Tips: num是以大端序的形式转换成bytes的,其中bodyPrefix的值是[]byte("b")

3. 潜在问题

假设在一个联盟链的场景下,采用了BFT类的算法,有一个重量级的业务跑在上面,日积月累产生了大量的数据,是否会出现

  • LevelDB的读写性能大幅下降拖慢系统的响应速度?
  • 单机存储无法满足需要?
  • 存储了大量的不会使用的历史数据?

在联盟链的场景下,由于共识速度的提升,导致出块速度也大幅提升,原本在公链场景下不存在的区块写入瓶颈,现在反而成了拖慢系统运行速度的重要因素了。

观察一下区块数据的存储就可以发现下面的这些特点;

  • 区块数据只会增加;
  • 无需对历史区块进行修改;
  • 无需对区块数据进行复杂操作,比如聚合,运算等;

归纳一下就是:

  • 顺序写
  • 随机读
  • 迭代(Iterator)

针对这些特点Hyperledger Fabric设计了基于文件的存储方式,在Fabric中区块数据是以一个个文件的形式存在。

chains
  |----mychannel
  |----|----blockfile_000000
index
  |----000001.log
  |----CURRENT
  |----LOCK
  |----LOG
  |----MANIFEST-000000

其中blockfile_000000是区块数据,index则是索引游标等元信息。

这种方式速度很快,方便做数据归档,也可以避免像LevelDB等数据库数据越写越慢的问题,主流联盟链都是采用类似的方案。

下一章:LSM树

LSM树,即日志结构合并树(Log-Structured Merge-Tree)。其实它并不属于一个具体的数据结构,它更多是一种数据结构的设计思想。大多NoSQL数据库核心思想都是基于LSM来做的,只是具体的实现不同。所以本来不打 ...