“狀態數據膨脹” 問題的技術路徑：無狀態性_以太坊

原標題：《觀點|狀態膨脹和無狀態性》

一.引言

本文的目的在于向大家介紹一種解決“狀態數據膨脹”問題的技術路徑——“無狀態性”。“狀態數據膨脹”是所有允許用戶自主寫入狀態數據的公鏈都會面臨的問題，指的是因為用戶及合約的不斷增加，在全節點處保存的狀態數據會越來越多。不斷增加的狀態數據會帶來一系列風險，包括：抬高全節點的運行門檻；使鏈上操作的定價失衡。

在本文中我主要拿以太坊區塊鏈來舉例，這是因為我對以太坊最熟悉，但狀態數據膨脹問題是普遍的，不是以太坊獨有的。我同樣也會舉出我所知的其他項目對這個問題的思考。

為使大家充分理解“無狀態性”的意義，我少不了要在開篇交代一下問題的背景。然后我會介紹以太坊社區為此提出的幾個概念，以及相關的開放問題/權衡取舍。最后，我會再回到最初的問題，以期通過對問題的多樣描述，拓寬對該問題的思考。

二.狀態數據膨脹問題

可以把“區塊鏈協議”理解為一種讓不定數量的計算機的行為統一步調成一臺計算機的協議。那么，其運行會在參與相關協議的計算機處產生兩種數據：一種是區塊數據，即我們常說的區塊鏈，這部分數據記錄了這個網絡在過去發生的所有事情；另一種是狀態數據，即代表當前整個網絡的狀態的數據，對以太坊來說，“狀態”的內涵包括：哪個賬戶有多少余額、已經發出過多少筆事務；哪個合約的代碼是什么，其內部的哪個存儲項的值是什么；還有一些與共識機制運行相關的數據。

狀態數據的特殊性在于：一方面，狀態數據是歷史區塊執行之后的結果；另一方面，它又是執行新區塊的前提。因此，在當前的以太坊區塊鏈上，全節點必須保存狀態數據，這樣才能驗證新收到區塊的合法性。

可以想象，因為用戶和合約的數量會不斷增加，如果不施加一些控制，狀態數據的規模是會不斷增大的。這就是狀態數據膨脹問題。

狀態膨脹問題帶來的影響是確定的：它會讓區塊驗證變得越來越困難。因為同樣是讀取和寫入一個狀態對象，在狀態對象有10萬個的時候，比之狀態對象只有1000個的時候，資源開銷是上升的。也正因此，狀態膨脹會使運行全節點的門檻提高，還會使EVM各操作的Gas開銷比例逐漸失衡，產生對節點的DoS攻擊向量。

但狀態膨脹問題的原因為何，則有許多種不同的角度。比如，Vitalik對該問題的歸因??是：

“這些操作只需事務的發送者一次性繳交按gas用量來計量的手續費，但會給整個網絡造成永久的持續性成本”換言之，問題的根源是支付和成本的不匹配——當前的以太坊協議既做不到能夠合理地刪除狀態來給區塊鏈“瘦身”?，又做不到讓用戶持續為保存自己的狀態付費。假設能做到，這個問題就能得到控制，不會這么嚴重了。因此，他傾向于“狀態保質期”方向的改進：用戶創建或更新某個狀態對象之后，只能保證全節點會在一段時間內存儲這個對象；逾期則必須采用額外的手段來“復活”這個對象。

Polkadot為其基于區塊鏈的消息傳遞應用程序申請商標注冊:金色財經報道，根據最近的一份文件，將自己定位為第 0 層區塊鏈的 Polkadot 已經為其基于區塊鏈的消息傳遞應用程序申請了商標注冊，Polkadot Converse一詞已注冊商標，在申請的商品和服務部分添加了有關該應用程序的其他信息。該商標涵蓋：用于社交網絡的軟件，用于創建、管理和與在線社區交互的軟件；用于創建、發送和接收電子消息、圖形、圖像、音頻內容的軟件。[2023/4/5 13:45:07]

對問題的其他歸因和“狀態保質期”概念，我們后文還會講到。現在我們先轉向“無狀態性”。

注1：VitalikButerin

https://ethfans.org/posts/a-theory-of-ethereum-state-size-management

