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

狀態(tài)

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

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

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

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

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

舉個例子：Bitcoin的歷史和狀態(tài)

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

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

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

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

再舉個例子：Ethereum的歷史和狀態(tài)

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

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

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

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

· data - 交易攜帶的任意信息

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

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

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

3. 構(gòu)造新的葉子存放新的狀態(tài)，更新狀態(tài)Merkle樹

可以看出，Ethereum的歷史和交易結(jié)構(gòu)與Bitcoin相比有非常大的不同。Ethereum的狀態(tài)是由賬戶構(gòu)成的，而交易是由觸發(fā)賬戶變動的信息構(gòu)成，狀態(tài)和交易中記錄的是完全不同類型的數(shù)據(jù)，二者之間沒有超集和子集的關(guān)系，歷史和狀態(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)會被裁剪掉，本地只保留歷史交易和當(dāng)前狀態(tài)，所有數(shù)據(jù)加起來大約是170G ，其中交易歷史大小是150G，當(dāng)前狀態(tài)大小是10G 。Ethereum中所有的開銷管理都被統(tǒng)一到gas計費模型之下，交易的大小需要消耗對應(yīng)的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é)點減少 并不是由于存儲增加導(dǎo)致的（根本原因是同步時的計算開銷，這里不展開了）?？紤]到Ethereum的歷史長度（當(dāng)前區(qū)塊的TImestamp減去genesis的TImestamp）不到Bitcoin的一半，可以看出Ethereum的歷史和狀態(tài)大小增長更快。

The Tragedy of （Storage） Commons：區(qū)塊鏈版本的公地悲劇

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

區(qū)塊鏈節(jié)點為處理交易所花費的資源有三種，CPU，存儲和網(wǎng)絡(luò)帶寬。CPU和帶寬都是每個區(qū)塊會刷新的資源，我們可以認為每個區(qū)塊間隔內(nèi)都用同樣多的CPU和帶寬可供使用，上個區(qū)塊消耗掉的CPU和帶寬不會讓下個區(qū)塊可用的CPU和帶寬變少。對于可刷新的資源，我們可以通過一次性支付的交易手續(xù)費來補償節(jié)點（手續(xù)費與計算復(fù)雜度和交易大小的相關(guān)性可參考RFC0015 Appendix ）。

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

Ethereum上由于各種DApp的存在，The Tragedy of （Storage） Commons相對更加嚴重。例如，在區(qū)塊5700001（May 30， 2018）的時候，使用狀態(tài)最多的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的眾籌已經(jīng)完成，EOS代幣已經(jīng)在EOS鏈上流轉(zhuǎn)，EOS眾籌的記錄卻永遠留在了Ethereum的節(jié)點上，消耗Ethereum全節(jié)點的存儲資源。

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

狀態(tài)爆炸

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

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

從這張圖中我們可以看到，隨著Ethereum網(wǎng)絡(luò)的發(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ū)塊鏈仍然是小眾技術(shù)的情況下的增長速度。當(dāng)我們解決了scalability問題，區(qū)塊鏈真正獲得mass adopTIon，DApp和用戶數(shù)量都爆炸式增長的時候，區(qū)塊鏈歷史和狀態(tài)數(shù)據(jù)會以什么速度累積呢？

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

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

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

Ethereum社區(qū)也看到了這個問題并提出了Storage Rent的方案：要求使用者為存儲資源的使用預(yù)支付一筆租金，占用存儲資源會持續(xù)消耗這筆租金，占用時間越長，使用者需要支付的租金越多。Storage Rent方案存在兩個問題：1. 預(yù)支付的租金終有一天會用完，這時候如何處理占用的狀態(tài)？正是為解決這個問題，Storage Rent需要諸如resurrection的機制來補充，增加了設(shè)計的復(fù)雜度，使智能合約的immutability大打折扣，也為使用體驗帶來了麻煩 ；2. Ethereum的狀態(tài)模型是一種共享狀態(tài)的模型，而不是First-class State 。以ERC20 Token為例，所有用戶的資產(chǎn)記錄都存放在單個ERC20合約的存儲里面，在這種情況下，應(yīng)該由誰來支付租金？

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