比特币区块结构Merkle树分析及如何验证交易

在比特币网络中，并不是每个节点都有能力存储完整的区块链数据。 由于存储空间的限制，许多节点使用SPV（Simplified Payment Verification）钱包访问比特币网络。 通过简单的支付验证，无需存储完整的区块链即可验证交易。 本文将分析区块结构 Merkle 树以及如何进行交易验证。

块状结构

工作量证明中出现的区块信息截图：

细心的同学一定发现了很多里面没有提到的其他信息，比如：时间戳、版本号、交易次数、二叉哈希树根（Merkle root）等。

让我们看一下块结构是什么样的：

如上图（以下简称：块结构图）所示：每个数据块包括块头和块体。

区块头封装了当前版本号、前一个区块的哈希值、当前区块PoW所需的随机数（Nonce）、时间戳、Merkle根信息。

区块体包括所有在区块创建过程中产生的、在当前区块中已经验证过的交易记录。 这些记录通过 Merkle 树的哈希过程生成一个唯一的 Merkle 根，并记录在区块头中。

区块哈希值实际上并不包含在区块的数据结构中。 实际上，在打包区块时，只有区块头用于计算哈希值（每个节点在从网络接收时计算）。 区块哈希值实际上就是区块头哈希值，可以用来唯一无歧义地标识一个区块。

区块头80字节，平均每笔交易至少250字节，每个区块平均包含2000笔交易。 因此，包含完整交易的区块比区块头大 4000 倍。

SPV 节点只下载区块头，不下载每个区块中包含的交易信息。 这样一条没有交易信息的区块链只是完整区块链的千分之几，那么SPV节点如何验证交易呢？

哈希验证

上面先不做介绍，先来回顾一下哈希函数，记账原理 我们知道，原始信息的任何细微变化都会哈希出一个完全不同的哈希值。

简单文件验证

我们通常使用哈希来检查下载的文件是否完整，我经常看到这样的下载页面：

可以看到下载链接后面提供了一个MD5（MD5也是一种Hash算法），这样我们就可以计算出下载后文件的MD5。 如果MD5与提供的MD5相等，说明文件没有损坏。 这个验证过程相信大家都能看懂。

多点文件校验（哈希表）

现在复杂度有点高了。 在P2P网络下载时，会将大文件切割成小文件，同时从多台机器下载数据。 这时候如何验证数据呢？

以BT下载为例，在下载真正的数据之前比特币区块体记录了哪些信息，我们会先下载一个hash列表（对接下来的每个小块计算一个hash），如果在传输过程中有一小块数据损坏了，那么我就重新下载这个数据堵塞。 这时候，问题就出现了。 这么多哈希，怎么保证它们自己（哈希列表中的哈希值）都是正确的呢？

答案就是把每一小块数据的哈希值拼在一起，然后对这个长字符串进行哈希运算，得到哈希列表的根哈希。 只要根哈希比较相同，就说明验证哈希列表正确，再通过哈希列表验证小数据块。 如果所有小数据块都校验通过，则说明大文件没有损坏。

默克尔树

验证交易的过程与文件验证非常相似。 每笔交易都可以看作是一个小数据块，但比特币使用默克尔树进行验证。 与哈希列表相比，默克尔树是一种哈希二叉树。 其明显的好处之一是可以单独取出一个分支（作为一棵小树）来验证部分数据，效率更高。

我们回过头来看上面的区块结构图，区块体中包含这样一棵Merkle树，Merkle树就是用来概括一个区块中的所有交易的。

每个叶子节点都是每笔交易信息的哈希值，相邻的两个哈希值合并成一个字符串再进行哈希运算，不断进行类似的操作，直到只有最顶端的一个节点，即默克尔根存入区块头.

因为 Merkle 树是二叉树，所以它需要偶数个叶节点。 如果只需要汇总奇数笔交易比特币区块体记录了哪些信息，则复制最后一笔交易，组成偶数个叶子节点。 这种叶子节点数为偶数的树也称为平衡树。

简化付款验证

SPV 节点不保存所有交易，也不下载整个区块，只保存区块头。 让我们看看它如何验证交易数据。

如果要验证区块结构图中的交易6，SPV节点会要求相邻节点（通过Merkleblock消息）包含从交易6的哈希值沿着Merkle树到区块根哈希的哈希序列header（即哈希希腊节点 6, 5, 56, 78, 5678, 1234 1~8 - 称为认证路径）确认交易的存在和正确性。 （在N笔交易组成的区块中确认任意一笔交易只需要计算log2(N)字节的哈希值，非常快速高效）

你明白吗？