注2：在當前的以太坊協議中，的確有操作可以做到刪除合約的存儲項，也為該操作碼的使用提供了一種粗糙的激勵機制。但事實證明，返還Gas機制不僅沒有改善狀態膨脹問題，還促成了GasToken的出現，加劇了狀態膨脹問題；而SELFDESTRUCT則導致了別的一些問題。?

三.“無狀態性”諸概念

無狀態性

“無狀態性”背后的觀念是：狀態膨脹問題之所以是一個問題，是因為驗證區塊的節點必須先有狀態數據，然后才能驗證區塊；但如果我們能做到無需在本地存儲狀態數據就能驗證區塊，那就無需擔心這個問題了。

具體做法是，在廣播區塊時，附帶傳播一份對該區塊內所有事務所訪問狀態的證據，一個完全不保存任何狀態的節點，也可以憑借這些證據恢復出恰好足以驗證該區塊內所有事務的狀態樹，并且驗證之后可以把這些狀態數據都丟棄。這里的“所訪問狀態的證據”，通常稱為“見證數據”。

無狀態性代表著對狀態膨脹問題的釜底抽薪式解決方案，徹底免去區塊驗證對狀態數據的需要，自然就不需要擔心狀態膨脹的問題了。另一方面，各節點還可以自行選擇存儲哪些狀態，允許開發者為自己的使用場景定制所需的客戶端。

但是，從節點的角度看，這意味著一種交換：以增大帶寬開銷為代價，來節約硬盤的讀寫和存儲開銷。那么見證數據到底有多大？

如果不對以太坊協議作任何改變，見證數據的大小會在MB級別?）。相比之下，當前的以太坊區塊數據量約為45KB?。由此看來，見證數據的帶寬開銷是非常大的。過去兩年中，無狀態以太坊研究的主要方向，就是思考如何才能降低見證數據的大小，方向有：代碼默克爾化，減少需要包含在見證數據中的合約代碼數據?；改變以太坊狀態樹的格式，比如將十六進制樹改為二進制樹?，或者將默克爾樹改為KZG承諾樹；以區塊為單位提供見證數據，而非以事務為單位，這樣可以免去一些重復的證據。改為二進制樹可以節約一半的帶寬開銷甚至更多；而VerkleTree可以產生固定大小的見證數據。

Snapchat將推出基于ChatGPT的自有聊天機器人:2月28日消息，Snapchat將推出一款由OpenAI最新版ChatGPT提供支持的聊天機器人，這款名為“My AI”的機器人將被固定在應用界面的聊天選項卡上。（TheVerge）[2023/2/28 12:33:47]

除了帶寬開銷增大以外，無狀態性還帶來了一種革命性的變化：網絡中可能大部分節點都不會保存狀態數據，至少不會保存全量的狀態數據。那么以往我們習以為常的屬性，在無狀態客戶端為主的網路中就不一定能實現了。這些問題都要重新思考：

當前條件下，用戶無需擔心誰能為自己提供錢包服務；因為自己賬戶的狀態在全網所有全節點處都有備份；但是“無狀態性”實現后，誰來為用戶提供見證數據呢？用戶如何知道哪里的節點存儲了自己的狀態？一種樂觀的假設是：出塊者處一定存儲了全部的狀態，否則就會影響其出塊；因此至少出塊者一定能提供這樣的服務。但這會影響錢包服務的可得性嗎？如果一個節點是無狀態的，僅保存了區塊數據，雖然它能參與歷史區塊廣播和歷史事務廣播，但它沒辦法參與新事務的廣播。準確點來說，TA是沒法驗證新收到的事務的有效性的。那么這樣的節點要如何在P2P網絡中存在？事務要如何在網絡中傳播？這是否意味著我們不論如何都需要某種以事務為單位提供見證數據的機制？還是說無狀態節點只能在一個專門的次級網絡中生存？如何為見證數據指定Gas開銷？又或者說，如何限制見證數據的大小？上面這個清單僅僅是當前的研究成果，它仍有可能變得更長。這些運行假設的變化，極有可能比它的帶寬開銷上的影響更為重要；如果不分析清楚這些假設，就沒有辦法判斷無狀態性是否真的值得實現，或者何種實現方式更好。

當前，有一種對無狀態性的分類是：

