在比特幣網絡中，不是每個節點都有能力儲存完整的區塊鏈數據，受限于存儲空間的的限制，很多節點是以SPV(Simplified Payment Verification簡單支付驗證)錢包接入比特幣網絡，通過簡單支付驗證可以在不必存儲完整區塊鏈下對交易進行驗證，本文將分析區塊結構Merkle樹及如何進行交易驗證。

　　區塊結構

　　在工作量證明中出現過一個區塊信息截圖：

　　細心的同學一定已經在里面發現了很多未講的其他信息，如：時間戳，版本號，交易次數，二進制哈希樹根(Merkle根)等。

　　我們來看看一個區塊結構到底是怎樣的：

　　如上圖(下文稱：區塊結構圖)所示：每個數據區塊包含區塊頭和區塊體。

　　區塊頭封裝了當前版本號、前一區塊哈希值、當前區塊PoW要求的隨機數(Nonce)、時間戳、以及Merkle根信息。

　　區塊體則包括當前區塊經過驗證的、 區塊創建過程中生成的所有交易記錄。這些記錄通過 Merkle樹的哈希過程生成唯一的Merkle根并記入區塊頭.

　　區塊哈希值實際上并不包含在區塊的數據結構里，其實區塊打包時只有區塊頭被用于計算哈希(從網絡被接收時由每個節點計算出來)，常說的區塊哈希值實際是區塊頭哈希值，它可以用來唯一、明確地標識一個區塊。

　　區塊頭是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)個字節的哈希值，非常快速高效)

　　大家明白了嗎?