大家都知道，隨著時間的不斷流逝，區塊鏈上的交易會越來越多，隨之也就造成了區塊鏈的數據容量不斷增大，由于區塊鏈的冗余備份，要求所有節點都需要保存全量的數據文件，這個時候，假如有一個用戶想用自己創建一個區塊鏈節點來進行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進行直接的存儲。

文末

綜上，其實不論是輕節點還是全節點，都有存在的價值以及意義，我們可以根據自己的需求去選擇部署相應的節點，雖說必然全節點的優勢會比輕節點大，但是由此造成的就是全節點的資源損耗也必然會大很多。