弱無狀態性：以區塊為單位提供見證數據；出塊者仍需保存全部狀態數據強無狀態性：以事務為單位提供見證數據，理論上不需要保持全部狀態數據也可以出塊在我看來，兩種方向存在短長，但不應認為網絡的最終形態可以被規劃出來。從節約帶寬的角度，弱無狀態性是更優選擇；但相應地也要面對上文所述新事務傳播問題。后文我們還會回到這個分類。

下面我們進入第二個概念：“準-無狀態性”。

注3：AlexeyAkhunov

https://ethfans.org/posts/state-availability-getnodedata-dht-approach-dev-update

準-無狀態性

準-無狀態性的概念來自這篇文章?。其背后的直覺是：無狀態性對見證數據的要求是能幫助完全無狀態的節點從0開始建構出能驗證相應區塊的狀態樹，但這很有可能浪費了帶寬資源；因為一旦收到了見證數據之后，節點就已經有一棵稀疏的狀態樹了，這棵樹是可以重用的，犯不著把它全刪了，收到一個新區塊又從0開始建構。

幣安將調查由Ankr開發者私鑰被竊引發的數個加密貨幣黑客攻擊事件:12月2日消息，據CNN披露，由于Ankr開發者私鑰被竊引發了數個加密代幣黑客事件，目前受影響的包括Ankr忠誠度代幣aBNBc、穩定幣HAY等。目前幣安表示其團隊正在調查本次事件，同時向用戶保證本次“不是針對幣安公司的攻擊”，但截至目前幣安公司尚未回應提供更多信息的請求。[2022/12/2 21:18:28]

因此，假定節點在收到一個區塊前，其狀態數據的存量情況是可知的，我們就可以借助見證數據為之提供一個狀態增量，這個增量加上其初始存量，恰好足以建構出能驗證新區塊的狀態樹。如此一來，我們就既能獲得無狀態性的大部分好處，又不需要像無狀態性那樣，付出那么高的帶寬開銷。

而且，準-無狀態性還有一個額外的好處：當狀態數據變得越來越多，狀態樹變得越來越深越來越密，無狀態下的見證數據理論上來說也會不斷增大，即帶寬開銷趨于上升；但準-無狀態性的見證數據僅提供增量數據，所以其見證數據也是最小化的。

麻煩在于，這個“節點的狀態數據存量”如何可知？理論上來說，除非我們從某個一致的存量開始實行準-無狀態性，否則是無法對這個存量達成同步的。但只需“一致”，這個數目具體是多少，無關緊要。由此我們發現了準-無狀態性的另一個優點：假使狀態數據已經變得過于龐大，我們可以將它們“清零”，從無狀態重新開始，啟動一次新的、由富狀態節點向驗證節點傳送見證數據的進程。

這就是ReGenesis，定期重啟以太坊這臺計算機。

注9：IgorMandrigin

https://ethfans.org/posts/semi-stateless-initial-sync-experiment

Regenesis

ReGenesis的構想最早由Alexey提出?，更細致的解讀可見此文?。大意是：定期將協議設定為空狀態，開始實施準-無狀態的流程——每一個區塊在傳播時，都必須附帶一些見證數據，使得一個從上一次regenesis事件開始清零了狀態數據、并獲得了自那以來所有區塊附帶見證數據的節點，都能驗證該區塊。

也就是說，每次觸發regenesis事件，一個只求驗證區塊、不求產生區塊的節點就可以把本地的狀態數據清零，憑借新收到的區塊附帶的見證消息，建構起剛好足以驗證該區塊的狀態樹；每個見證數據，都會帶來增量的狀態數據，只要節點緩存了自己的狀態樹，則見證數據都是剛好夠用的。當節點本地的狀態數據足夠多，甚至有可能出現無需附帶見證數據的區塊。但是，又不必擔心狀態數據的膨脹問題，因為節點會定期清零狀態。

ReGenesis是一個特別均衡的方案。而且，因為它追求的是準-無狀態性，雖然ReGenesis要求實現基于事務的見證數據，它繞過了基于事務見證數據的無狀態性的一個缺點：需要頻繁更新一筆事務的見證數據，每一次狀態根更新，都要求更新未打包事務的見證數據；但是，在準-無狀態性中，準-無狀態節點每收到一個區塊，本地的狀態就會多一些，而事務被打包的時間必定晚于其廣播的時間，所以事務在廣播時附帶的見證數據必定足以應付驗證的需要。

AMM協議JediSwap上線StarkNet主網:11月30日，自動做市商協議JediSwap發推表示已上線StarkNet主網，之后將發布細節內容。

