摘要：目前整個歷史的大小所有區塊加起來的大小大約是，而狀態的大小只有大約由約萬個組成。通過每個區塊的，間接限制了歷史和狀態的增長速度。常見的一個誤解是的區塊鏈大小已經超過了。區塊鏈節點為保存歷史和狀態付出的存儲，正是這樣一種共享資源。

如果 Layer 1 的關注點應該是狀態而不是計算，在設計 Layer 1 區塊鏈時，我們就需要先理解什么是區塊鏈的狀態。理解了狀態是什么，我們才能理解狀態爆炸是什么。

區塊鏈網絡中的每一個全節點，在網絡中運行一段時間之后都會在本地存儲上留下一些數據，我們可以按照歷史和現在把它們分為兩類：

歷史——區塊數據和交易數據都是歷史，歷史是從 Genesis 到達當前狀態的路徑。

狀態（即現在）——節點在處理完從 Genesis
到當前高度的所有區塊和交易后形成的最終結果。狀態隨著區塊的增加一直處于變化之中，交易是造成變化的原因。

共識協議的作用是通過一系列的消息交換，保證每一個節點看到的當前狀態是相同的，而實現這個目標的方式是保證每一個節點看到的歷史是相同的。只要歷史相同（即所有交易的排序相同），處理交易的方式相同（把交易放在相同的確定性虛擬機里面執行），最后看到的當前狀態就是相同的。當我們說「區塊鏈具有不可篡改性」時，是指區塊鏈歷史不可篡改，相反，狀態是一直在變化的。

有趣的是，不同的區塊鏈保存歷史和狀態的方式不同，其中的差異使得不同的區塊鏈形成了各自的特點。由于這篇文章討論的話題是狀態，而影響狀態的歷史數據主要是交易（而不是區塊頭），接下來的討論歷史的時候會側重交易，忽略區塊頭。

Bitcoin 的狀態，指的是 Bitcoin 賬本當前的樣子。Bitcoin 的狀態是由一個個 UTXO（尚未花費的交易輸出）構成的，每個 UTXO 代表了一定數量的 Bitcoin，每個 UTXO 上面寫了一個名字（scriptPubkey），記錄這個 UTXO 的所有者是誰。如果要做一個比喻的話，Bitcoin 的當前狀態是一個裝滿了金幣的袋子，每個金幣上刻著所有者的名字。

Bitcoin 的歷史由一連串的交易構成，交易內部的主要結構是輸入和輸出。交易更改狀態的方法是，把當前狀態中包含的一些UTXO（交易輸入引用的那些）標記為已花費，從 UTXO 集合中移出，然后把一些新的 UTXO（這個交易的輸出）添加到 UTXO 集合里面去。

可以看出，Bitcoin 交易的輸出（TXO，Transaction Output）正是上面說的 UTXO，UTXO 只不過是一種處于特殊階段（尚未花費）的 TXO。因為構成 Bitcoin 狀態的組件（UTXO），同時也是構成交易的組件（TXO）。由此 Bitcoin 有一個奇妙的性質：任意時刻的狀態都是歷史的一個子集，歷史和狀態包含的數據類型是同一維度的。交易的歷史（所有被打包的交易的集合，即所有產生過的 TXO 的集合）即狀態的歷史（每個區塊對應的 UTXO 集合的集合，也是所有產生過的 TXO 的集合），Bitcoin 的歷史只包含交易。

在 Bitcoin 網絡中，每一個區塊，每一個 UTXO 都要持續占用節點的存儲空間。目前 Bitcoin 整個歷史的大小（所有區塊加起來的大小）大約是200G，而狀態的大小只有大約 3G（由約 5000萬個UTXO組成）。Bitcoin 通過對區塊大小的限制很好的管理了歷史的增長速度，由于其歷史和狀態之間的子集關系，狀態數據大小必然遠小于歷史數據大小，因此狀態增長也間接的受到區塊大小的管理。

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。（思考題：EOS 使用了類似 Ethereum 的賬戶模型，卻沒有在區塊頭中包含狀態的 Merkle Tree Root，這是好還是不好？）

Ethereum 中每一個區塊，每一個賬戶都會持續占用節點的存儲空間。Ethereum 節點在同步的時候有多種模式，在 Archive 模式下所有的歷史和狀態都會保存下來，其中歷史包括歷史交易和歷史狀態，所有數據加起來的大小超過了 2TB；在 Default 模式下，歷史狀態會被裁剪掉，本地只保留歷史交易和當前狀態，所有數據加起來大約是 170G，其中交易歷史大小是 150G，當前狀態大小是 10G。Ethereum 中所有的開銷管理都被統一到 gas 計費模型之下，交易的大小需要消耗對應的 gas，而每一條 EVM 指令消耗的 gas，不僅考慮了計算開銷，也將存儲開銷考慮在內。通過每個區塊的 gaslimit，間接限制了歷史和狀態的增長速度。

