以太坊“狀態”規模快速膨脹，開發人員考慮向用戶收取“狀態租金”
以太坊開發者社群正面臨一些決定以太坊網路可用性的艱難決定，一些核心開發人員預測，如果以太坊的狀態大小（state siz）繼續以目前的速度增長，以太坊網路將在三年內崩潰。
圖片來源： ofollow,noindex" target="_blank">visualhunt
減緩其增長的首要解決方案是徵收“狀態租金（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/">GitHub ，或者關注 以太坊魔術師團體 和 Ethresearch 論壇中的討論。
與此同時，社群還需要做更多的工作來發展提案和概念證明，以檢驗任何狀態租金機制所帶來的後果。一旦發生這種情況，將由客戶端和Dapp開發人員做出權衡，並決定願意做出哪種選擇。