今年1月，零知識證明技術開發公司StarkWare曾向JediSwap授予贈款，用于構建和發展新的DeFi應用程序。JediSwap表示，該項目是StarkNet上第一個無需許可的AMM協議。[2022/11/30 21:12:25]

那么它的缺點在哪里呢？

如果一筆事務在事先并不能確定自己會訪問哪些交易，則有可能并不能提供足夠的見證數據并因此失敗。這并不是一個不可解決的問題，因為根據準-無狀態性，只需多次發起并補充見證數據，總能成功。但這總歸意味著用戶可能要多次發送同一筆事務。

不確定ReGenesis下節點會不會也拋棄區塊數據，所以rollup這樣layer-2方案可能會受到影響。

從我們上面推論下來，ReGenesis很像一種無狀態或者準-無狀態方案。但是，從另一個角度看，ReGenesis也很像一種“狀態保質期”方案或者“狀態租金”方案：每過一段時間，所有的狀態對象都會過期、失活，而你為了讓自己的狀態復活，必須支付額外一筆代價；而用戶的一次付費，也只能保證相關狀態在節點處能存儲一段時間，而無法保證能永久存儲。

從這個角度看，ReGenesis會面臨另一個所有狀態保質期方案都會面對的問題：“復活沖突”。如果有人在已經失活的狀態存儲位置直接創建了一個新狀態，那就會產生沖突——從前的富狀態節點無法與無狀態節點達成共識。對應的ReGenesis上，就是regenesis事件觸發后，有人嘗試在原本已經有狀態的存儲位置上新建一個狀態，一直存儲著狀態數據的富狀態節點，就將無法與剛清零了狀態的無狀態節點，對狀態根達成共識。

Vitalik為此提出的解決方案??是：給賬戶安排一個與其創建時期相對應的標識符，從而明確用戶到底是想復活自己在從前時段創建的狀態，還是想新建一個狀態，從而解決復活沖突問題。

當前，ReGenesis已經完全被當成一個狀態保質期方案，與弱無狀態性所代表的無狀態性方案相競爭?。但在我看來，由于其運行需要使用見證數據，而圍繞見證數據使用的研究是從無狀態性的研究中生發出來的，所以無狀態性是一個不應被放棄的視角，尤其是準-無狀態性的概念，非常富有啟發性。

注10：AlexeyAkhunov

https://ethfans.org/posts/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state

注11：IgorMandrigin

加密指數基金管理公司Bitwise將引入主動管理加密策略:11月2日消息，加密指數基金管理公司Bitwise Asset Management宣布將引入主動管理加密策略，以滿足機構對流動性加密策略快速增長的需求。Bitwise的主動管理加密策略團隊由Jeffrey Park領投，Jeffrey Park此前是Corbin Capital的合伙人，在此之前，曾在哈佛管理公司和摩根士丹利任職。[2022/11/2 12:07:03]

https://ethfans.org/posts/37566

注12：VitalikButerin

https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739

總結

從無狀態性和準-無狀態性的概念出發，我們最終走向了ReGenesis這種較為均衡的方案。從狀態保質期的角度出發，也可以得出ReGenesis相當有競爭力的結論。但是，這絕不意味著無狀態性的研究已經完成或者已被淘汰。事實上，我們還未能確定無狀態性帶來的所有影響是否都已被分析清楚了，因此，也無法斷言已經出現了絕對值得實現的方案。而且，就算方案確定了，工程上獲得安全高效的成果，仍有待時日。因此，對無狀態性的實現，我并不那么樂觀。

接下來，我們重新回到狀態膨脹問題，看看對這個問題的不同表述，會不會給我們帶來一些啟發。

四.問題到底出在哪兒？

狀態膨脹問題到底意味著什么？它在何種意義上是一個問題？如何為之歸因并提出可行的解決方案？如何衡量一種解決方案是否有價值？

你至少可以從以下幾個方面，來思考狀態膨脹給我們帶來的影響：

它會使區塊驗證的成本不斷升高，因此抬高全節點運行的門檻；

它意味著一種只增不減的永久性負擔，對網絡的長期存續和去中心化是一種威脅；

它意味著鏈上操作的Gas定價有持續存在的失衡風險；

我們一個一個來。

驗證成本

