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

最新内容会更新在主站深刻浅出区块链社区
原文连接:比特币区块结构Merkle树及简单支付验证分析

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

区块结构

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

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

咱们来看看一个区块结构究竟是怎样的：

如上图（下文称：区块结构图）所示：每一个数据区块包含区块头和区块体。
区块头封装了当前版本号、前一区块哈希值、当前区块PoW要求的随机数(Nonce)、时间戳、以及Merkle根信息。
区块体则包括当前区块通过验证的、 区块建立过程当中生成的全部交易记录。这些记录经过 Merkle树的哈希过程生成惟一的Merkle根并记入区块头.

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

区块头是80字节，而平均每一个交易至少是250字节，并且平均每一个区块包含2000个交易。所以，包含完整交易的区块比区块头的4千倍还要大。
SPV节点只下载区块头，不下载包含在每一个区块中的交易信息。这样的不含交易信息的区块链，大小只有完整区块链的几千分之1，那SPV节点是如何验证交易的呢？

哈希验证

上面先留一个引子，先来回顾下哈希函数，记帐原理咱们知道原始信息任何微小的变化都会哈希彻底不一样的哈希值。

简单文件验证

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

能够看到下载连接后面提供了一个MD5（MD5也是一种Hash算法），这样咱们能够在下载以后对文件计算MD5，若是MD5与提供的MD5相等，说明文件有没有被损坏，这个验证过程相信你们都能理解。

多点文件验证(哈希列表)

如今复杂度提升一点，在P2P网络中下载时，会把大文件切成小文件，同时从多个机器上下载数据，这个时候怎么验证数据呢？

以BT下载为例，在下载真正的数据以前，咱们会先下载一个哈希列表的（每一个下小块计算出一个哈希），若是有一个小块数据在传输过程当中损坏了，那我只要从新下载这一个数据块就好了，这时有一个问题就出现了，那么多的哈希，怎么保证它们自己(哈希列表中的哈希值)都是正确地呢？

答案是把每一个小块数据的哈希值拼到一块儿，而后对这个长字符串在做一次哈希运算，获得哈希列表的根哈希。只要根哈希校对比同样就说明验哈希列表是正确的，再经过哈希列表校验小数据块，若是全部的小数据块验证经过则说明大文件没有被损坏。

Merkle树

验证交易的过程和文件验证很类似，能够人为每一个交易是一个小数据块，但比特币使用Merkle树的方式进行验证，相对于哈希列表，Merkle树是一种哈希二叉树，它的明显的一个好处是能够单独拿出一个分支来（做为一个小树）对部分数据进行校验，更加高效。

咱们回看下上面的区块结构图，区块体就包含这样一个Merkle树,Merkle树被用来概括一个区块中的全部交易。

每一个叶子节点是每一个交易信息的哈希，往上对相邻的两个哈希合并成字符串再哈希，继续相似的操做直到只剩下顶部的一个节点，即Merkle根，存入区块头。

由于Merkle树是二叉树，因此它须要偶数个叶子节点。若是仅有奇数个交易须要概括，那最后的交易就会被复制一份以构成偶数个叶子节点，这种偶数个叶子节点的树也被称为平衡树。

简化支付验证

SPV节点不保存全部交易也不会下载整个区块，仅仅保存区块头，咱们来看看它是如何对交易数据进行验证的。

假如要验证区块结构图中交易6，SPV节点会经过向相邻节点索要（经过Merkleblock消息）包括从交易6哈希值沿Merkle树上溯至区块头根哈希处的哈希序列 (即哈希节点6, 5, 56, 78, 5678, 1234 1~8 - 称为认证路径) 来确认交易的存在性和正确性。（在N个交易组成的区块中确认任一交易只须要计算log2(N)个字节的哈希值，很是快速高效）

你们明白了吗？

深刻浅出区块链 - 系统学习区块链，打造最好的区块链技术博客