区块链说数据没被篡改过是不是在骗你？

【背景介绍】

前文《打破K/V存储的性能瓶颈》中，我们提到用一个哈希值来反映区块链系统中所有对象的当前状态集合，并称之为“世界状态”。现在大多数区块链底层平台为了支持与其他链集成，或者为了部署在更小的终端，都会提供轻节点的功能，轻节点也就是存储少量数据的“轻量级节点”，但因为没有存储全量数据，无法对其他节点的数据进行正确性的验证。这里便需要其他节点生成一份数据证明，配合轻节点本地保存的“世界状态”来进行数据的验证。

这份数据证明是什么？又是怎么实现的？带着这份疑问，本文将详细介绍目前主流的数据证明的实现以及解决方案和优化思路。

【默克尔证明】

介绍数据证明前，我们先要了解传统的默克尔树，以及对应的证明生成和验证的流程。

默克尔树（Merkle Tree），因发明人叫Merkle，并且是树形结构而得名。如下图，默克尔树的叶节点存储数据或者数据的哈希值，任一父节点包含了其子节点总和的哈希值。

默克尔树最大的作用便是快速校验部分数据是否在原始数据中。

举个例子，要想验证L2在上图的这棵树上，只需要节点列表[L2，Hash0-0，Hash1]即可，通过L2可以计算出Hash0-1，通过Hash0-1与Hash0-0可以计算出Hash0，再通过Hash0与Hash1，便可以得到一个树根，再把该树根与Top Hash进行比对即可快速验证L2是否在树中。默克尔树生成数据证明以及验证数据证明的原理就是如此，生成证明时自底向上，不断获取父节点的兄弟节点，打包成数据证明；验证时通过遍历证明中的节点列表，不断进行哈希得到父节点的操作，最后可以得到树根节点，再把该树根与原树根进行比对，达到验证的目的。

这种基本的默克尔树广泛应用在区块链系统中，例如比特币中轻钱包的SPV（简单支付验证）便是应用该原理，比特币中区块记录的root便是区块中交易集合构成的默克尔树的树根，使得无需下载完整区块，只需要区块头便可以验证某条交易的有效性。

【以太坊上的数据证明】

默克尔树虽然满足了数据证明以及验证的需求，但是其二叉树的结构，会使其在存储庞大的状态数据时，造成中间节点太多，有存储压力大的问题；并且默克尔树在对数据的增删改查方面没有解决方案，我们知道状态数据在执行合约时需要频繁的读写，因此可以对数据进行查询修改也是非常重要的，针对以上几点问题，以太坊提出了默克尔帕特里夏树（Merkle Patricia Tree，下文称MPT）。

▲什么是MPT？

MPT主要结合了默克尔树和前缀树的特点，前缀树顾名思义，是一种利用字符串的公共前缀来进行查询的树，如下图所示，用来查询有共同前缀的数据不需要进行字符的比对，十分方便，但缺点也十分明显，如果一个字符串与其他节点没有公共前缀时，便会带来很多节点的创建，造成存储空间的浪费。

基于默克尔树以及前缀树的优缺点，MPT提出了四种节点类型：

1）空节点：用来表示空字符串；

2）分支节点：用来表示MPT树中所有拥有超过1个子节点以上的非叶子节点，最多能容纳十六个子节点；

3）叶子节点：表示为 [key, value]的一个键值对，其中key是一种十六进制编码(HP编码)，value是节点具体内容的RLP编码；

4）扩展节点：同样表示为[key, value]的一个键值对 ，不过value是其他节点的hash值 ，这个 hash可以被当做key，用来在数据库中查询子节点；

相比于普通的前缀树以及默克尔树，MPT加入了扩展节点，可以将不共享的前缀压进一个节点，带来路径压缩的特性，降低了树的高度，减少了空间浪费；分支节点的加入，使得单个节点最多能有十六个分叉，同样也是降低了树高；并且通过哈希值进行树节点间的连接，确保了安全性与可验证性。

对MPT上的数据进行增删改查，需要通过前缀索引到对应的节点，叶子节点的改动会带来新的分支节点或者扩展节点的加入，新的节点需要进行哈希计算得出新的哈希值，然后更新父节点的信息，造成索引路径上节点的哈希值的连锁的改动，最后生成一个唯一的“世界状态”。

在MPT上，要想生成数据证明，也需要沿着树进行前缀的索引，并把索引路径上的节点打包成证明返回即可。验证数据证明的时候，需要验证叶子节点中键的正确性，并且对证明中的节点列表进行自底向上的哈希操作，最后比对树根的值即可。

▲性能瓶颈

上文提到以太坊是以节点的哈希值作为数据库存储节点的键，这些节点的存储与区块号或交易并没有任何绑定关系，并且散落在整个状态空间中的，那么随着交易量的增大，状态变迁带来的新节点也会增多，数据存储压力会越来越大。

