大家都知道，隨著時間的不斷流逝，區(qū)塊鏈上的交易會越來越多，隨之也就造成了區(qū)塊鏈的數據容量不斷增大，由于區(qū)塊鏈的冗余備份，要求所有節(jié)點都需要保存全量的數據文件，這個時候，假如有一個用戶想用自己創(chuàng)建一個區(qū)塊鏈節(jié)點來進行DApp的開發(fā)，但是又不想參與共識，其實對于這個用戶來說，同步大量的數據是一件很耗時的事情，并且十分浪費相關的硬盤資源。

因此，專員今天想來跟大家講一下區(qū)塊鏈中的全節(jié)點以及輕節(jié)點的概念，專員的思考角度其實主要也是從以太坊這種賬戶模型去思考，今天也以以太坊作為例子來說這個事情。

以以太坊作為例子

在說全節(jié)點與輕節(jié)點相關介紹之前

專員首先向來跟大家說一下以太坊的區(qū)塊頭相關的東西，以太坊區(qū)塊的存儲主要分為兩個部分，分別是Header和Body，Body其實比較簡單，就是一些的交易列表，還有Uncle Block的相關信息，但是其實更為復雜的其實是Block Header，如下圖所示Block Header里面會存比較多的數據，比如說父區(qū)塊的區(qū)塊hash，時間戳，挖礦的難度值等等相關的參數，

但是專員覺得，其中最重要的當屬以太坊中的“三棵樹”，與此對應在區(qū)塊頭中的就是，StateRoot，TransactionRoot和ReceiptRoot三個哈希值。

在以太坊中什么用來存儲區(qū)塊數據的核心數據結構？

利用了一種叫做Merkle-Patricia Trie（MPT）是Ethereum用來存儲區(qū)塊數據的核心數據結構。

最簡單理解是一個倒置的樹形結構，每個節(jié)點可能有若干個子節(jié)點，在最底層，也就是葉子節(jié)點，把數據分成若干個小的數據塊，計算出相應的Hash與之對應。

但是往上層看去，Merkle樹并不是直接去運算根哈希，而是把相鄰的兩個節(jié)點的哈希合并成一個字符串，然后運算這個字符串的哈希，這樣每兩個哈希就能夠得到了一個”子哈?！?，而這個自哈希就是他們的父節(jié)點的哈希值。

于是以此類推

依然是一樣的方式計算哈希值，可以得到數目更高級節(jié)點的新一級哈希，最終必然形成一棵倒掛的樹，到了樹根的這個位置，這一代就剩下一個根哈希了，我們把它叫做 Merkle Root。而在以太坊中，還對Merkle樹做了相應的優(yōu)化，在Merkle樹的基礎上進行前綴樹的構建，因此也就通過前綴樹能夠快速查詢相關的數據信息，但是這個專員今天不細講，有興趣的同學可以私下去研究一下。

因此通過Merkle樹，其實我們可以做到幾個事情：

1. 快速重哈希：其實就是說，能夠在樹節(jié)點變化的情況下，根據上次的計算機結果通過計算部分值就可以計算出一個新的Merkle Root。

2. 輕節(jié)點擴展：采用Merkle樹，我們可以再公鏈的環(huán)境下，擴展一個輕節(jié)點。輕節(jié)點的特點其實就是，只需要存儲Block Header，而不存儲全量的交易列表等信息。通過Merkle證明來判斷一筆交易是否在現在的區(qū)塊鏈交易列表中。這樣，其實造就了以太坊的輕節(jié)點能夠運行在小容量的個人PC等終端設備上。

下面說回以太坊

在StateRoot，TxHashRoot和ReceiptHashRoot，分別取自三個MPT的計算結果：stateTrie， txTrie， 和receiptTrie的根節(jié)點哈希值。這樣的話，比如說我們在進行Block的同步過程中，通過比對收到的TxHash，可以確認transactions列表是否同步完整，通過StateRoot來判斷節(jié)點間狀態(tài)是不是一致的。

因此在以太坊中，所謂全節(jié)點，其實就是同步所有區(qū)塊鏈數據的節(jié)點，包括各種區(qū)塊Body，交易列表等等相關信息。但也是因為節(jié)點全量數據都保存的情況，我們不需要相依賴中介去進行數據的驗證。

而所謂的以太坊輕節(jié)點（輕客戶端）

每當有區(qū)塊出現在網絡便下載區(qū)塊頭，而不是全量的情況狀態(tài)，并發(fā)送客戶端需要的特定狀態(tài)的默克爾證明（Merkle proofs）的請求。同時在以太坊輕節(jié)點中使用分布式哈希表來追蹤前綴節(jié)點，而不是直接采用LevelDB進行直接的存儲。

文末

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