Vitalik：以太坊的可能未來，The Purge

以太坊面臨的挑戰之一是，默認情況下，任何區塊鏈協議的膨脹和復雜性都會隨着時間的推移而增加。這發生在兩個地方：

歷史數據：歷史上任何時刻進行的任何交易和創建的任何帳戶都需要由所有客戶端永久存儲，並由任何新客戶端下載，從而完全同步到網路。這會導致客戶端負載和同步時間隨着時間的推移不斷增加，即使鏈的容量保持不變。

協議功能：添加新功能比刪除舊功能容易得多，導致代碼復雜性隨着時間的推移而增加。

爲了使以太坊能夠長期維持下去，我們需要對這兩種趨勢施加強大的反壓力，隨着時間的推移降低復雜性和膨脹。但與此同時，我們需要保留使區塊鏈變得偉大的關鍵屬性之一：持久性。你可以把一張 NFT、一封交易通話數據中的情書、或者一份包含 100 萬美元的智能合約放在鏈上，進入一個洞穴十年，出來時發現它仍然在那裏等待你閱讀和交互。爲了讓 DApp 放心地完全去中心化並刪除升級密鑰，他們需要確信他們的依賴項不會以破壞他們的方式升級 - 特別是 L1 本身。

如果我們下定決心，在這兩種需求之間取得平衡，並在保持連續性的同時最大限度地減少或扭轉臃腫、復雜性和衰退，這是絕對可能的。生物體可以做到這一點：雖然大多數生物體都會隨着時間的推移而衰老，但少數幸運兒卻不會。即使是社會系統也可以有極長的壽命。在某些情況下，以太坊已經取得了成功：工作證明消失了，SELFDESTRUCT操作碼大部分消失了，信標鏈節點已經存儲了最多六個月的舊數據。以更通用的方式爲以太坊找出這條道路，並走向長期穩定的最終結果，是以太坊長期可擴展性、技術可持續性甚至安全性的終極挑戰。

The Purge:主要目標。

通過減少或消除每個節點永久存儲所有歷史記錄甚至最終狀態的需要來降低客戶端存儲要求。

通過消除不需要的功能來降低協議復雜性。

文章目錄：

History expiry（歷史記錄到期）

State expiry（狀態到期）

Feature cleanup（特徵清理）

History expiry

解決什麼問題？

截至撰寫本文時，完全同步的以太坊節點需要大約 1.1 TB的磁盤空間用於執行客戶端，另外還需要數百 GB 的磁盤空間用於共識客戶端。其中絕大多數是歷史：有關歷史區塊、交易和收據的數據，其中大部分已有多年歷史。這意味着即使 Gas 限制根本沒有增加，節點的大小每年也會持續增加數百 GB。

它是什麼，它是如何工作的？

歷史存儲問題的一個關鍵簡化特徵是，因爲每個塊通過哈希連結（和其他結構）指向前一個塊，所以對當前達成共識就足以對歷史達成共識。只要網路對最新區塊達成共識，任何歷史區塊或交易或狀態（帳戶餘額、隨機數、代碼、存儲）都可以由任何單個參與者提供以及 Merkle 證明，並且該證明允許其他任何人驗證它的正確性。共識是 N/2-of-N 信任模型，而歷史是N-of-N 信任模型。

這爲我們如何存儲歷史記錄提供了很多選擇。一種自然的選擇是每個節點僅存儲一小部分數據的網路。這就是種子網路幾十年來的運作方式：雖然網路總共存儲和分發了數百萬個文件，但每個參與者僅存儲和分發其中的幾個文件。也許與直覺相反，這種方法甚至不一定會降低數據的穩健性。如果通過讓節點運行更加經濟實惠，我們可以建立一個擁有 100,000 個節點的網路，其中每個節點存儲隨機 10% 的歷史記錄，那麼每條數據將被復制 10,000 次 - 與 10,000 個節點的復制因子完全相同-節點網路，每個節點都存儲所有內容。

如今，以太坊已經開始擺脫所有節點永久存儲所有歷史的模型。共識區塊（即與權益證明共識相關的部分）僅存儲約 6 個月。 Blob 僅存儲約 18 天。EIP-4444旨在爲歷史區塊和收據引入一年的存儲期。長期目標是建立一個統一的時期（可能約爲 18 天），在此期間每個節點負責存儲所有內容，然後建立一個由以太坊節點組成的點對點網路，將舊數據存儲在分布式網路方式。

Erasure codes可用於提高robustness，同時保持復制因子相同。事實上，Blob 已經進行了糾刪碼，以支持數據可用性採樣。最簡單的解決方案很可能是重新使用這種Erasure codes，並將執行和共識塊數據也放入 blob 中。

與現有研究有哪些聯繫？

EIP-4444；

Torrents and EIP-4444；

門戶網路；

門戶網路和 EIP-4444；

Portal 中 SSZ 對象的分布式存儲和檢索；

如何提高gas限制（Paradigm）。

還需要做什麼，需要權衡什麼？