為什么狀態數據的增加會提高區塊驗證的成本？因為對以太坊來說，區塊的執行和區塊的驗證是一回事，都是完全執行所有的計算過程；區塊驗證要求本地具備最新的狀態數據；狀態數據的增加意味著對單個狀態對象的讀取和寫入變得更困難。這三個條件中，任一因果關系被打破或被削弱，狀態膨脹給區塊驗證帶來的影響都會被削弱甚至消除。

假如區塊的驗證與執行不是一回事、區塊驗證的開銷是個常量，則狀態膨脹問題不會影響區塊驗證的成本；這就是Mina等新興區塊鏈采取的思路：每次出塊，出塊者都會為區塊的執行過程生成一個計算完整性的證明，驗證方只需驗證這個證明就可以驗證相關區塊的合法性，而驗證的開銷是個常量，這就打破了狀態膨脹對區塊驗證成本的影響。理論上來說，以太坊也可以引入類似的技術；而我們要付出的代價是：找出一種安全可靠的、能夠為通用計算實現計算完整性證明的工程實現、可能完全改變應用開發者的體驗、需要重新設計鏈上操作的Gas消耗量比例。

同理，無狀態性就是在打破或說影響第條因果關系。實現無狀態性之后，區塊驗證就不再要求本地存儲最新的狀態數據了，但它還留下了一種風險：隨著狀態數據的增加，見證數據增大的風險。

而則向我們指出，優化客戶端同樣有助于減少這個問題對我們的影響。舉例而言：Geth客戶端1.10版??實現了狀態快照，該功能可以保證狀態讀取的開銷是一個常量，也即消除了狀態膨脹對狀態讀取的開銷的影響；但是，即使優化到極致，狀態寫入的開銷仍然會隨著狀態數量的增加而增加。

注13：PéterSzilágyi

https://ethfans.org/posts/geth-v1-10-0-introduction

永久性負擔

從這個角度看，問題出在：用戶可強制要求節點存儲自己的狀態；支付與成本在時段上的不匹配，一次付費永久存儲。

無狀態性的激進和革命之處就在于，它針對的是，而不是，也即它不把這個問題解釋為一個經濟機制問題，也不考慮改變經濟模型來解決這個問題。無狀態性完全消除了節點與本地的一部分特殊數據交互以驗證區塊的需要，從而完全免去了存儲狀態數據需要。實現了無狀態性之后，存儲部分還是全部狀態完全由節點運營者自己決定，用戶實際上無法強制所有節點來存儲自己的狀態，只能預期礦池或者錢包服務提供商這樣的專業運營商會存儲自己的狀態，而這是完全公平的。

而針對的解決方案可分為兩類：一類的傾向是：一次付費、有限時段存儲；無限時段存儲、持續付費。前者的代表是各種狀態保質期方案；后者的代表是Nervos區塊鏈。

在Nervos區塊鏈上，用戶要存儲狀態時就必須綁定一定數量的區塊鏈原生資產CKB，綁定的代幣數量與可寫入的狀態數據大小是成恒定比例的；由此，用戶在存儲狀態時，雖然沒有貨幣支出，但因資產綁定而承受的不便利，就是一種持續的、與存儲狀態的時長一一對應的成本。因此，這一模式約束了用戶存儲狀態的行為；而且CKB的數量就構成了狀態數據的上限，控制了狀態膨脹。

而狀態保質期方案，相比無狀態性就顯得有點半心半意——在許多狀態保質期方案中，它雖然能約束狀態數據的大小，但不一定能降低與特殊數據交互的需要，它需要額外的數據結構來記錄失活狀態的信息，也需要與這一數據交互。解決復活沖突實際上也就是在解決這個問題。

另外，包括ReGenesis在內的狀態保質期方案也意味著，整個網絡的事務處理容量，會被一類并不創造經濟價值、僅僅是為了繳納租金的狀態復活事務給占去一塊。這使人疑心狀態保質期到底是不是一個長期可持續的、能獲得民意支持的方向，畢竟，用戶是會越來越多的。

操作碼Gas定價失衡