ps. 常見的一個誤解是：Ethereum 的「區塊鏈大小」已經超過 1T 了。從上面的分析我們可以看到，「區塊鏈大小」是一個非常模糊的定義，如果把歷史狀態算進去，它確實超過了，但是對于全節點來說，把歷史狀態刪掉沒有任何問題，因為只要有 Genesis 和交易歷史，任意時刻的歷史狀態都可以重新被計算出來（不考慮計算需要的時間）。真正有意義的數據，是全節點必須的數據的大小，Bitcoin 是 200G，Ethereum 是 170G，兩者是基本相同的，而且在平均配置的云主機上都能裝下，因此人們觀察到的 Ethereum 全節點減少 并不是由于存儲增加導致的（根本原因是同步時的計算開銷，這里不展開了）。考慮到 Ethereum 的歷史長度（當前區塊的 timestamp 減去 genesis 的 timestamp）不到 Bitcoin 的一半，可以看出 Ethereum 的歷史和狀態大小增長更快。

The Tragedy of (Storage) Commons：區塊鏈版本的公地悲劇
公地悲劇所指的是這樣一種情況，有限的共享資源在不受任何使用限制的情況下會被人們過度消耗。區塊鏈節點為保存歷史和狀態付出的存儲，正是這樣一種共享資源。

區塊鏈節點為處理交易所花費的資源有三種，CPU、存儲和網絡帶寬。CPU 和帶寬都是每個區塊會刷新的資源，我們可以認為每個區塊間隔內都有同樣多的 CPU 和帶寬可供使用，上個區塊消耗掉的 CPU 和帶寬不會讓下個區塊可用的 CPU 和帶寬變少。對于可刷新的資源，我們可以通過一次性支付的交易手續費來補償節點。

與 CPU 和帶寬不同，存儲是一種占用資源，在一個區塊中被占用了的存儲，除非使用者主動釋放，否則無法在后面的區塊中被其它使用者使用。節點需要為存儲持續的付出成本，而使用者卻不需要為存儲持續的支付手續費（記住交易手續費只需要支付一次）。使用者只需要在往區塊鏈寫數據的時候支付一點點手續費，就可以永久使用一個可用性超過 Amazon S3 的存儲，其無限大的永久存儲成本需要區塊鏈網絡中的所有全節點來承擔。

Ethereum 上由于各種 DApp 的存在，The Tragedy of (Storage) Commons 相對更加嚴重。例如，在區塊 5700001（May 30, 2018）的時候，使用狀態最多的 5 個合約是：

1.EtherDelta, 5.09%
2.IDEX, 4.17%
3.CryptoKitties, 3.05%
4.ENS, 1.92%
5.EOS Sale, 1.73%

比較有趣的是最后一個，EOS Sale。雖然 EOS 的眾籌已經完成，EOS 代幣已經在 EOS 鏈上流轉，EOS 眾籌的記錄卻永遠留在了Ethereum 的節點上，消耗 Ethereum 全節點的存儲資源。

可以看到，在缺乏管理的情況下，區塊鏈的存儲資源會被有意或者無意的濫用。在一個設計合理的經濟模型中，使用者必須承擔存儲占用的成本，這個成本不僅僅與占用存儲空間的大小成正比，還與占用時間的長度成正比。

無論是歷史還是狀態數據都會占用存儲資源。通過上面對 Bitcoin 和 Ethereum 的分析（其他區塊鏈的狀態模型基本都可以歸納為二者之一）可以看到，雖然它們對歷史和狀態的增長進行了管理，但是對歷史和狀態的總大小卻沒有任何控制，這些數據會持續無休止的累積下去，使得運行全節點需要的存儲資源越來越大。提高全節點的運行門檻，使網絡的去中心化程度越來越低，這是我們不愿意看到的。

你也許會說，有沒有可能硬件平均水平的提高會超過歷史和狀態的積累速度？我的回答是可能性很低：

從這張圖中我們可以看到，隨著 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 大打折扣，也為使用體驗帶來了麻煩；

2.Ethereum 的狀態模型是一種共享狀態的模型，而不是 First-class State。以 ERC20 Token 為例，所有用戶的資產記錄都存放在單個 ERC20 合約的存儲里面，在這種情況下，應該由誰來支付租金？

解決狀態爆炸問題也是 Nervos CKB 的設計目標之一，為此 CKB 走了一條完全不同的、更為徹底的變革之路。

原文鏈接：https://talk.nervos.org/t/top...