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

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

区块结构

在工作量证明中出现过一个区块信息截图：

细心的同学一定已经在里面发现了很多未讲的其他信息，如：时间戳，版本号，交易次数，二进制哈希树根(Merkle根)等。

我们来看看一个区块结构到底是怎样的：

区块结构图

如上图（下文称：区块结构图）所示：每个数据区块包含区块头和区块体。

区块头封装了当前版本号、前一区块哈希值、当前区块PoW要求的随机数(Nonce)、时间戳、以及Merkle根信息。

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

区块哈希值实际上并不包含在区块的数据结构里，其实区块打包时只有区块头被用于计算哈希（从网络被接收时由每个节点计算出来），常说的区块哈希值实际是区块头哈希值，它可以用来唯一、明确地标识一个区块。

区块头是80字节，而平均每个交易至少是250字节，而且平均每个区块包含2000个交易。因此，包含完整交易的区块比区块头的4千倍还要大。

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

哈希验证

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

简单文件验证

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