AI 中文社
Copyright © 2022-2024 aizws.net · 网站版本: v1.2.6·内部版本: v1.23.3·
页面加载耗时 0.00 毫秒·物理内存 59.0MB ·虚拟内存 1300.0MB
欢迎来到 AI 中文社区（简称 AI 中文社），这里是学习交流 AI 人工智能技术的中文社区。 为了更好的体验，本站推荐使用 Chrome 浏览器。
以太坊 区块结构
区块由两部分组成：区块头（header）和 区块体（body）。
1. 区块结构
1.1 区块结构图
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来做的，只是具体的实现不同。所以本来不打 ...