專員之前跟大家聊過區塊鏈存儲的相關的話題，其實大家都知道，隨著時間的不斷流逝，區塊鏈上的交易會越來越多，隨之也就造成了區塊鏈的數據容量不斷增大，由於區塊鏈的冗餘備份，要求所有節點都需要保存全量的數據文件，這個時候，假如有一個用戶想用自己創建一個區塊鏈節點來進行DApp的開發，但是又不想參與共識，其實對於這個用戶來說，同步大量的數據是一件很耗時的事情，並且十分浪費相關的硬盤資源。
因此，專員今天想來跟大家講一下區塊鏈中的全節點以及輕節點的概念，專員的思考角度其實主要也是從以太坊這種賬戶模型去思考，今天也以以太坊作為例子來說這個事情。
以以太坊作為例子
在說全節點與輕節點相關介紹之前
專員首先向來跟大家說一下以太坊的區塊頭相關的東西，以太坊區塊的存儲主要分為兩個部分，分別是Header和Body，Body其實比較簡單，就是一些的交易列表，還有Uncle Block的相關信息，但是其實更為複雜的其實是Block Header，如下圖所示Block Header裡面會存比較多的數據，比如說父區塊的區塊hash，時間戳，挖礦的難度值等等相關的參數，
但是專員覺得，其中最重要的當屬以太坊中的“三棵樹”，與此對應在區塊頭中的就是，StateRoot，TransactionRoot和ReceiptRoot三個哈希值。
在以太坊中什麼用來存儲區塊數據的核心數據結構？
利用了一種叫做Merkle-Patricia Trie(MPT)是Ethereum用來存儲區塊數據的核心數據結構。
最簡單理解是一個倒置的樹形結構，每個節點可能有若干個子節點，在最底層，也就是葉子節點，把數據分成若干個小的數據塊，計算出相應的Hash與之對應。
但是往上層看去，Merkle樹並不是直接去運算根哈希，而是把相鄰的兩個節點的哈希合併成一個字符串，然後運算這個字符串的哈希，這樣每兩個哈希就能夠得到了一個”子哈希“，而這個自哈希就是他們的父節點的哈希值。
於是以此類推
依然是一樣的方式計算哈希值，可以得到數目更高級節點的新一級哈希，最終必然形成一棵倒掛的樹，到了樹根的這個位置，這一代就剩下一個根哈希了，我們把它叫做 Merkle Root。而在以太坊中，還對Merkle樹做了相應的優化，在Merkle樹的基礎上進行前綴樹的構建，因此也就通過前綴樹能夠快速查詢相關的數據信息，但是這個專員今天不細講，有興趣的同學可以私下去研究一下。
因此通過Merkle樹，其實我們可以做到幾個事情：
1. 快速重哈希：其實就是說，能夠在樹節點變化的情況下，根據上次的計算機結果通過計算部分值就可以計算出一個新的Merkle Root。
2. 輕節點擴展：採用Merkle樹，我們可以再公鏈的環境下，擴展一個輕節點。輕節點的特點其實就是，只需要存儲Block Header，而不存儲全量的交易列表等信息。通過Merkle證明來判斷一筆交易是否在現在的區塊鏈交易列表中。這樣，其實造就了以太坊的輕節點能夠運行在小容量的個人PC等終端設備上。
下面說回以太坊
在StateRoot，TxHashRoot和ReceiptHashRoot，分別取自三個MPT的計算結果：stateTrie, txTrie, 和receiptTrie的根節點哈希值。這樣的話，比如說我們在進行Block的同步過程中，通過比對收到的TxHash，可以確認transactions列表是否同步完整，通過StateRoot來判斷節點間狀態是不是一致的。
因此在以太坊中，所謂全節點，其實就是同步所有區塊鏈數據的節點，包括各種區塊Body，交易列表等等相關信息。但也是因為節點全量數據都保存的情況，我們不需要相依賴中介去進行數據的驗證。
而所謂的以太坊輕節點(輕客戶端)
每當有區塊出現在網絡便下載區塊頭，而不是全量的情況狀態，併發送客戶端需要的特定狀態的默克爾證明（Merkle proofs）的請求。同時在以太坊輕節點中使用分佈式哈希表來追蹤前綴節點，而不是直接採用LevelDB進行直接的存儲。
文末
綜上，其實不論是輕節點還是全節點，都有存在的價值以及意義，我們可以根據自己的需求去選擇部署相應的節點，雖說必然全節點的優勢會比輕節點大，但是由此造成的就是全節點的資源損耗也必然會大很多。
閱讀更多 區塊鏈技術專員 的文章
