前提知識儲備
- 為什么要有SPV（Simplified Payment Verification）？
完整的比特幣數(shù)據庫（也就是區(qū)塊鏈）需要超過 140 Gb 的磁盤空間彤钟。因為比特幣的去中心化特性来候，網絡中的每個節(jié)點必須是獨立，自給自足的逸雹，也就是每個節(jié)點必須存儲一個區(qū)塊鏈的完整副本营搅。隨著越來越多的人使用比特幣，這條規(guī)則變得越來越難以遵守：因為不太可能每個人都去運行一個全節(jié)點梆砸。并且转质，由于節(jié)點是網絡中的完全參與者，它們負有相關責任：節(jié)點必須驗證交易和區(qū)塊帖世。另外休蟹，要想與其他節(jié)點交互和下載新塊，也有一定的網絡流量需求。
SPV 是一個比特幣輕節(jié)點赂弓，它不需要下載整個區(qū)塊鏈绑榴，也不需要驗證區(qū)塊和交易。相反盈魁，它會在區(qū)塊鏈查找交易（為了驗證支付）翔怎，并且需要連接到一個全節(jié)點來檢索必要的數(shù)據。這個機制允許在僅運行一個全節(jié)點的情況下有多個輕錢包备埃。
Full Peer會儲存完整的Block：Block Size + Block Header + Transaction Counter + Transactions姓惑，其中占用存儲空間最大的就是Transactions，而Block Header里面包含了這個Block.Merkle Root Path按脚，這個Hash值在計算整個Block的Hash時候會被用到于毙。
SPV (Simplified Payment Verification) Client只存精簡的Block：Block Size + Block Header。根本沒有真實的交易詳細信息辅搬，所以體積小唯沮。
SPV交易之間要解決的問題
A用戶向商戶B 發(fā)起了一筆比特幣轉賬，并且告知B 堪遂，這筆交易的Txid和SPV上面的Block 信息介蛉，于是B根據Txid和Block信息币旧，同時向多個FullPeer去confirm這筆交易是否真的存在猿妈。Merkle Tree就是要解決這個問題！
Merkle Tree的一些相關事情
- Merkle Tree生成原理不解釋 了鳍刷，參考其它的博客吧输瓜，我只寫你搜不到的內容芬萍。
- Merkle Tree的第一大功能是：在生成區(qū)塊的時候，對所有的交易按照樹形結構生成了一個摘要信息（Root Node.path）芹缔，這就是壓縮值最欠，這讓SPV的實現(xiàn)奠定了基礎示罗。
Merkle Tree在交易確認時候的作用
SPV向一個Full Peer發(fā)送 Block信息和 TXID蚜点，查詢這筆Txid是否存在在這個Txid里面（假設是HK交易）绍绘，F(xiàn)ullPeer根據Block.Hash值迟赃，先找到這個Block，然后遍歷Block的Transactions數(shù)組左刽，可以理解為遍歷Transaction.Txid是否一樣欠痴，如果沒有，就直接返回SPV交易不存在喇辽，如果有的話雨席，那么就要根據下圖的信息，傳輸HL旦委、HIJ、HMNOP 和 HABCDEFGH的值
所以SPV收到Peer的一串值的時候摩钙，就可以根據這些值，計算出在這個Block的MerkleRootNode.data了（也叫RootPath）网持，如果和自己的SPV里面的RootPath一樣长踊，那么說明這筆交易在區(qū)塊鏈中真實存在
精華
為什么計算RootPath要用Merkle Tree身弊，而不用List呢列敲？
我們在計算Block Hash的時候帖汞，可以把所有的Transactions的Txid翩蘸，拼接起來，對拼接值進行 Sum256扶踊，得出一個 RootPath，因為這種方式的數(shù)學上的運算量是最小的秧耗，而Merkle Tree需要重重計算Hash值绣版。為什么FullPeer在Check到這筆交易存在在Block中是杂抽，要返回HL、HIJ缩麸、HMNOP 和 HABCDEFGH的值杭朱，而不是直接返回RootPath呢吹散？要知道RootPath本身就存在了的消息頭里面的，都不需要進行運算的刃唐，而且一個RootPath傳輸?shù)捏w積更小界轩。
為什么SPV要向多個節(jié)點同時發(fā)起交易是否存在的confirm請求？
Merkle Tree的優(yōu)勢在于：在傳輸空間和數(shù)據不可篡改上都做到很好
為什么不支持返回RootPath抖甘，因為只返回一個RootPath是沒有辦法讓SPV相信這個結果是真實的衔彻，因為比特幣的系統(tǒng)中，要FullPeer是可能造假的米奸。可能Txid不存在慢睡，但是Peer卻告訴SPV存在铡溪，SPV無法驗證這個結果是否可靠。但是通過傳輸HL髓涯、HIJ哈扮、HMNOP 和 HABCDEFGH的值卻可以驗證，這個交易是真實存在的包各，因為RootPath的計算是不可逆的问畅，可以通過結合這些相鄰節(jié)點的Hash值六荒，計算出RootPath，這個計算值如果和SPV里面的值是一樣的卵皂，就可以證明這個交易真實存在渐裂，且不是Peer造假的钠惩，因為哈希加密是不可逆的族阅，Peer是無法偽造一些假的 HL坦刀、HIJ、HMNOP 和 HABCDEFGH的值來讓這些值和 當前Txid求出RootPath的沐寺。
為什么不用數(shù)組，因為樹形結構的話狐援，只要返回4個Hash值（HL啥酱、HIJ镶殷、HMNOP 和 HABCDEFGH）就可以確認該筆交易是否可靠微酬，但是如果是數(shù)組的話，則需要把整個數(shù)組的全部Hash值都傳給SPV陷遮，否則就沒有辦法計算RootPath拷呆。
SPV要向多個節(jié)點發(fā)起confirm請求，是為了降低造假的可能性茬斧。比如同時向10個Full Peer去查詢這筆交易项秉，9個Peer都說不存在慷彤，而1個Peer返回存在，那么該交易一定存在岁诉，且9個Peer的數(shù)據是造假的涕癣，因為Peer是無法偽造HL坠韩、HIJ、HMNOP 和 HABCDEFGH的值音比。
參考資料
http://www.reibang.com/p/bfda51cd340d
http://www.reibang.com/p/1abffeac87fc
