谈到区块链的存储，我们很容易联想到它的链式存储结构，然而区块链从比特币发展到今日当红的EOS，技术形态已经演化了10年之久。目前的EOS的存储除了确认结构的链式存储以外，在状态存储方面有了很大的进步，尤其是引入了MongoDB plugin以后，可以将功能有限的状态库搭上大数据的班车。本文将全面介绍EOS的存储技术。
EOS 存储，Merkle Tree，mongodb，chainbase，源码学习，context_free_actions
EOS的链式存储结构EOS的区块数据结构如下：
field explanationtimestamp 时间戳
producer 生产者
confirmed 生产者确认数
previous 链式结构前一个区块的id
transaction_mroot 交易默克尔树根
action_mroot 动作默克尔树根
schedule_version 生产者版本排序号
new_producers 下一个生产者
header_extensions 区块头扩展字段
producer_signature 区块签名，由生产者签名
transactions 块打包交易内容，是数组结构，可以多个
block_extensions 区块扩展字段
id 当前块id
block_num 当前块高度
ref_block_prefix 引用区块的区块头
Merkle Tree
默克尔树的演化路线是 Hash => Hash Tree => Merkle Tree ，他们都是为解决数据一致性而存在的，具体的含义如下：
Hash 是我们都熟知的技术了，它可以为一个文件或其他数据生成一个Hash值，我们在下载一个文件时，通常会在下载页面看到这个文件的Hash值以及该Hash值的算法，下载完毕以后，我们可以在本地对整个文件进行同样的Hash算法得到Hash值，然后与网页上的Hash值进行对比，如果相同，则说明文件完整，是网页上的源文件，如果不匹配则说明文件损坏，被修改或者不完整。
仍旧是文件完整性的校验需求，当这个文件特别大的时候，对这个文件进行Hash算法是能耗巨大的，所以可以将文件切割成很多的小块，每一个小块都有一个Hash，然后将所有小块的Hash值拼在一起再次进行Hash算法得到的就是Root Hash。这样一来，我们在下载大文件的时候，会先下载一个包含Root Hash的Hash list，通过校验Root Hash可以确定Hash list的正确性，确定Hash list正确以后，再逐个下载小块文件并逐一验证Hash，当发现某个小块Hash不匹配的时候，就可以单独重新下载该小块即可，而不必重新下载全部。Hash list的结构实际上是一个Root Hash 为根，小块Hashs为叶子节点的树高为2的Hash Tree。
Merkle Tree实际上是对Hash List的优化，它极大的提高了性能。它的结构是一个二叉树（也可以是多叉树，性能优化的关键点是它的高度是大于等于2的），每个节点最多只有两个子节点，只有叶节点是根据小块文件做的Hash，每两个相邻的叶节点的父节点是由这两个Hash做的父Hash，如果叶节点的总数是单数，则会剩余一个，逐级而上，最终会有一个的根节点，这个根节点就是Merkle Root。这样以来，我们在下载大文件的时候，会首先下载一个Merkle Tree，从最左下叶节点进行校验，逐级而上，将整个Merkle Tree校验完毕。这里面不同于上面Hash Tree的是，只要最左下相邻的两个叶节点的Hash值与他们的父节点的Hash通过了匹配，则可以立即开始下载这两个叶节点对应的文件块，并行地，再校验其他叶节点，这就提高了性能，不必校验完整的Merkle Tree之后再下载文件。
Merkle Tree 与 区块链上面的区块数据结构中包含了两个与Merkle Tree相关的字段：
transaction_mroot，一个区块中的transactions字段可以包含多笔交易，区块中的transaction_mroot是所有该区块内打包的交易的Merkle Root，可以用来校验其中的每笔交易的正确性。如果该区块中不包含任何交易，则该字段的值为0000000000000000000000000000000000000000000000000000000000000000。节点同步数据的时候，会先将交易的Merkle Tree下载并通过Merkle Root来校验，而不是将所有的交易主体全部下载下来，这样可以节省轻节点的数据量。
action_mroot，创建一个基于所有分发的action的根，在区块内接收交易时进行评估。用在轻客户端的校验，功能同上。