背景
背景
背景
二級標題
DeFi、GameFi等去中心化應用的蓬勃發展，極大地增加了對低交易費用的高性能區塊鏈的需求。然而，構建高性能區塊鏈的一個關鍵挑戰是存儲爆炸。下圖是取自Etherscan 的圖表，它說明了一個以太坊全節點（存檔）的區塊鏈數據大小。
分解存儲開銷
區塊
區塊
如果我們進一步分析存儲使用情況，我們可以發現區塊數據只佔了約300GB的數據（從區塊高度0到13.6M），這一數字遠小於9TB。那麼剩下的8.7TB數據從何而來呢？
區塊
區塊
狀態
交易收據
這其中，狀態是這8.7TB 的主要組成部分。所以有時，我們將存儲爆炸稱為“狀態爆炸”。但是為什狀態會如此之大？
葉子節點是地址(0x...) => 帳戶的映射，其中帳戶存儲與地址關聯的餘額、nonce等
二級標題
內部節點維護樹結構，以便可以快速計算整個樹的哈希根
Geth 的全節點
二級標題
為了解決存檔節點狀態爆炸的問題，Geth 的天才工程師們創建了一種稱為“修剪”模式的新模式，該模式僅定期存儲MPT。這裡我們舉一個簡化的例子，其中節點只保存每3 個區塊的MPT。 （注意，為了獲得一個不包含任何狀態區塊的狀態，節點必須獲得該區塊之前最近的狀態，並重放接下來的交易）。
通過從創世區塊開始重放所有交易來運行節點的一個問題是，重放所有交易會佔用很長時間。一般來說，建立這樣一個節點需要數週時間才能從創世區塊趕上網絡的最新狀態。為了加速節點的啟動過程，Geth 進一步提供了一種快速同步模式，可以下載最新的穩定區塊的MPT，而無需重放和維護區塊之前的歷史MPT。下載完MPT 後，它會像全節點一樣重放新區塊（帶有定期狀態存儲）。
問題
問題
問題
二級標題
問題
以目前以太坊447GB 的存儲大小和15 TPS，我們預計具有1TB SSD 的普通配置計算機應該能夠運行以太坊節點相當長的一段時間（比如數年）。那麼存儲爆炸或狀態爆炸真的存在嗎？或許未來幾年以太坊並不會，但假如我們可以將以太坊的虛擬機(EVM) 擴展到數百或數千TPS 呢？
讓我們將目光轉向另一個基於EVM 的鏈，幣安智能鏈（BSC）。截至2021 年12 月8 日，BSC 已有：
約984 GB 鏈上數據，其中區塊約佔550 GB，狀態約佔400 GB。
20.6623 億筆交易，100 TPS
如果我們進一步用交易數量來預測數據大小，我們可以得到：
如果TPS 為100，即~3,153 M TPY
1 年後，總TX ~5,219M，區塊~ 1.375 TB，狀態~ 1.085TB
3 年後，總TX ~11,525M，區塊~3.025TB，狀態~2.387 TB
如果TPS 為150（觀察到的峰值TPS），即~4,730 M TPY
1 年後，總TX ~6,796M，區塊~1.809 TB，狀態~1.427 TB
3 年後，總TX ~16,256M，區塊~4.327 TB，狀態~3.414TB
綜上所述，對於BSC來說，如果保持目前的速度甚至更高，則很快就會達到以太坊存檔節點相同的存儲大小，這是普通計算機幾乎無法運行的。
具有極高TPS 區塊鏈的存儲爆炸問題
如果我們對一個極高TPS 的區塊鏈（比如像QuarkChain 能夠做到的那樣）做一個更大膽的假設，這個數字會變成多少？我們來考慮一個具有1000 TPS 的區塊鏈並分析其區塊和狀態大小，將是：
將這些數字放在一起，我們很容易得出一個結論，這是大多數普通配置計算機將無法承受的要求！
二級標題
優化
二級標題
二級標題
狀態存儲優化
我們提出的第一個優化是使用普通的KV 而不是MPT。當MPT 很大時，MPT 中的所有內部節點可能非常昂貴。而我們的優化將去掉MPT 中的所有內部節點。假設每個賬戶的數據大約是50 字節（20 個地址+ 2 個nonce + 12 個賬戶+ 其他），我們可以節省下100億賬戶的數據為：
~ 10B * 50 + 100GB（代碼）= 600 GB，大約是MPT版本的1/10！
雖然使用普通KV 會帶來巨大的好處，但一個主要問題是我們無法在如此短的區塊間隔內計算每個區塊的狀態後哈希，這意味著我們將失去以太坊的以下好處：
快速同步：下載任何區塊的狀態並通過重放剩餘的區塊來快速同步網絡
分叉檢測（或拜占庭檢測）：來自對等方新創建的區塊是否會導致與本地執行區塊的狀態不同。
為了啟用快速同步，我們有一個週期性的快照區塊（快照間隔= epoch = 例如，14 週）。一個快照區塊包含前狀態哈希這一附加信息，即前一個快照區塊的後狀態哈希（執行交易之後的狀態哈希）：
非快照區塊不維護狀態哈希，而是具有增量哈希，其中包含該區塊的所有交易事務的原始數據庫操作（刪除、更新）的哈希。這使得分叉檢測成為可能！
我們使用交易前狀態哈希來代替以太坊中區塊的交易後狀態哈希。原因是節點不能立即計算狀交易後的狀態哈希，但是通過使用交易前狀態哈希，節點可以使用整個epoch間隔來計算哈希。例如，假設狀態哈希計算每秒處理10M 的狀態數據，那麼計算600 GB 的整個狀態將需要600 GB / 10 M ~ 16.67 小時（vs. epoch = 14 週）
2. 當下一個快照區塊被創建時，計算出的狀態前哈希值將存儲在該區塊中。同樣，節點將創建KV 的另一個快照並在後台計算其哈希。
二級標題
3.當下一個快照區塊被創建時，節點除了存儲狀態前哈希之外，節點現在可以釋放快照區塊的KV快照，這意味著來自快照區塊以來所有被刪除/更新的數據將被自動垃圾回收（例如，在levelDB 中壓縮）
二級標題
二級標題
區塊存儲優化
使用快照區塊，我們可以通過僅存儲以下數據來進一步減少節點中所需的區塊數據：
2 * 14（天）* 24（小時）* 3600（秒）* 100 * 1000（TPS）= 224 GB！
總結
總結
總結
二級標題
總結
我們分析了以太坊當前的存儲使用情況：
不僅是區塊，狀態存儲消耗了很多的空間
當TPS > 1000 時，存儲空間用量高得令人望而卻步
狀態大小（~10B 帳戶）從8.3 TB 減少到600 GB
致謝
致謝
一台2TB 的普通配置計算機應該能滿足長時間運行節點的條件
IOS
Android