由于以太坊底层采取的是leveldb存储，对于每个键值的读取最坏情况下需要一次磁盘IO，那么在执行合约的时候，将会有大量的时间耗费在状态的读取中，久而久之系统整体的性能会越来越差。

【联盟链下如何优化？】

当下主流数据库一般分为两种：以LSM树为主的数据库例如leveldb、rocksdb；还有以B+树为主的数据库例如mysql。相同条件下B+树的读要比LSM树更有效率，在联盟链场景下，我们知道大部分应用场景都是读多写少，那么针对联盟链，能不能基于B+树来提出一种既能实现数据证明，又可以兼顾到读写性能的方法呢？答案是肯定的，我们提出了一种默克尔B+树的结构，结合了B+树以及默克尔树的特点，降低了查询所需的磁盘IO以及存储的数据量，在保持高性能的同时，还能提供数据证明、数据可验证的功能。

▲什么是默克尔B+树？

B+树是一种n叉的平衡查找树，所有键值对都会按键值的大小顺序存放在最后一层叶子节点中，父节点会记录其连接的子节点的最小键值，方便索引。

默克尔B+树以B+树为基础，包含了两种节点：处于最后一层的数据节点、索引节点，该树具有以下的特点：

1）每个节点会有一个ID；

2）索引节点的子节点列表中存放了子节点的最小键以及哈希值；

3）数据节点的子节点列表存放的是[key，value]状态数据键值对；

4）每个节点的哈希值由它的子节点列表总和的哈希值得出；

如上图，将状态数据以键值对的形式存入数据节点，每个节点最后会以页的形式存放到磁盘中，为了更适应磁盘的读写策略，规定每个页大小为4K（磁盘页大小通常为4K），这样就可以通过计算出页ID*页大小的偏移量从磁盘读取某个节点。

同样我们规定每个节点最多容纳4K的数据，如果某个数据节点插入太多键值对，导致其超过了4K的阈值，将会产生分裂，变为多个不超过阈值的新数据节点，并把对应的新节点信息插入到原父节点的子节点列表中，再递归检查父节点即索引节点是否超过阈值，如果超过将会重复分裂过程。

这里我们会提供一个最大页ID以及空闲ID列表来管理页ID，当新建了一个节点时，会先去空闲ID列表查询一下是否存在满足条件的ID，有则取出来分配给新节点，否则会把最大页ID分配给新节点，并递增最大页ID。有分配自然就会有回收，当节点A分裂为节点B和节点C时，节点A的页ID就会被回收，纳入到空闲ID列表中。当发现某个节点变为空节点时，也会被回收页ID。

由于默克尔B+树在每个节点都存储了哈希值，每次对状态数据的增删改查，都会造成底层数据节点的变动，进而影响从数据节点到根节点路径上的节点哈希值，最后生成出唯一的“世界状态”。

在生成数据证明时，同样是沿着树根，通过键的比对向下索引，并把索引路径上的节点打包成证明返回即可。验证数据证明的时候，可以在数据证明中的节点路径进行同样的索引操作，验证索引路径的一致性，并且进行节点哈希值的正确性校验，最后比对树根的值即可。

▲优化思路

根据上文来看，默克尔B+树确实可以实现较高的读写效率以及可验证性，但是还有很大的优化空间，基于此，我们打算从优化磁盘读的角度提出优化思路。

对于节点限制在4K大小这点，可以有效提高节点分叉数，降低树高，进而降低磁盘IO次数，但是仍然需要log(n)次的磁盘IO，为了最大化降低IO次数，我们把索引节点与数据节点分开存储为索引文件和数据文件。索引节点中可以认为只存放了键，因此索引文件远远小于数据文件，把索引文件通过mmap（内存映射）的形式维护在内存中，这样对底层的数据的读取只需要数据文件的一次磁盘IO即可，大大提升了读效率，在联盟链读多写少的场景下具有较大的优势。

【小结】

本文是存储系列推文的延续，主要阐述了区块链中数据证明的实现。

首先介绍了对状态数据做数据证明的背景需求，并以以太坊为例，详细介绍其状态数据存储结构MPT，阐述了在MPT上数据证明以及验证的实现，并进一步分析了以太坊的性能瓶颈。

针对联盟链读多写少的场景，本文提出了一种以默克尔B+树为基础的解决方案，解释了在默克尔B+树上的数据证明以及验证的实现，并且为了进一步提高性能，提供了优化思路，通过索引与数据分离的方式来完善可用性。

作者简介

郑柏川

趣链科技基础平台部 区块链存储研究小组

参考文献

[1]?https://github.com/ethereum/go-ethereum

[2]https://en.wikipedia.org/wiki/Merkle_tree

查看更多

—-

编译者/作者：趣链科技

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。