摘要：在本次秘猿科技區(qū)塊鏈小課堂中，我們帶大家來了解一個全新的狀態(tài)爆炸問題。目前整個歷史的大小所有區(qū)塊加起來的大小大約是，而狀態(tài)的大小只有大約由約萬個組成。通過每個區(qū)塊的，間接限制了歷史和狀態(tài)的增長速度。常見的一個誤解是的區(qū)塊鏈大小已經(jīng)超過了。

在設計全新的區(qū)塊鏈經(jīng)濟模型之前，我們以 SoV（價值存儲） 和 MoE（交易媒介） 兩個框架分析了比特幣和以太坊經(jīng)濟模型，得出了上一篇中的問題。在本次秘猿科技區(qū)塊鏈小課堂中，我們帶大家來了解一個全新的狀態(tài)爆炸問題。這類問題將會在未來解決擴展性問題后，顯著爆發(fā)出來，我們稱之為 post-scalability problem！

秘猿科技區(qū)塊鏈小課堂第 32 期

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

區(qū)塊鏈網(wǎng)絡中的每一個全節(jié)點，在網(wǎng)絡中運行一段時間之后都會在本地存儲上留下一些數(shù)據(jù)，我們可以按照歷史和現(xiàn)在把它們分為兩類：

歷史——區(qū)塊數(shù)據(jù)和交易數(shù)據(jù)都是歷史，歷史是從 Genesis 到達當前狀態(tài)的路徑。

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

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

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

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

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

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

在 Bitcoin 網(wǎng)絡中，每一個區(qū)塊，每一個 UTXO 都要持續(xù)占用節(jié)點的存儲空間。目前 Bitcoin 整個歷史的大?。ㄋ袇^(qū)塊加起來的大小）大約是200G，而狀態(tài)的大小只有大約 3G（由約 5000萬個UTXO組成）。Bitcoin 通過對區(qū)塊大小的限制很好的管理了歷史的增長速度，由于其歷史和狀態(tài)之間的子集關系，狀態(tài)數(shù)據(jù)大小必然遠小于歷史數(shù)據(jù)大小，因此狀態(tài)增長也間接的受到區(qū)塊大小的管理。

Ethereum 的狀態(tài)，也叫做「世界狀態(tài)」，指的是 Ethereum 賬本當前的樣子。Ethereum 的狀態(tài)是由賬戶構成的一棵 Merkle 樹（賬戶是葉子），賬戶里面不僅記錄了余額（代表一定數(shù)量的 ether），還記錄了合約的數(shù)據(jù)（例如每一只加密貓的數(shù)據(jù)）。Ethereum 的狀態(tài)可以看作是一個大賬本，賬本的第一列是名字，第二列是余額，第三列是合約數(shù)據(jù)。

Ethereum 的歷史同樣由交易構成，交易內(nèi)部的主要結(jié)構是：

to - 另一個賬戶，代表交易的發(fā)送對象

value - 交易攜帶的 ether 數(shù)量

data - 交易攜帶的任意信息

交易更改狀態(tài)的方法是，EVM 找到交易發(fā)送的目標賬戶：

根據(jù)交易的 value 計算目標賬戶的新余額；

將交易攜帶的 data 作為參數(shù)傳遞給目標賬戶的智能合約，運行智能合約的邏輯，在運行中可能會修改任意賬戶的內(nèi)部狀態(tài)生成新的狀態(tài)；

構造新的葉子存放新的狀態(tài)，更新狀態(tài) Merkle 樹。

可以看出，Ethereum 的歷史和交易結(jié)構與 Bitcoin 相比有非常大的不同。Ethereum 的狀態(tài)是由賬戶構成的，而交易是由觸發(fā)賬戶變動的信息構成，狀態(tài)和交易中記錄的是完全不同類型的數(shù)據(jù)，二者之間沒有超集和子集的關系，歷史和狀態(tài)所包含的數(shù)據(jù)類型是兩個維度的，交易歷史大小與狀態(tài)大小之間沒有必然的聯(lián)系。交易修改狀態(tài)后，不僅會產(chǎn)生新的狀態(tài)（圖中實線框的葉子），而且會留下舊的狀態(tài)（圖中虛線框的葉子）成為歷史狀態(tài)，因此 Ethereum 的歷史不僅僅包含交易，還包含歷史狀態(tài)。因為歷史和狀態(tài)屬于不同的維度，Ethereum 區(qū)塊頭中不僅僅包含交易的 merkle root，也需要顯式包含狀態(tài)的 merkle root。（思考題：EOS 使用了類似 Ethereum 的賬戶模型，卻沒有在區(qū)塊頭中包含狀態(tài)的 Merkle Tree Root，這是好還是不好？）

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

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

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

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

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

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

EtherDelta, 5.09%

IDEX, 4.17%

CryptoKitties, 3.05%

ENS, 1.92%

EOS Sale, 1.73%

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

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

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

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

從這張圖中我們可以看到，隨著 Ethereum 網(wǎng)絡的發(fā)展，狀態(tài)數(shù)據(jù)累積的數(shù)量呈指數(shù)式的增長。Bitcoin 的狀態(tài)數(shù)據(jù)從 0 積累到 3G，用了 10 年；Ethereum 的狀態(tài)數(shù)據(jù)從 0 積累到 10G，用了 4 年；而這是在我們還沒有解決 Scalability 問題，區(qū)塊鏈仍然是小眾技術的情況下的增長速度。當我們解決了 Scalability 問題，區(qū)塊鏈真正獲得 mass adoption，DApp 和用戶數(shù)量都爆炸式增長的時候，區(qū)塊鏈歷史和狀態(tài)數(shù)據(jù)會以什么速度累積呢？

這就是狀態(tài)爆炸問題，我們把它歸類為 post-scalability problem，因為它在解決 Scalability 問題之后會非常明顯。我們最早是在做許可鏈場景落地時注意到了這個問題，因為許可鏈的性能遠高于公有鏈，剛好處于 post-scalability 的階段。（思考題：許可鏈怎么解決狀態(tài)爆炸問題？）

歷史數(shù)據(jù)的累積相對容易處理，未來可以通過去中心化的 Checkpoint 或是零知識證明等技術來壓縮，在那之前全節(jié)點甚至可以把歷史直接丟掉，依然可以正常運行。狀態(tài)數(shù)據(jù)的累積則麻煩許多，因為它是全節(jié)點運行必須的數(shù)據(jù)。

不少區(qū)塊鏈項目已經(jīng)看到了這個問題，并提出了一些解決方案。EOS RAM 是解決狀態(tài)爆炸問題的一個有益嘗試：RAM 代表了超級節(jié)點服務器可用的內(nèi)存資源，無論是賬戶、合約狀態(tài)還是代碼，都需要占用一定的 RAM 才能運行。RAM 的設計也有很多問題，它需要通過內(nèi)置的交易市場購買，不可轉(zhuǎn)讓，無法租用，將合約執(zhí)行過程中的短期內(nèi)存需求和合約狀態(tài)的長期存儲需求混在了一起，而且 RAM 的總量設定沒有確定的規(guī)則，更多取決于超級節(jié)點可以承受的硬件配置，而非共識空間的成本。

Ethereum 社區(qū)也看到了這個問題并提出了 Storage Rent 的方案：要求使用者為存儲資源的使用預支付一筆租金，占用存儲資源會持續(xù)消耗這筆租金，占用時間越長，使用者需要支付的租金越多。Storage Rent 方案存在兩個問題：

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

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

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