前面一篇文章（分析之三）中提到了以太坊的資料儲存越來越大，有個資料“瘦身”的問題，本文中具體討論下。

以太坊是一個去中心化的區塊鏈系統，資料不是存放在中心伺服器上，而是存在客戶端的硬碟上。目前以太坊發展遇到一個現實問題：安裝過以太坊客戶端，挖過礦的同學想必都知道安裝完後同步要好幾天，資料高達幾十G，在個人電腦上安裝全客戶端已經有點勉強了，更不要說是手機等輕客戶端。這種情況發展下去，比如出現中心化，也就是隻有一部分企業級使用者會安裝全客戶端，個人客戶對資料的驗證只能依賴代理的企業，這個和區塊鏈去中心化的理念背道而馳。幸虧現在有了快速同步的技術，讓“臃腫”的以太坊資料成功“瘦身”。

以去年我下載的舊版本的geth為例，資料同步到2/3已經有40G了，因為體積太大網路較慢硬碟不夠用一直同步不了；今年這個月，我用了新版本的geth，開啟了快速同步特性（geth --fast），大概15個G一個晚上就完成了同步，處在可以挖礦的模式了。原因就是快速同步時不需要將所有歷史交易全部重新回放一遍，減少了CPU的工作量，加快了速度（原先慢不是因為網路下載區塊鏈資料頻寬的問題，而是需要CPU驗算時間）。

以太坊創始人Vitalik談到以太坊瘦身，第一個特性就是fast syncing和state tree pruning的概念； fast syncing的意思是一個新的節點不需要下載和驗證整個區塊鏈，反而只需要下載每個交易的收據（receipt），然後可以用梅克爾樹的模式下載和驗證最新的狀態。這樣同步的時間更快。也就是說快速同步只關心交易結果，並不會把歷史交易全部重新做一遍來驗證。state tree pruning的意思是自動刪除不再有效梅克爾樹的樹枝； 這樣應該可以減少儲存的需求5-10倍。為什麼快速同步模式不僅快，資料庫體積還小？因為LevelDB是種層級儲存的模式，其實舊狀態也儲存著，只不過在比較深的level，讀取時讀取不到，Get時讀取的是淺層level的最新狀態，這種歷史資料在快速同步時是沒有同步過來的，大部分情況下也不需要關心（我安裝了快速節點，部分交易歷史無法顯示了，但是賬戶餘額絕對是正確的），從而有效減少了儲存體積。

也就是說，以太坊資料大，是因為交易歷史明細多，之前的交易歷史明細如果不再關心了，可以用fast模式不同步下來（Trie樹就少了），對個人使用者而言是足夠了。不過對交易所而言，要儲存所有的歷史記錄，所以這樣就不夠了。我有個在交易所工作的前同事，透露交易所的以太坊節點，儲存了所有Trie樹，體積超過一個TB！

所以，到底需要儲存多少資料，也是看需求。