原文標題：《另一個狀態友好的界地址方案》
二級標題
二級標題

回顧：狀態大小管理技術

為了防止以太坊的狀態容量無止境地膨脹，我們需要用一些方法使舊狀態「失活」, 這樣加入網絡的節點就不再需要存儲舊狀態了。即使大多數的客戶端都變成無狀態，似乎也可以合理預見，最終這個系統會擴容到網絡無法一直保證所有狀態都可用的地步。有兩個方法可以使舊狀態失活：

• 直接刪掉，然後可以把它移到另外的默克爾樹，這樣關心該狀態對象的人可以獲取相應的默克爾分支，在未來某個時候用它來激活該狀態。

• 不把對象移出樹結構；相反，只在樹的該位置標記「失活」，這樣節點就不會存儲它(且協議也不會要求它們這樣做)。通過發送一個提供默克爾證明(即見證數據) 的事務來訪問該狀態，失活的對象就可以重新被訪問了。

方法(1) 對應於「經典的存儲租金方案」，方法(2) 對應於傳統「無狀態客戶端」的最簡單延伸——舊狀態可以被遺忘的模型。這兩種方法都允許關心特定狀態對象的個人追踪默克爾分支，這樣隨後如果那些狀態對象失活了它們可以用來激活這些對象。然而，這兩種方法都是有明顯問題的。

二級標題

二級標題

提議

我提議對方法(2) 進行修改，可以解決以上的問題。正如很多方法(2) 的提議實現方案所呈現的，賬戶有「活躍」與「失活」兩種狀態，失活賬戶是那些超過一年未被訪問過的賬戶。要訪問失活賬戶，你需要提供見證數據；當失活賬戶被訪問了，該賬戶會自動解除失活狀態(觸及任何賬戶都會重置它的一年失活期計算)。修改內容如下：

我們給每個地址添加一個32 個字節的「epoch 前綴」 （會被解譯為一個整數）。例如，epoch 前綴是9 的地址是這樣：0x00000009de0b295669a9fd93d5f28d9ec85e40f4cb697bae，以00000009 作為前綴。

默克爾路徑會直接依賴epoch 的前綴而不是它的哈希值(因此merkle_path_key = address[:4] + hash(address[4:]) 而不是現在在用的merkle_path_key = hash(address) 。這確保了「沒用過的」地址空間是連續的。

除非地址的epoch 前綴是小於或等於區塊鏈已運行的年數，否則地址不能被使用

會增加一個CREATE3 操作碼，它會把epoch 前綴作為一個參數，並在具有該epoch 前綴的一個地址上創建一個合約。

推薦用戶和合約總是使用具有盡可能新的epoch 前綴來創建賬戶，甚至設為默認設置，因為肯定會有具有最新epoch 前綴的全狀態仍然是可以訪問的。為了還能保有「反事實地址(counterfactual addresses)」（即在合約代碼被發布前，用戶在鏈上[例如通過發送ETH 或ERC20 代幣] 或鏈下[通過在一個通道裡互動] 交互的地址），用舊epoch 前綴來創建合約還是可能的。但是，對於想要創建反事實地址的用戶，如果長期不創建，他們就要負責為該賬戶存儲舊狀態的分支。

來源鏈接：

來源鏈接：

來源鏈接：ethresear.ch