Ethereum中所有的開銷管理都被統一到gas計費模型之下，交易的大小需要消耗對應的gas ，而每一條EVM指令消耗的gas，不僅考慮了計算開銷，也將存儲開銷考慮在內。通過每個區塊的gaslimit，間接限制了歷史和狀態的增長速度。
ps. 常見的一個誤解是，Ethereum的「區塊鏈大小」已經超過1T了。從上面的分析我們可以看到，「區塊鏈大小」是一個非常模糊的定義，如果把歷史狀態算進去，確實超過了，但對于全節點來說，把歷史狀態刪掉沒有任何問題，因為只要有Genesis和交易歷史，任意時刻的歷史狀態都可以重新被計算出來（不考慮計算需要的時間）。
真正有意義的數據，是全節點必須的數據的大小，Bitcoin是200G，Ethereum是170G，兩者是基本相同的，而且在平均配置的云主機都能裝下，因此人們觀察到的Ethereum全節點減少并不是由于存儲增加導致的（根本原因是同步時的計算開銷）。
考慮到Ethereum的歷史長度（當前區塊的timestamp減去genesis的timestamp）不到Bitcoin的一半，可以看出Ethereum的歷史和狀態大小增長更快。
05
The Tragedy of (Storage) Commons：區塊鏈版本的公地悲劇
公地悲劇所指指的是這樣一種情況，有限的共享資源在不受任何限制的使用下被人們過度消耗。區塊鏈節點為保存歷史和狀態付出的存儲，正是這樣一種共享資源。
區塊鏈節點為處理交易所花費的資源有三種，CPU，存儲和網絡帶寬。CPU和帶寬都是每個區塊會刷新的資源，我們可以認為每個區塊間隔內都用同樣多的CPU和帶寬可供使用，上個區塊消耗掉的CPU和帶寬不會讓下個區塊可用的CPU和帶寬變少。對于可刷新的資源，我們可以通過一次性支付的交易手續費來補償節點（手續費與計算復雜度和交易大小的相關性可參考RFC0015Appendix）。
與CPU和帶寬不同，存儲是一種占用資源，在一個區塊中被占用了的存儲，除非使用者主動釋放，否則無法在后面的區塊中被其它使用者使用。節點需要為存儲持續的付出成本，而使用者卻不需要為存儲持續的支付手續費（記住交易手續費只需要支付一次）。
使用者只需要在往區塊鏈寫數據的時候支付一點點手續費，就可以永久使用一個可用性超過Amazon S3的存儲，其無限大的永久存儲成本需要區塊鏈網絡中的所有全節點來承擔。
Ethereum上由于各種DApp的存在，The Tragedy of (Storage) Commons相對更加嚴重。例如，在區塊5700001（May 30, 2018）的時候，使用狀態最多的5個合約是：
EtherDelta, 5.09%
IDEX, 4.17%
CryptoKitties, 3.05%
ENS, 1.92%
EOS Sale, 1.73%
比較有趣的是最后一個，EOS Sale。雖然EOS的眾籌已經完成，EOS代幣已經在EOS鏈上流轉，EOS眾籌的記錄卻永遠留在了Ethereum的節點上，消耗Ethereum全節點的存儲資源。
可以看到，在缺乏管理的情況下，區塊鏈的存儲資源會被有意或者無意的濫用。
在一個設計合理的經濟模型中，使用者必須承擔存儲占用的成本，這個成本不僅僅與占用存儲空間的大小成正比，還與占用時間的長度成正比。
06
狀態爆炸
公地悲劇所指的無論是歷史還是狀態數據都會占用存儲資源。通過上面對Bitcoin和Ethereum的分析（其他區塊鏈的狀態模型基本都可以歸納為二者之一）可以看到，雖然它們對歷史和狀態的增長進行了管理，但是對歷史和狀態的總大小卻沒有任何控制，這些數據會持續的無休止的累積下去，使得運行全節點需要的存儲資源越來越大，提高全節點的運行門檻，使網絡的去中心化程度越來越低，這是我們不愿意看到的。
你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：
從這張圖中我們可以看到，隨著Ethereum網絡的發展，狀態數據累積的數量呈指數式的增長。Bitcoin的狀態數據從0積累到3G，用了10年；Ethereum的狀態數據從0積累到10G，用了4年；而這是在我們還沒有解決Scalability問題，區塊鏈仍然是小眾技術的情況下的增長速度。
此文由 中國比特幣官網 編輯，未經允許不得轉載?。?a href="http://www.huohuxiazai.com/">首頁 > 比特幣行情 » 區塊鏈的狀態爆炸困境 |硬核系列