乾貨 | 如何復活已經被遺忘的狀態？過期狀態復活方法比較

原標題：《乾貨 | 過期狀態復活方法比較》

感謝 @adietrichs 對本文的審閱。

狀態保質期（中文譯本）是目前解決狀態增長問題（中文譯本）的推薦方案。

在本文中，我們將狀態保質期視為一種會定期讓完整狀態樹失效的機制。本文將討論如何存儲之前的周期（period），因為我們的關注點就是如何復活已經被遺忘的狀態 —— 無論 n=0 還是 n=1。

以下總結了一些機制提案：

清空

顧名思義，“清空” 就是什麼都不剩：過了保質期的狀態會立馬失效，如果用戶需要使用已失效狀態中的部分數據，必須提供對應的見證數據（witness）。請注意，若要讀取或寫入還未在有效狀態中初始化的部分，用戶必須提供證明：要麼是一個除外證明（exclusion proof）來表明這部分數據在之前任意時刻都沒有初始化，要麼是一個具體時間點的證明，然後再提供一個除外證明來表明這部分數據在這個時間點之後沒有改變過。

利

非常簡單

弊

除外證明的大小會隨時段數量呈線性增長，讓初始化狀態數據的成本變得異常高
逃避了地址衝突問題

帶周期標記的地址（PWA）

清空元數據的主要問題在於，初始化新的狀態元素會產生很高的成本。通過讓地址帶上周期標記，以太坊協議可以創建一種機制來避免在初始化新的狀態數據時產生地址衝突。鑒別器會設定賬戶最少能夠存活到哪個時段。目前有兩種方法可以實現 PWA：

地址空間擴展（ASE）

Vitalik 的文章
Ipsilon 的文章

太長不看：同時允許傳統的 20 個字節的地址和 32 個字節的 ASE 前綴地址存在。在以太坊虛擬機中創建一個環境變量來修改涉及地址的操作碼的行為，具體視相關地址是傳統地址還是 ASE 地址而定。

利

新的狀態無需證明即可初始化。
可擴展以保存其它元數據。
解決地址衝突問題。

弊

需要對 EVM 進行大量修改。
需要創建兩種不同的 EVM 環境，分為傳統模式和擴展模式。
轉換映射將無限增長（與傳統環境中使用的長地址數量呈線性關係），而且無法用過期機制來拋棄似乎是可以有過期機制的，只不過（拋棄數據后）要承擔一些地址衝突的風險。
用戶體驗不佳，因為用戶可以將資產存儲在三種類型的地址上（短地址、長地址、壓縮地址）。
並非所有 Solidity 編譯的合約的掩碼地址都有 160 位，因此一些合約的地址可能會存在高階臟位（dirty upper bit）。

（點擊此處，查看 Ipsilon 的完整分析。）

免擴展的 PWA

Vitalik 的文章

太長不看：找到一個未使用過的 4 個字節的前綴，並禁止在舊規則下使用該前綴創建新的合約/地址。舊合約在傳統模式下執行，只可根據舊規則創建新的地址。新類型的合約在 PWA 模式下執行，只可創建新的合約（其中，開頭 4 個字節是預先選好的前綴，第 5 – 6 個字節代表當前時段，第 7- 20 個字節照例代表地址。）

利

新的狀態無需證明即可初始化。
對 EVM 的修改相對較少。
不需要轉換表，用戶只需要考慮一種地址。
不會破壞現有工具（不過它們顯示的可能是異或地址（xor'd address）而非原像？）

弊

發生地址衝突的概率較高，不再有反事實合約。
不是一個很有吸引力的解決方案，可能會讓地址擴展變得越來越難。

周期元數據

狀態樹元數據

這個想法應該還沒有被正式定義（就算有也只是在 @adietrichs 的腦中），但它的大體思路是在狀態樹中的賬戶對象處增加一個新的字段來表示創建時間。這樣可以解決因除外證明而導致新的存儲項初始化成本過高的問題（尤其是在假設合約是為了在每個周期部署新的子合約而編寫的情況下），但是不會改善為創建新賬戶而創建新賬戶的問題。

利