模型存储在哪里_区块链存储的底层存储

存储在增长

区块链节点作为运行在计算机之上系统，需要有地方记录数据，自然也就需要存储。

以上是比特币的磁盘占用随时间的变化图（来自bitcoin.com）。可以看到占用空间目前已经到200G，十年200G的数据并不多，但考虑到比特币的tps只有个位数级别，这个量级的数据已经是相当大的了。

上图是以太坊的磁盘占用随时间的变化图（来自etherscan.io）。目前数据的大小为130多G，虽然没有比特币那么大，但是增长迅速。

区块链面临的最大问题之一是可扩展问题，可能大多数人在看到这个问题的时候都会想到tps，其实，除了tps之外，还有存储的问题。挖矿节点中由于存储了所有的历史交易和区块，随着交易的不断增长，占用的磁盘空间也越来越大，新节点加入到完成同步需要越来越长的时间。而这个问题会因为tps的提高而显得越来越突出，因为写入的速度快了，存储的增长也会对应加快。

UTXO模型和Account模型

数据模型本身对存储有较大的影响，与比特币的UTXO（Unspent Transaction Output）模型不同的是，以太坊采用了Account模型。

什么是UTXO呢？UTXO模型的交易中包含input（输入）与output（输出），整个过程有点像我们平时用纸币购买商品以及找零的过程。比方说，当需要在超市购买价值150元人民币的商品时，由于没有50元面值的纸币，所以给出两张100元面值的钞票，这就是两个input，收银员找零50元，这其实就是两个output，一个output是150元给到超市，一个output是50元找零还给买方，为便于理解忽略手续费。UTXO就像钱包的纸币，一张纸币就是一个UTXO，不会合并。

产生的output叫做Unspent Transaction Output，用于后续使用，每个output只能使用一次，所以称为UTXO模型，如下图所示意（来自http://bitcoin.org）。

相比之下，Account模型的流程更像银行的转账，系统中存着每个账号对应的余额等关键信息（而在UTXO模型中，如果需要知道某账户总余额，钱包客户端需要把属于这个账号的所有UTXO累加起来)。

如下图所示，整个系统中包含一个世界状态（World State），在处理区块时（区块中包含Transaction），世界状态从一个状态变到另外一个状态。

世界状态中包含所有账号的信息，每个账号中的关键信息包括nonce、余额balance、storage hash和code hash。其中storage hash可以理解为这个合约存储的hash，这对于合约账户来说很关键，因为合约大多涉及存储读写。而code hash则为合约代码的hash。

MPT（Merkle Patricia Trie）树

如上图，以太坊为代表的账户模型中，区块头中包含几个重要信息:

1、tansaction root: 区块中交易根hash，用于快速验证交易执行结果是否相同以及证明某个交易的存在。

2、state root: 账户状态（每个账户的余额和nonce，合约相关数据等）根hash。

3、receipts root:区块中合约相关的交易输出的事件根hash。

MPT全称Merkle Patricia Trie，是以太坊用来存储数据的一种数据结构, 它融合了Trie、Patricia Trie、Merkle Tree这3种数据结构的优点，从而实现快速查找并节省存储空间。

Trie树，又称前缀树或字典树，是一种用于快速检索的多叉树结构，其中的键通常是字符串。与二叉查找树不同，键不是直接保存在节点中，而是由节点在树中的位置决定。一个节点的所有子孙都有相同的前缀，也就是这个节点对应的字符串，而根节点对应空字符串。实际上trie每个节点是一个确定长度的数组，数组中每个节点的值是一个指向子节点的指针，最后有个标志域，标识这个位置为止是否是一个完整的字符串，并且有几个这样的字符串。

Trie树

Patricia树，或称Patricia trie，或crit bit tree，压缩前缀树，是一种更节省空间的Trie。对于每个节点，如果该节点是唯一的儿子的话，就和父节点合并。

Patricia树

Merkle Tree，通常也被称作Hash Tree，顾名思义就是存储hash值的一棵树。Merkle树的叶子是数据块(例如，文件或者文件的集合)的hash值。非叶节点是其对应子节点串联字符串的hash。

MPT树的结点类型

前面说过MPT树是Trie、Patricia Trie、Merkle Tree这3种数据结构的结合，它包含4种结点类型：

• 空结点（NULL）

• 分支结点（branch node）：包含16个分支，以及1个value

• 扩展结点（extension node）：只有1个子结点

• 叶子结点（leaf node）：没有子结点，包含一个value

其中Prefix用于区分扩展节点和叶子节点。

4对key-value的MPT树

上图是包含4对key-value（图中右上角列出）的MPT树。MPT具有字典书的特征，可以用来高效查找，查找的过程大概如下：key与value均是二进制，在查找时将key的每个字节分为两半（也就是4bits，nibble），查找时按照nibble为单位进行查找。

以a711355这个key（图中右上角）为例，从root开始往下查找，由于所有的节点都以a7开始，所以root节点的shared nibble(s)字段包含了a7，这个节点指向一个分支节点（由hash指向而不是指针，这也就是merkle树特性的体现）。在a711355这个key中，a7之后是1，所以在这个分支节点中找到下标为1的值，这个值指向一个Leaf Node，到这里遍历完成，value就体现在这个Leaf Node中。

以太坊中的快速同步

以太坊为了解决节点启动同步慢的问题，在启动时可以指定同步的方式（syncmode），选项包括light, fast和full。其中full模式指的是在同步过程中同步全部数据，并依次验证和执行区块和交易；light模式只同步区块头，具体关心的交易都从全量节点拉取并证明，这种模式适用于轻量钱包客户端；fast模式除了同步区块头之外，也会同步交易以及receipt，与full模式不一样的是，fast模式并不执行交易。

问题来了，fast模式不执行交易那世界状态中的数据从哪里来呢？

具体的处理方法为：在快速同步到最新区块的时候，从别的节点同步世界状态，由于世界状态是MPT树，可以方便地验证其正确性。当同步完成MPT树之后，切换到full模式，也即一边同步之后的区块，一边执行交易以更新状态。

这个方法从一定程度上降低了新节点同步的代价，虽然从网络同步的数据并没有减少，但减掉了大部分的执行时间，并且不会产生太多老旧版本的状态树（试想每一个区块的root都是一个不同的树根）。

到这里我们知道，采用Account模型的系统中，对存储问题的处理要比UTXO模型更加灵活，因为UTXO中没有状态树，无法用fast模式进行快速同步。甚至Account模型中把老的交易和区块删除掉，仍然可以不影响挖矿的过程。

分布式存储

在Account模型的系统中，使用快速同步之后整个世界状态树将不那么大，因为不必要的老的树节点没有存下来。事实上也可以通过定期的MPT树裁剪，使得树保持相对小。如果是对空间敏感的节点，甚至可以把旧的交易或者区块删除掉。但是整个系统中，总需要一些全量的节点保存全量的数据，此时类似于mongodb的分布式存储就必不可少了。引入分布式存储的好处在于存储空间可以动态水平扩展，而且扩展之后对读写性能的影响基本可以忽略，这对于数据较大的区块链系统来说，是十分必要的。