鏈上操作的Gas消耗量的絕對值是沒有意義的，一個操作消耗100Gas并不意味著什么；有意義的是不同操作的Gas消耗量比例：一個消耗100Gas的操作的計算開銷被認為是一個消耗1Gas的操作的100倍。它的意義有兩重：它引導應用開發者優化代碼的方向，假設兩個操作路徑都可以達到同樣的效果，而一條路徑的Gas開銷更低，開發者就會實現這個路徑；如果這個比例失衡了，那就意味著某種操作的名義開銷偏離了其實際開銷，而這樣的操作碼就更有可能被利用來發起對節點的DoS攻擊。著名的“上海攻擊”就是這樣：攻擊者在事務中包含了大量Gas消耗量很低、但節點實際計算開銷很大的操作碼，而處理這些事務會使節點負載過大而掉線。

狀態膨脹就會引發這樣的失衡問題：狀態操作的Gas開銷是一個常量，但狀態讀寫的開銷實際上并不是一個常量，它會隨著狀態數量的增加而增加。那為什么狀態操作的Gas開銷不能實時、動態變化呢？因為狀態讀寫邏輯上是由EVM來實現的，但實際上并不是，它是由客戶端軟件的數據庫來實現的，不同客戶端的實際開銷既不統一，也無法被EVM感知。

值得提醒的是：上述兩種效果是會相互疊加的。如果相關操作的名義開銷比例，恰好引導著應用開發者使用這種實際開銷被低估的資源，則問題就會變得更嚴重——其實狀態膨脹問題本身就是這樣的一個例子，狀態讀寫的名義開銷定得太低了。

當前以太坊社區的做法是，通過硬分叉來調整不同操作的Gas消耗量。這就等于是說，以太坊當前的治理程序，充當了EVM感知狀態操作開銷的信息輸入機制。這樣做當然不能完美地解決這個問題，它同時也提醒了我們，以太坊這臺電腦有多么依賴人類工程師的定期修理。

此外，合理的Gas定價還要面臨的另一個挑戰是：它要用同一個度量單位，來度量本質上需要不同資源的操作的開銷比例。

談到這一點，是因為無狀態性也受該問題的影響。在當前，節點執行區塊的主要開銷并不是計算，而是狀態的讀寫；而使用見證數據取代了狀態數據之后，主要的開銷就變成了帶寬。當然，出塊者生成見證數據需要計算，但即使我們不考慮這一點，或認定當前的狀態操作名義消耗量已足夠準確，我們仍必須考慮怎么約束見證數據大小的問題。好的辦法無疑仍是價格，但其Gas消耗量應如何確定呢？

回到無狀態性

了解了這些問題，我們也許更能明白無狀態性究竟解決了什么問題，又留下了哪些問題等待解決。實際上，我們再回過頭來看無狀態性，其原理是很單純的：以帶寬開銷換取硬盤讀寫的節約。但是，能截然認為這一定是值當的嗎？假設我們生活在一個硬盤讀寫就是很便宜，而帶寬就是非常稀缺的世界里呢？或者說，假設日后兩種資源的價格會倒轉過來呢？

換言之，無論選擇無狀態性還是保持原狀，從事后來看可能都是不夠靈活的選擇——最理想的情況，應該是節點能自己選擇犧牲哪個換取哪個，并隨時切換，而不是由一個治理程序強制大家選擇某一種，這種選擇再好，終究只是有限頭腦的智慧的產物，而且都不能排除要依賴治理程序的風險。

這是否意味著，最優的方案應該是一個跟當前的以太坊網絡部分重疊、平行運行的無狀態客戶端網絡？用戶能自由加入，自由切換？我們能擁有這樣的方案嗎？

五.結語

自19年3月了解了“無狀態性”概念以來，我便認定，無狀態性是以太坊最值得研究的底層協議演化方向，唯有它能既解決狀態膨脹問題，又維持以太坊的經濟屬性。今天我仍這么相信。只是，對狀態膨脹問題的思考，會不斷牽涉到以太坊的底層范式——全局狀態和鏈上計算——最終具象化為一個問題：如何為鏈上操作制定名義開銷比例？無論要對以太坊作什么改進，都繞不開這個問題。最終你也會得到跟我一樣的結論：以太坊的設計失衡之處不是一處，而是兩處。無狀態性之后，我們仍有迢迢長路。

的確，本來，對任何彌賽亞的期待，都是一種幻想。此際，讓我們先解決以太坊長期生存道路上最大的障礙：狀態膨脹。

Tags：以太坊GASGENEREGEN幸運以太坊幣值多少錢UGAS-JUN21價格gene幣價格Regent Coin

BNB