區塊鏈的狀態爆炸困境
二級標題
二級標題
二級標題
Layer 1應該關注狀態
如果我們認為區塊鏈分層是未來的發展方向，我們應該從一開始就考慮到上層協議和分層網絡的需求，在分層的大框架下去設計區塊鏈協議。
換句話說，從分層的角度來看，現有的區塊鏈設計方式都是過時的。現有的區塊鏈在設計時考慮的是特定的功能（例如支付，或者是運行DApp），並希望在運行一段時間後讓上層協議來適應自己。然而如果我們閱讀互聯網的歷史就知道，今天互聯網的協議分層不是這樣打補丁打出來的，相反是在吸收過去經驗之後。這是為什麼區塊鏈並不天然是Layer 1，Layer 1是需要設計的。
解決這個問題的最好方式是將大部分交易轉移到共識範圍更小但是性能更好的上層協議中，並且保證上層協議的參與者總是可以在不滿意的時候退回到區塊鏈上來解決問題，代價僅僅是一些時間成本。
二級標題
狀態是什麼
區塊鍊網絡中的每一個全節點，在網絡中運行一段時間之後都會在本地存儲上留下一些數據，我們可以按照歷史和現在把它們分為兩類：
區塊鍊網絡中的每一個全節點，在網絡中運行一段時間之後都會在本地存儲上留下一些數據，我們可以按照歷史和現在把它們分為兩類：
區塊鍊網絡中的每一個全節點，在網絡中運行一段時間之後都會在本地存儲上留下一些數據，我們可以按照歷史和現在把它們分為兩類：
區塊鍊網絡中的每一個全節點，在網絡中運行一段時間之後都會在本地存儲上留下一些數據，我們可以按照歷史和現在把它們分為兩類：
共識協議的作用是通過一系列的消息交換，保證每一個節點看到的當前狀態是相同的，而實現這個目標的方式是保證每一個節點看到的歷史是相同的。只要歷史相同（即所有交易的排序相同），處理交易的方式相同（把交易放在相同的確定性虛擬機裡面執行），最後看到的當前狀態就是相同的。當我們說「區塊鏈具有不可篡改性」的時候，指的是區塊鏈歷史不可篡改，相反狀態是一直在變化的。
二級標題
二級標題
二級標題
舉個例子：Bitcoin的歷史和狀態
Bitcoin的狀態，指的是Bitcoin賬本當前的樣子。 Bitcoin的狀態是由一個個UTXO（尚未花費的交易輸出）構成的，每個UTXO代表了一定數量的Bitcoin，每個UTXO上面寫了一個名字（scriptPubkey），記錄這個UTXO的所有者是誰。如果要做一個比喻的話，Bitcoin的當前狀態是一個裝滿了金幣的袋子，每個金幣上刻著所有者的名字。
由此，Bitcoin有一個奇妙的性質：任意時刻的狀態都是歷史的一個子集，歷史和狀態包含的數據類型是同一維度的。交易的歷史（所有被打包的交易的集合，即所有產生過的TXO的集合）即狀態的歷史（每個區塊對應的UTXO集合的集合，也是所有產生過的TXO的集合），Bitcoin的歷史只包含交易。
二級標題
二級標題
二級標題
再舉個例子：Ethereum的歷史和狀態
Ethereum的狀態，也叫做「世界狀態」，指的是Ethereum賬本當前的樣子。 Ethereum的狀態是由賬戶構成的一棵Merkle樹（賬戶是葉子），賬戶裡面不僅記錄了余額（代表一定數量的ether），還有合約的數據（例如每一隻加密貓的數據）。 Ethereum的狀態可以看作一個大賬本，賬本的第一列是名字，第二列是餘額，第三列是合約數據。
Ethereum的歷史同樣由交易構成，交易內部的主要結構是：
to：另一個賬戶，代表交易的發送對象
value：交易攜帶的ether數量
data：交易攜帶的任意信息
交易更改狀態的方法是，EVM找到交易發送的目標賬戶，
1.根據交易的value計算目標賬戶的新余額；
2.將交易攜帶的data作為參數傳遞給目標賬戶的智能合約，運行智能合約的邏輯，在運行中可能會修改任意賬戶的內部狀態生成新的狀態；
3.構造新的葉子存放新的狀態，更新狀態Merkle樹。
可以看出，Ethereum的歷史和交易結構與Bitcoin相比有非常大的不同。 Ethereum的狀態是由賬戶構成的，而交易是由觸發賬戶變動的信息構成，狀態和交易中記錄的是完全不同類型的數據，二者之間沒有超集和子集的關係，歷史和狀態所包含的數據類型是兩個維度的，交易歷史大小與狀態大小之間沒有必然的聯繫。
交易修改狀態後，不僅會產生新的狀態（圖中實線框的葉子），而且會留下舊的狀態（圖中虛線框的葉子）成為歷史狀態，因此Ethereum的歷史不僅僅包含交易，還包含歷史狀態。
因為歷史和狀態屬於不同的維度，Ethereum區塊頭中不僅僅包含交易的merkle root, 也需要顯式包含狀態的merkle root。
Ethereum中每一個區塊，每一個賬戶都會持續佔用節點的存儲空間。 Ethereum節點在同步的時候有多種模式，在Archive模式下所有的歷史和狀態都會保存下來，其中歷史包括歷史交易和歷史狀態，所有數據加起來大小超過了2TB；在Default模式下，歷史狀態會被裁剪掉，本地只保留歷史交易和當前狀態，所有數據加起來大約是170G，其中交易歷史大小是150G，當前狀態大小是10G。
二級標題
二級標題
The Tragedy of (Storage) Commons：區塊鏈版本的公地悲劇
二級標題
The Tragedy of (Storage) Commons：區塊鏈版本的公地悲劇
公地悲劇所指指的是這樣一種情況，有限的共享資源在不受任何限制的使用下被人們過度消耗。區塊鏈節點為保存歷史和狀態付出的存儲，正是這樣一種共享資源。
區塊鏈節點為處理交易所花費的資源有三種，CPU，存儲和網絡帶寬。 CPU和帶寬都是每個區塊會刷新的資源，我們可以認為每個區塊間隔內都用同樣多的CPU和帶寬可供使用，上個區塊消耗掉的CPU和帶寬不會讓下個區塊可用的CPU和帶寬變少。對於可刷新的資源，我們可以通過一次性支付的交易手續費來補償節點（手續費與計算複雜度和交易大小的相關性可參考RFC0015Appendix ）。
與CPU和帶寬不同，存儲是一種佔用資源，在一個區塊中被佔用了的存儲，除非使用者主動釋放，否則無法在後面的區塊中被其它使用者使用。節點需要為存儲持續的付出成本，而使用者卻不需要為存儲持續的支付手續費（記住交易手續費只需要支付一次）。
EtherDelta, 5.09%
IDEX, 4.17%
CryptoKitties, 3.05%
ENS, 1.92%
EOS Sale, 1.73%
狀態爆炸
狀態爆炸
狀態爆炸
你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：
你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：
你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：
你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：
從這張圖中我們可以看到，隨著Ethereum網絡的發展，狀態數據累積的數量呈指數式的增長。 Bitcoin的狀態數據從0積累到3G，用了10年；Ethereum的狀態數據從0積累到10G，用了4年；而這是在我們還沒有解決Scalability問題，區塊鏈仍然是小眾技術的情況下的增長速度。
當我們解決了scalability問題，區塊鏈真正獲得mass adoption，DApp和用戶數量都爆炸式增長的時候，區塊鏈歷史和狀態數據會以什麼速度累積呢？
這就是狀態爆炸問題，我們把它歸類為post-scalability problem，因為它在解決scalability問題之後會非常明顯。我們最早是在做許可鏈場景落地時注意到了這個問題，因為許可鏈的性能遠高於公有鏈，剛好處於post-scalability的階段。
歷史數據的累積相對容易處理，未來可以通過去中心化的Checkpoint或是零知識證明等技術來壓縮，在那之前全節點甚至可以把歷史直接丟掉，依然可以正常運行。狀態數據的累積則麻煩許多，因為它是全節點運行必須的數據。
不少區塊鏈項目已經看到了這個問題，並提出了一些解決方案。 EOS RAM是解決狀態爆炸問題的一個有益嘗試：RAM代表了超級節點服務器可用的內存資源，無論是賬戶、合約狀態還是代碼，都需要佔用一定的RAM才能運行。
RAM的設計也有很多問題，它需要通過內置的交易市場購買，不可轉讓，無法租用，將合約執行過程中的短期內存需求和合約狀態的長期存儲需求混在了一起，而且RAM的總量的設定沒有確定的規則，更多取決於超級節點可以承受的硬件配置，而非共識空間的成本。
Ethereum社區也看到了這個問題並提出了Storage Rent的方案：要求使用者為存儲資源的使用預支付一筆租金，佔用存儲資源會持續消耗這筆租金，佔用時間越長，使用者需要支付的租金越多。 Storage Rent方案存在兩個問題：
1.預支付的租金終有一天會用完，這時候如何處理佔用的狀態？正是為解決這個問題，Storage Rent需要諸如resurrection的機制來補充，增加了設計的複雜度，使智能合約的immutability大打折扣，也為使用體驗帶來了麻煩；
