以太坊“狀態”規模快速膨脹，開發人員考慮向用戶收取“狀態租金區塊鏈
以太坊開發者社區正面臨一些決定以太坊網絡可用性的艱難決定。
以太坊開發者社區正面臨一些決定以太坊網絡可用性的艱難決定，一些核心開發人員預測，如果以太坊的狀態大小（state siz）繼續以目前的速度增長，以太坊網絡將在三年內崩潰。
減緩其增長的首要解決方案是征收“狀態租金（state rent）”，即向服戶收取存儲數據的費用。（在有些情況下，這稱為“存儲租金(storage rent)”，但在本文中，我將使用“狀態租金”這個術語）。
但這可能會對用戶的體驗產生不愉快的影響，并且可能對現有應用程序產生負面影響。此外，并非所有人都同意狀態大小問題像有些人認為的那樣緊迫。
雖然最終將由核心開發人員來編寫修復程序，但他們似乎并不急于代表以太坊社區做出決定并選擇適當的解決方案。這是因為盡管這個問題本質上是技術性的，但是解決方案涉及到一些會影響可用性的價值權衡。因此，圍繞該問題進行協調有些困難。本文試圖用相對容易理解的語言來描述這一問題和將收取存儲租金作為解決方案的主張。
龐大而冗余的數據量
存儲數據需要磁盤空間，同時對數據進行同步需要時間，這兩者都是塊鏈網絡中的關鍵考慮因素，其中至少有一些節點必須同步并存儲整條鏈的數據（或其中重要的數據塊)。
這不僅僅是一個效率的問題，而且是有關可持續性和可擴展性的問題。按照目前的情況，完全同步和下載一個歸檔節點已經需要幾個星期的時間，說實話，這還是使用以太坊網絡頻率最低的時候。
如果你不是一個超級技術人員，或者不了解以太坊區塊鏈的詳細情況，你可能會認為這是因為這條鏈太長了。但這只是部分原因。事實上，同步所有區塊(塊頭、塊哈希)只是這個過程的一部分。
問題在于，包括狀態樹(state trie)在內的大量必要信息塊并不包含在區塊本身中。狀態樹是一個復雜的結構，包含當前所有的賬戶和一組密碼證明。在節點能夠以加密方式證明任何賬戶的任何內容之前，需要將這些信息提供給節點。同步這些信息所花的時間和同步區塊鏈本身所花的時間一樣長，甚至更長。
這并不是一個新問題。以太坊黃皮書中寫道，處理和存儲整個狀態樹非常笨重，并建議：“或許可以將區塊鏈壓縮：狀態樹中沒有發送/接收某個固定數量區塊中交易的節點可以丟棄掉，從而減少狀態數據庫的增長。”
今年3月，在討論構建Ethereum 2.0的想法時，Vitalik Buterin在Ethresearch提出了一個通過收取租金來限制狀態增長的模型。
從不同的角度來處理這個問題
雖然有關狀態大小的問題很早以前就意識到了，但它最近已成為開發者社區討論的一個關鍵主題。以太坊魔術師團體（The Fellowship of Ethereum Magicians）有一個專門負責以太坊Casper/Sharding升級前的Ethereum 1.x開發的團隊。這個團隊包括兩個工作組，他們致力于解決以太坊日益增長的大規模數據存儲的問題，兩個工作組的角度都不一樣:一個工作組專注區塊鏈剪裁和狀態減少（刪除舊的和不必要的數據）,另一個是研究狀態租金的工作組，專注于管理以太坊狀態的增長。雖然對狀態縮減和區塊鏈剪裁的需求與管理狀態大小的需要密切相關，但是這些問題需要不同的解決方案，因此需要不同的權衡以及單獨的討論和文章。
簡單地說，關于區塊鏈剪裁和狀態減少的討論集中在效率和可擴展性之間的權衡，以及安全性和不可變性之間的權衡。圍繞通過征收狀態租金來減少狀態增長的討論需要面對這樣一個事實，即征收狀態租金將顯著損害已經很棘手的用戶體驗，并對現有應用程序造成不必要的負擔，這些應用程序的開發人員無法將狀態租金納入他們的設計之中。雖然兩者都很重要，但本文的重點是討論如何通過狀態租金來限制狀態樹的增長。
為什么要收取狀態租金
征收狀態租金的解決方案是由Turbo Geth開發人員阿列克謝?阿赫諾夫(Alexey Akhunov) 提出，它適用于狀態租金提議者所說的“活躍狀態”， “活躍狀態”由“所有非空賬戶和所有已創建但未自毀的合約”組成。
狀態租金作為解決狀態膨脹問題的一種方法，其背后的理念包含兩個方面：其中一個好處是，通過未支付租金可以很容易識別出不活躍賬戶或無價值數據，然后將這些數據從狀態中“驅逐”出去。如果在以太坊上做開發花費更多，人們會更加明智地對待他們在以太坊上所做的事，這說得過去。對賬戶活動消耗的磁盤空間收取租金，可以鼓勵開發者開發出更多存儲優化型合約，并吸引更多對數據敏感的用戶。如果賬戶數量減少、活躍賬戶更少、而賬戶的效率提高，那么狀態樹的增長率必然會放緩。
征收狀態租金的意義
目前，那些認為狀態租金是最可行的人正在討論誰應該支付租金，以及如何計算租金等細節。這些問題具有重大意義。
誰來支付租金是一個特別有意義的問題，尤其是考慮到抗審查制度時。對于社區中的許多人來說，以太坊最吸引人的承諾在于，它使很多組織能夠在沒有太多或任何人為干預的情況下運行，從而使企業永遠不會被監管機構或任何人關閉。要求組織定期支付費用以維護數據可用性會有違最初承諾，至少對于已經部署的應用程序來說是這樣，這些應用程序的開發人員無法預料到這種需求
不過，在阿赫諾夫的提議中，他承認即使提前通知，合約也可能難以向用戶收取租金。此外，用戶也有可能做出不負責任或惡意的行為，通過為合約灌輸大量數據，從而推高租金。由于這些原因，基于數據存儲對合約收取狀態租金會比較復雜。
即使與應用程序交互的個人用戶出于存儲數據而支付費用，如果出于某種原因被阻止支付或無法跟上他們的費用，強制性狀態租金也可能對抗審查制度產生負面影響。
需要注意的是，如果合約沒有支付租金，合約或賬戶本身不會被刪除，而只會刪除活動狀態中的信息(如賬戶余額)。如果數據通過其他方式可用，則合約可以繼續執行; 阿赫諾夫和其他人討論了個人或組織下載和存儲他們自己的數據、以及某些節點選擇這樣做的可能性。
阿赫諾夫試圖在他的提案草案中解決這些問題，但他承認，征收狀態租金將產生嚴重后果。他說道：
“不幸的是，在我看來，大多數合約都需要重新編寫、重新部署以及重新填充數據。對我來說，要么修改合約，要么平臺走向滅亡，兩者必選其一。”
也許狀態租金可以緩一緩
凱西?德特里奧（Casey Detrio）是Ethereum 1.x的核心開發者，他撰寫了一篇名為《Ethereum 1.x：主網升級路線圖草案》（"Ethereum 1 dot X: a half-baked roadmap for mainnet improvements）的文章，概述了存儲空間有限的問題以及提出了一些解決狀態膨脹的方案。他在總結中指出，一些研究人員認為只要Ethereum 2.0能相對快速地啟動，它將成為一種解決方案。當然，這是基于Casper和分片將很快到來的假設，如果真的是這樣，將是一個相當大的飛躍。此外，斷言狀態大小在Ethereum 2.0下不再有問題并不是一個公認的事實，因為分片技術并不提供無限的可擴展性。
對此，德特里奧提到了這樣一個擔憂:“在Ethereum 1.0上引入租金機制可能會讓用戶感到困惑，因為它可能與在2.0上引入的租金機制不同。”
征收狀態租金的主要替代方法是創建無狀態客戶端和無狀態合約。不過，這種選擇的可行性仍有爭議。此外，它將迫使所有合約負責存儲和維護它們自己的數據，這可能有點壓力。
當前工作
想要了解更多關于阿赫諾夫狀態州租金提案的細節，請查看GitHub，或者關注以太坊魔術師團體和Ethresearch論壇中的討論。
與此同時，社區還需要做更多的工作來發展提案和概念證明，以檢驗任何狀態租金機制所帶來的后果。一旦發生這種情況，將由客戶端和Dapp開發人員做出權衡，并決定愿意做出哪種選擇。
1.TMT觀察網遵循行業規范，任何轉載的稿件都會明確標注作者和來源；
2.TMT觀察網的原創文章，請轉載時務必注明文章作者和"來源：TMT觀察網"，不尊重原創的行為TMT觀察網或將追究責任；
3.作者投稿可能會經TMT觀察網編輯修改或補充。
