觀點| 以太坊狀態規模管理諸提議（上）
從狀態樹上移除vs. 給狀態樹安排一個“退休” 部分
另一個區分不同狀態過期提議的技術角度是“一樹流” 和“二樹流”。也就是說，我們到底是像現在這樣，只有一棵狀態樹，只不過把某些狀態標記為過期；還是直接把失活的狀態從主狀態樹上移除，轉移到另一棵專門的（只包含過期狀態的）樹（或者其他數據）上？
一樹流
- 激活節點以白色標記，失活節點以灰色標記-
注意，即使是樹上的中間節點，也會被標記為激活或者失火（或者，更現實一點的方案，每個節點都會帶有失活日期的標記，所以能夠容易檢查其活性）；標記工作可以在狀態樹上的每個節點（葉子節點和中間節點）處完成。
二樹流
- 白色的樹包含激活狀態；灰色的樹存儲失活狀態-
一樹流的好處是，最起碼，其工作方式看起來會跟當前的狀態樹相似，失活和復活的流程也比較簡單：復活流程只需刷新樹上相關節點的“過期日期” 參數，而失活則是自動化的。但它的缺點在於：它需要一種能夠在節點中以此種方式存儲過渡信息（intermediate information）的樹結構，而且不能很好地擴展到Verkle 樹。此外，它還需要額外的默克爾證明元件，不僅要能夠下沉到葉子節點，還要能夠（在需要證明某部分狀態已經過期時）停在中間節點處。
二樹流的好處是：當前的、形式純粹的狀態累加器就能支持這類方案，而無需為每個節點增加元數據。缺點是，它需要對整個協議做一些更深層次的變更，而且需要一個顯式的流程來滅活狀態（所以過期不再是自動化的了）。另外，它也沒有為複活衝突兩難（見下一節）提供內置的解決方案，所以需要在兩種辦法中作出選擇。
注意，在二樹流中，存儲失活狀態的數據結構不是非樹不可。事實上，完全有可能出現這樣一種設計：需要復活一個狀態對象時，只需提供一個指向該對象失活時候收據的默克爾樹，再附上一些密碼學證據，證明此前該對象未被復活過（或者最近又重新過期），即可。
復活衝突
然後我們就到了狀態過期方案的一個關鍵難題上：“復活衝突”。復活衝突的概念如下。假設某個賬戶由地址A 生成；這個賬戶過期了；然後，地址A 又創建了一個新的賬戶（例如，使用CREATE2 操作碼保證兩次生成的賬戶的地址是同一個）；最後，地址A 再嘗試復活那個最開始的賬戶。這時候會出現什麼情況？
這裡有幾種可能的解決方案：
顯式的“賬戶合併” 流程：類似於規定“除了兩個賬戶的ETH 餘額相累加以外，以舊賬戶的狀態為準”或者“除了累加ETH 之外，以新賬戶的狀態為準”；甚至於，可以由舊賬戶的合約代碼來規定特殊的合併流程通過消除同一地址重複部署的功能來確保復活衝突不會發生：也就是調整CREATE2 的功能，比如在最終哈希成地址的數據原像中包含當前時間，因此即使未來使用同樣的數據來生成，也無法得到同樣的地址向狀態對象增加一個“存根”，以防止在同一位置生成新賬戶（上述一樹流方法自動實現了這一功能）要求生成新賬戶時都必須附帶該賬戶此前未過期的證明：某種意義上等價於存根方案，只不過這種辦法是把存根放在狀態的一個單獨部分中，所以任何想要創建合約賬戶的用戶都必須跟踪這部分狀態
（注意，如果我們使用存儲槽過期方案，則上述任一解決方案都必須延伸到單個存儲槽層面，而不能止步於賬戶層）
主要的擔憂有：（1）會給應用增加很多複雜性，他們需要加入合併的邏輯；（2）這樣做了之後，除非在鏈上“註冊” 一個地址，否則用戶就沒法再輕易獲得可以與之交互、可以積累資產（例如ERC20 token）的地址了。未註冊的地址是很重要的：任何第一次收到ETH 的用戶都是在使用一個尚未註冊的地址。這第（2） 的擔憂的根源是：未註冊的地址實際上有了時間限制，如果用戶生成了一個地址、收到了資金，但在接下來一年裡忘了發送交易（也就是忘了“註冊”），那他的資金就會被鎖住。
注意，EOA 也不能倖免。雖然看起來能夠，因為EOA 的合併流程比較簡單（只需把舊的ETH 餘額加到新的里，對nonce 則有EIP 169）這樣的方案。不過，這裡也有兩個問題。首先，賬戶抽象的目標是用合約來替代EOA，而賬戶抽象化的合約的合併流程可能並不簡單。其次，會受過期和復活事件影響的不僅有EOA 本身，還有該EOA 所參與的應用中的相關存儲鍵（例如ERC20 token 餘額），所以還是需要復雜的合併邏輯。
因此，從我的角度來看，破壞性最小的是某種形式的存根方案。不過，存根方案裡存在一個信息理論問題，會導致一些奇怪的結果。為了防止新的狀態對像在N 個已經過期的狀態對象位置處創建，一個覆蓋（cover）了這N 個地址（以及/或者存儲鍵）的集合必須是狀態的一部分。如果這個集合是信息最小化的（即，只包含了這些地址），那麼這個集合的大小會是O(N)，因此其狀態規模也是O(N)；那麼，激活狀態的規模就將與失活狀態的規模成比例，所以實際上我們並沒有解決這個問題。
Tree rot
解決這個問題的唯一辦法就是覆蓋超過那N 個賬戶的信息；實際上，我們將不得不讓整棵樹都變得不可訪問（再次提醒，這就是一樹流解決方案的實質：如果兩個賬戶過期了，它們之間的所有空間都會隱式過期（ if two accounts get expired, all the space in between them also implicitly gets expired））。
而這裡還有一個問題：這產生了一種形式的“樹發霉（tree rot）”，隨著時間推移，對於新帳戶的創建來說，狀態樹的所有部分都是不可訪問的，至少對那些沒有跟踪該區域過期狀態的用戶來說是這樣的。
而樹發霉導致的次生問題也必須解決。舉個例子：如果一個合約要創建子合約，它必須能夠在要么未發霉，要么用戶具有見證數據的狀態區域創建合約（也許需要用戶提供的“提示”）。樹發霉問題的一個解決方案見此處：持續地開放狀態的新區域以供賬戶創建。另一種思路是每個用戶都選擇狀態的某些區域（例如狀態的1/256），跟踪該區域的變化（包括過期狀態）以便能創建見證消息，並且只在該區域創建帳戶。
樹發霉的另一個問題是，它需要一個顯式的數據結構來存儲和檢查範圍。如果一棵樹有能夠放在節點中、指明該節點以下的哪些部分已經過期的數據（就像一樹流解決方案所用的那樣），那是最好的，但一個鍵值對存儲要做到這一點還是相當有難度的。
回頭再看強無狀態性
在狀態過期方案中使用樹結構所產生的許多問題，都可以被追溯到這樣一個事實：我們需要對哪些狀態是活躍的、哪些狀態是失活的，達成共識。在二樹流模式中，這一點更加明顯；但即使是在一樹流模式中，狀態樹上也需要有顯式的標記，以便近期使用快速同步下載了狀態的以太坊節點能夠確定一筆嘗試訪問某個賬戶、但又沒有提供見證消息的交易，應該成功還是失敗。那我們能不能做到不需要明確這個區別呢？
如果我們實現了完全的無狀態性，然後能幫助交易發送者和區塊生產者可靠地獲得見證消息生成所需的狀態，不就解決這個問題了嗎？那什麼辦法能幫助交易發送者和區塊生產者做到這些呢？
一種自然而然的辦法是：網絡中的節點都僅保存狀態樹的一部分，例如，在過去一年中訪問到的那部分。只需在客戶端設定中加入一個自願的設定即可。如果我們想要更可靠一些，我們可以通過引入一種proof of custody 方案，強制至少礦工（後面就是PoS 的驗證者）存儲一些數據。
有一點需要注意：如果共識層不能感知哪些狀態是活躍的、哪些狀態是失活的，那訪問近期狀態和老舊狀態的Gas 開銷就是一樣的。這會導致兩個結果：
訪問近期狀態的Gas 開銷也需要進一步提高包含了見證消息的區塊大小上限可能非常之大，如果一個區塊裡滿是訪問老舊狀態的事務的話（大概是800 bytes * 12.5 m gas / 2400 gas per access ~= 4.1 MB，已假設實行了EIP-2929，轉成了二進制樹）
如果我們想避免這些不利因素，就需要在共識中跟踪哪些狀態對象（包括尚未填滿的地址空間區域）是活躍狀態，這又會讓我們回到接近於狀態過期方案的屬性。這再一次地說明了，“無狀態性vs. 狀態過期（狀態租金）” 是一條光譜，是一個複雜的權衡空間，而不是一個非此即彼的選擇。
Rollup 也需要，也可以，使用同樣的解決方案
以太坊的一種重要的中期可擴展性解決方案是rollups（中文譯本）。不過，rollup 本身並非不再需要擔憂狀態數據規模問題；實際上，rollup 系統的狀態規模問題，與以太坊鏈本身的，性質完全相同。
幸運的是，如果我們能推出一種解決方案，則至少EVM rollup（嘗試最大程度複製以太坊運行環境的rollup 方案）能夠使用同樣的解決方案，來解決其內部狀態的規模問題。因此，狀態規模管理方案，與rollup 和分片等可擴展性方案是互補的（state size management is complementary to rollups, sharding and other scaling strategies）。
（譯者註：個人認為此處的“互補”一詞有嚴重誤導性。）
結論
狀態規模是一個日益惡化的問題，而狀態規模的解決方案也能為大幅提高區塊Gas 上限鋪平道路。我們應該對某種形式的狀態過期方案達成共識並加以實現。不過，不同的解決方案之間存在重大技術權衡，尤其如果我們還想要保持當前設計的一些重要屬性的話。
一些我們可能需要犧牲的屬性包括：
用戶可以離線生成賬戶並以該地址接收資金、並且在使該地址在鏈上顯明之前可以靜默任意時長的屬性地址保持20 字節的長度（rolling state expansion 方案需要更大的地址空間，雖然地址的長度可能本來就需要為抗碰撞的緣故很快改變）狀態可以被視為“純粹的” 鍵值對存儲的屬性，以及無需在狀態樹上每個節點內存儲元數據的屬性現有的應用需要程度不等的重寫，以保證用戶無需存儲全部失活狀態就能生成見證數據Gas 消耗量；或者創建新合約、寫入新存儲槽的難度
我們如果已經準備好作出犧牲，有些方案可以很快開始著手實現。另一方面，也許假以時日，我們能修補或者更好地匯總這些觀念，減少問題，尤其是使它們在技術上更容易實現（例如，允許使用“純粹的” 鍵值對存儲）。我們應該更深入地理解我們更願意/更不願意接受哪些方面的犧牲，並繼續積極研究改進提案。
原文鏈接:
https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/state_size_management
作者: Vitalik Buterin
