區塊鏈與狀態爆炸

如果二級標題二級標題

狀態

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

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

• 狀態（即現在）——節點在處理完從Genesis
  

到當前高度的所有區塊和交易後形成的最終結果。狀態隨著區塊的增加一直處於變化之中，交易是造成變化的原因。

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

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

舉個例子：Bitcoin 的歷史和狀態

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 都要持續佔用節點的存儲空間。目前，而，而二級標題二級標題

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

Ethereum 中每一個區塊，每一個賬戶都會持續佔用節點的存儲空間。 Ethereum 節點在同步的時候有多種模式，在Archive 模式下所有的歷史和狀態都會保存下來，其中歷史包括歷史交易和歷史狀態，所有數據加起來的大小超過了2TB；在Default 模式下，歷史狀態會被裁剪掉，本地只保留歷史交易和當前狀態，，其中，其中交易歷史大小是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 相對更加嚴重。例如，在是：是：

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 的總量設定沒有確定的規則，更多取決於超級節點可以承受的硬件配置，而非共識空間的成本。

Storage Rent 的方案Storage Rent 的方案：要求使用者為存儲資源的使用預支付一筆租金，佔用存儲資源會持續消耗這筆租金，佔用時間越長，使用者需要支付的租金越多。 Storage Rent 方案存在兩個問題：

1.預支付的租金終有一天會用完，這時候如何處理佔用的狀態？正是為解決這個問題，Storage Rent 需要諸如resurrection 的機制來補充，增加了設計的複雜度，使智能合約的immutability 大打折扣，也為使用體驗帶來了麻煩；

2.Ethereum 的狀態模型是一種共享狀態的模型，而不是First-class State原文鏈接：

原文鏈接：

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