比特币区块结构默克尔树及简单支付验证分析

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

块结构

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

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

我们来看看块结构是什么样的：

如上图（以下简称：块结构图）所示：每个数据块包含一个块头和一个块体。区块头封装了当前版本号、前一个区块的哈希值、当前区块的 PoW 所需的随机数（Nonce）、时间戳和 Merkle 根信息。块体包括在当前块中被验证并在块创建过程中产生的所有交易记录。这些记录是由默克尔树的哈希过程产生的，生成一个唯一的默克尔根，并记录在区块头中。

区块哈希值实际上并不包含在区块的数据结构中。实际上，在打包区块的时候，只有区块头用来计算哈希（每个节点从网络接收到的时候计算），常说的区块哈希其实就是区块头哈希，它只能用来一、 明确标识一个块。

区块头80字节，平均交易至少250字节，平均区块包含2000笔交易。因此，包含完整交易的区块比区块头大 4000 倍。 SPV 节点只下载块头，而不是每个块中包含的交易信息。这样一个没有交易信息的区块链只有完整区块链大小的千分之一。 SPV节点如何验证交易？

哈希验证

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

简单的文件验证

我们通常使用哈希来验证下载文件的完整性，我经常看到这样的下载页面：

@ >

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

多点文件校验（哈希表）

现在复杂性有所提高。在P2P网络下载时，大文件会被切割成小文件，多台机器同时下载。上传和下载数据，此时如何验证数据？

以BT下载为例，在下载真实数据之前，我们会先下载一个hash列表（每下一个小块计算一个hash），如果有小块数据在传输过程中损坏这个过程比特币余额查询，那么我只需要重新下载这个数据块。这时候，就有问题了。这么多的hash，如何保证它们自己（hash列表中的hash值）是正确的呢？

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

默克尔树

验证交易的过程与文件验证非常相似。每笔交易都可以人为地做一个小数据块，但是比特币使用 Merkle 树的方法进行验证，相比于 Hash 列表，Merkle 树是一个哈希二叉树，其明显的优势之一就是可以取出一个单独的分支（如一棵小树）来验证部分数据，效率更高。

回看上面的区块结构图，区块体中包含这样一棵默克尔树，用来汇总一个区块中的所有交易。

每个叶子节点是每个交易信息的hash，将相邻的两个hash合并成一个字符串再hash，继续类似的操作，直到只剩下顶部节点，也就是Merkle根，存储在区块头中。

因为默克尔树是二叉树，它需要偶数个叶子节点。如果只需要汇总奇数笔交易，则复制最后一笔交易比特币余额查询，形成偶数个叶子节点。这种叶节点数为偶数的树也称为平衡树。

简化付款验证

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

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

你明白吗？

区块链通俗——打造优质区块链技术博客，来这里了解区块链，关注知乎和微博，掌握区块链技术动态。我的知识星球为你解答区块链技术问题，欢迎加入讨论。