編譯：GaryMa 吳說區塊鏈
Vitalik在近期的韓國區塊鏈週、新加坡演講甚至是以太坊執行層核心開發者會議(ACDE)上，都共同提及過一個話題：狀態（State），而隨之左右的則是與其相關的各種解決方案概念，如無狀態、狀態過期（StateExpiry）、歷史數據過期（HistoryExpiry，EIP-4444）、Verkle樹、甚至是地址空間的擴展\壓縮（Address Space Expand\Compression）。當然，這其實也不是什麼新的路線圖調整規劃，在Vitalik 去年11 月發布的以太坊的最新路線圖中，這些主要歸屬於TheVerge和ThePurge關鍵路線。
本文便結合這兩大關鍵路線以及一些新的思路挑戰，一起回顧一下Vitalik 心中的狀態解決路線。
狀態（State）
以太坊中的狀態指的是一個包括所有外部擁有賬戶（EOAs）、它們的餘額、智能合約部署以及相關存儲的綜合賬本。這個狀態不是靜態的；它會隨著新用戶的增加和新智能合約的部署而不斷擴展。
目前，全節點必須存儲這個不斷增長的數據集，以正確驗證區塊並確保狀態轉換正確，使驗證過程本質上是有狀態的。而這種不斷增長的存儲要求因此提高了運行全節點的硬件要求，將導致驗證者越來越中心化。
根據etherscan.io/數據，當前運行一個快速同步全節點至少需要1200 Gb（以Geth 客戶端為例），這還是在已經進行了狀態修剪，刪除了較早之前的狀態數據，只保留最近的狀態的前提下。如果是存檔節點，即全節點會保留所有歷史狀態，包括每個區塊的狀態，那麼需要的容量需要約15,400 Gb，並且未來還是一直增長，即社區常說的“狀態爆炸”。
這也是Vitalik 在韓國區塊鏈週上所強調的：節點的中心化是以太坊網絡面臨的最大問題之一，應該通過使節點的運行更便宜、更容易來解決。
為了應對這一系列挑戰，以太坊社區一直在努力尋找改進和優化的方法，即我們開頭所例舉的各種解決方案概念。
狀態解決方案
無狀態（Statelessness）
無狀態（Stateless）核心概念是將狀態數據外部化，不再需要每個節點存儲完整的狀態。在這種模式下，節點只需維護區塊頭和相關交易信息，通過狀態證明（State Proofs）來驗證和重建狀態。
無狀態的主要作用和意義在於減輕節點的存儲負擔，提高網絡可擴展性，使更多節點能夠輕鬆參與驗證，同時仍然保持了以太坊的去中心化性質。
Verkle 樹
目前，以太坊依賴Merkle-Patricia 樹來哈希和壓縮其狀態數據。然而，這種樹結構中Merkle證明的大小可能會變得太大，使它們不太適用於無狀態模型所需的見證。
為了解決這個問題，以太坊計劃過渡到Verkle 樹，這是一種更高效的數據結構。 Merkle-Patricia 樹和Verkle 樹都共享一個重要的能力，即生成見證——密碼學證明，允許任何人輕鬆確認狀態根中特定信息的存在與公開可用。
Verkle 樹的優勢在於它們在生成較小的證明大小方面效率更高。
歷史數據過期（HistoryExpiry，EIP-4444）
EIP-4444 旨在實施歷史數據過期，這是一項升級，要求節點停止在點對點網絡上託管超過一年的歷史區塊。刪除歷史數據顯著減輕了節點運營者的磁盤空間需求。同時，它還通過消除適應歷史區塊不同版本的代碼的需要，簡化了客戶端軟件。此外，EIP-4444與PDS（Proto-danksharding）的結合確保了定期數據修剪；EIP-4444 每年修剪一次，而PDS 每月修剪一次數據區塊。儘管這有助於減少節點的數據存儲需求，但也引發了有關歷史數據的保存和恢復的擔憂。
狀態過期（StateExpiry）
無狀態性消除了驗證者在驗證區塊時需要維護完整狀態的必要性。但狀態並不會消失；它的持續增長仍然是網絡的長期挑戰。
為了解決這個根本問題，社區便提出了狀態過期（State Expiry）方案。
狀態過期將自動修剪那些保持不變的狀態部分，比如一年，將它們移到一個單獨的樹結構中，並從主要的以太坊協議中刪除它們。
值得一提的是，狀態過期只有在遷移到Verkle 樹後才變得可行。另外，Vitalik 在韓國區塊鏈週KBW2023 上表示：如果有無狀態和PBS，狀態過期可以是低優先級的。
因為如果屆時區塊提議者構建者分離（Proposer-Builder Separation、PBS）實現後，在無狀態下，儘管區塊構建者仍需要訪問狀態來創建區塊，但屆時的區塊構建者已經被預期能夠有效處理狀態的增長，因為這領域允許一定程度的中心化，構建者們的節點性能自然能夠滿足需求。
儘管目前協議級別PBS 尚未納入以太坊主網，但是我們大致通過了解Mev-Boost PBS 當前的市場分佈，也能大致了解未來主網的一個趨勢走向，mevboost.pics 的數據統計如下：
另外，狀態過期（State Expiry）的實現涉及以太坊地址格式的改變，目前有兩種方案：地址空間擴展（address space extension）vs 地址空間壓縮（address space compression）。前者是將地址長度增加到32 字節（當前地址格式為20字節），但需要復雜的邏輯來向後兼容並且現有的合約也必須更新；後者雖然保留20字節格式，不過將前6 字節用於前綴以及地址週期的標識，雖然這樣大大減少了兼容難題，但也隨之引來另一個難題，地址長度只剩下14 字節便不再具有抗碰撞能力，從而引入一些地址創建的潛在安全問題，這也是目前社區所面臨的重大挑戰。
總結
現在，我們大致可以根據上述技術解決方案的實現難題以及緩急，排除前後優先級（2\3\4 或許可以同等）：
1. Verkle樹
2. PBS
3. 無狀態
4. 歷史數據過期（EIP-4444）
5. 以太坊地址格式的改變（壓縮/擴展）
6. 狀態過期
綜上，可降低節點運行門檻，保持節點的去中心化以及潛在的狀態爆炸問題，減輕狀態增長以優化網絡通信負載。
當然，目前依舊是任重道遠。
參考鏈接：
https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356
https://public.bnbstatic.com/static/files/research/ethereum-beyond-the-merge-.pdf
https://www.fx168news.com/article/295525