剩下的主要工作包括構建和集成一個具體的分布式解決方案來存儲歷史記錄------至少是執行歷史記錄，但最終還包括共識和 blob。最簡單的解決方案是 (i) 簡單地引入現有的 torrent 庫，以及 (ii) 稱爲Portal 網路的以太坊原生解決方案。一旦引入其中任何一個，我們就可以打開 EIP-4444。 EIP-4444 本身不需要硬分叉，但它確實需要新的網路協議版本。因此，同時爲所有客戶端啓用它是有價值的，否則存在客戶端因連接到其他節點期望下載完整歷史記錄但實際上並未獲取而發生故障的風險。

主要的權衡涉及我們如何努力提供"古代"歷史數據。最簡單的解決方案是明天停止存儲古代歷史，並依賴現有的存檔節點和各種集中式提供程序進行復制。這很容易，但這削弱了以太坊作爲永久記錄場所的地位。更困難但更安全的途徑是首先構建並集成 torrent 網路，以分布式方式存儲歷史記錄。在這裏，"我們有多努力"有兩個維度：

我們如何努力確保最大的節點集確實存儲了所有數據？

我們將歷史存儲集成到協議中的深度有多深？

對於（1）的一種極端偏執的方法將涉及托管證明：實際上要求每個權益證明驗證器存儲一定比例的歷史記錄，並定期以加密方式檢查它們是否這樣做。更溫和的方法是爲每個客戶端存儲的歷史百分比設置一個自願標準。

對於 (2)，基本實現只涉及今天已經完成的工作：Portal 已經存儲了包含整個以太坊歷史的 ERA 文件。更徹底的實現將涉及實際將其連接到同步過程，這樣，如果有人想要同步完整歷史記錄存儲節點或存檔節點，即使沒有其他存檔節點在線存在，他們也可以通過直接同步來實現來自門戶網路。

它如何與路線圖的其他部分交互？

如果我們想讓節點運行或啓動變得極其容易，那麼減少歷史存儲需求可以說比無狀態性更重要：在節點需要的 1.1 TB 中，約 300 GB 是狀態，剩餘的約 800 GB GB 已成爲歷史。只有實現無狀態性和 EIP-4444，才能實現在智能手表上運行以太坊節點並且只需幾分鍾即可設置的願景。

限制歷史存儲還使得較新的以太坊節點實現更可行，僅支持協議的最新版本，這使它們變得更加簡單。例如，現在可以安全地刪除許多代碼行，因爲 2016 年 DoS 攻擊期間創建的空存儲槽已全部刪除。既然轉向權益證明已經成爲歷史，客戶可以安全地刪除所有與工作量證明相關的代碼。

State expiry

解決什麼問題？

即使我們消除了客戶端存儲歷史記錄的需要，客戶端的存儲需求也將繼續增長，每年約 50 GB，因爲狀態持續增長：帳戶餘額和隨機數、合約代碼和合約存儲。用戶可以支付一次性費用，從而永遠給現在和未來的以太坊客戶帶來負擔。

狀態比歷史更難"過期"，因爲 EVM 從根本上來說是圍繞這樣一個假設而設計的：一旦創建了狀態對象，它就會始終存在，並且可以隨時被任何事務讀取。如果我們引入無狀態性，有人認爲這個問題也許並沒有那麼糟糕：只有專門的區塊構建器類需要實際存儲狀態，而所有其他節點（甚至包含列表生成！）都可以無狀態運行。然而，有一種觀點認爲，我們不想過多依賴無狀態性，最終我們可能希望使狀態過期以保持以太坊的去中心化。

它是什麼，它是如何工作的

今天，當您創建一個新的狀態對象時（可以通過以下三種方式之一發生：（i）將 ETH 發送到新帳戶，（ii）使用代碼創建新帳戶，（iii）設置以前未觸及的存儲槽） ，該狀態對象永遠處於該狀態。相反，我們想要的是對象隨着時間的推移自動過期。關鍵的挑戰是以實現三個目標的方式做到這一點：

效率：不需要大量的額外計算來運行到期過程。

用戶友好性：如果有人進入洞穴五年並回來，他們不應該失去對 ETH、ERC20、NFT、CDP 頭寸的訪問權......

開發人員友好性：開發人員不必切換到完全不熟悉的思維模型。此外，目前已經僵化且不更新的應用程序應該可以繼續正常運行。

不滿足這些目標就很容易解決問題。例如，您可以讓每個狀態對象還存儲一個過期日期計數器（可以通過燃燒 ETH 來延長過期日期，這可能在任何時候讀取或寫入時自動發生），並有一個循環遍歷狀態以刪除過期日期的過程狀態對象。然而，這引入了額外的計算（甚至存儲需求），並且它肯定不能滿足用戶友好性的要求。開發人員也很難推理涉及存儲值有時重置爲零的邊緣情況。如果你在合同範圍內設置到期計時器，這在技術上會讓開發者的生活變得更容易，但它會讓經濟變得更加困難：開發者必須考慮如何將持續的存儲成本"轉嫁"給用戶。

這些都是以太坊核心開發社區多年來一直在努力解決的問題，包括"區塊鏈租金"和"再生"等提案。最終，我們結合了提案中最好的部分，並集中在兩類"已知最不糟糕的解決方案"上：

• 部分狀態過期解決方案
• 基於地址週期的狀態到期建議。

Partial state expiry部分狀態到期

部分狀態到期提案都遵循相同的原則。我們將狀態分成塊。每個人都永久存儲"頂級映射"，