Vitalik 新文：以太坊的可能未來（五）——The Purge

WEEX 唯客博客， 原標題：《Possible futures of the Ethereum protocol, part 5: The Purge》 作者：Vitalik Buterin 編譯：Odaily 星球日報 夫如何   自 10 月 14 日起，以太坊創始人 Vitalik Buterin 陸續發布對以太坊可能的未來的討論，從《The Merge》、《The Surge》、《The Scourge》、《The Verge》到最新發布的《The Purge》彰顯了 Vitalik 對以太坊主網的未來發展的暢想和如何解決目前所面臨問題的解決方案。 《The Merge》：探討了以太坊在轉向 PoS 后需改進單槽最終性和降低質押門檻，以提高參與度和交易確認速度。 《The Surge》：探討了以太坊擴容的不同策略，尤其是以 Rollup 為中心的路線圖，及其在可擴展性、去中心化和安全性方面的挑戰與解決方案。 《The Scourge》：探討了以太坊在向 PoS 轉型中面臨中心化和價值提取風險，開發了多種機制以增強去中心化和公平性，同時進行質押經濟改革以保障用戶利益。 《The Verge》：探討了以太坊無狀態驗證的挑戰與解決方案，重點介紹了 Verkle 樹和 STARK 等技術如何增強區塊鏈的去中心化和效率。 10 月 26 日，Vitalik Buterin 發布關於《The Purge》文章，文章中探討了以太坊面臨的挑戰是如何在長期內降低複雜性和存儲需求，同時保持鏈的持久性和去中心化，關鍵措施包括通過「歷史過期」和「狀態過期」減少客戶端存儲負擔，並通過「特徵清理」簡化協議，以確保網路的可持續性和可擴展性。 以下為原文內容，由 Odaily 星球日報編譯。 特別感謝 Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden 和 Tomasz Stanczak 的反饋和審查。 以太坊面臨的挑戰之一是，默認情況下，任何區塊鏈協議的膨脹和複雜性都會隨著時間的推移而增加。這發生在兩個地方： 歷史數據：歷史上任何時刻進行的任何交易和創建的任何帳戶都需要由所有客戶端永久存儲，並由任何新客戶端下載，從而完全同步到網路。這會導致客戶端負載和同步時間隨著時間的推移不斷增加，即使鏈的容量保持不變。 協議功能：添加新功能比刪除舊功能容易得多，導致代碼複雜性隨著時間的推移而增加。 為了使以太坊能夠長期維持下去，我們需要對這兩種趨勢施加強大的反壓力，隨著時間的推移降低複雜性和膨脹。但與此同時，我們需要保留使區塊鏈變得偉大的關鍵屬性之一：持久性。你可以把一張 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、ERC 20、NFT、CDP 頭寸的訪問權…… 開發人員友好性：開發人員不必切換到完全不熟悉的思維模型。此外，目前已經僵化且不更新的應用程序應該可以繼續正常運行。 不滿足這些目標就很容易解決問題。例如，您可以讓每個狀態對象還存儲一個過期日期計數器（可以通過燃燒 ETH 來延長過期日期，這可能在任何時候讀取或寫入時自動發生），並有一個循環遍歷狀態以刪除過期日期的過程狀態對象。然而，這引入了額外的計算（甚至存儲需求），並且它肯定不能滿足用戶友好性的要求。開發人員也很難推理涉及存儲值有時重置為零的邊緣情況。如果你在合同範圍內設置到期計時器，這在技術上會讓開發者的生活變得更容易，但它會讓經濟變得更加困難：開發者必須考慮如何將持續的存儲成本「轉嫁」給用戶。 這些都是以太坊核心開發社區多年來一直在努力解決的問題，包括「區塊鏈租金」和「再生」等提案。最終，我們結合了提案中最好的部分，並集中在兩類「已知最不糟糕的解決方案」上： 部分狀態過期解決方案 基於地址周期的狀態到期建議。 Partial state expiry 部分狀態到期 部分狀態到期提案都遵循相同的原則。我們將狀態分成塊。每個人都永久存儲「頂級映射」，其中塊為空或非空。僅當最近訪問過該數據時才會存儲每個塊中的數據。有一種「復活」機制，如果不再存儲 這些提案之間的主要區別是：（i）我們如何定義「最近」，以及（ii）我們如何定義「塊」？一個具體的提案是 EIP-7736 ，它建立在為 Verkle 樹引入的「莖葉」設計之上（儘管與任何形式的無狀態狀態兼容，例如二叉樹）。在這種設計中，彼此相鄰的標頭、代碼和存儲槽存儲在同一個「主幹」下。一個莖下存儲的數據最多可以是 256 * 31 = 7, 936 位元組。在許多情況下，帳戶的整個標頭和代碼以及許多密鑰存儲槽都將存儲在同一個主幹下。如果給定主幹下的數據在 6 個月內沒有被讀取或寫入，則不再存儲該數據，而是僅存儲該數據的 32 位元組承諾（存根）。未來訪問該數據的交易將需要「復活」數據，並提供根據存根進行檢查的證明。 還有其他方法可以實現類似的想法。例如，如果帳戶級別的粒度不夠，我們可以制定一個方案，其中樹的每個 1/2 32 部分都由類似的莖葉機制控制。 由於激勵因素，這變得更加棘手：攻擊者可以通過將大量數據放入單個子樹並每年發送單個交易來「更新樹」，從而迫使客戶端永久存儲大量狀態。如果您使續訂成本與樹大小成正比（或續訂持續時間成反比），那麼有人可能會通過將大量數據放入與他們相同的子樹中來傷害其他用戶。人們可以嘗試通過根據子樹大小使粒度動態化來限制這兩個問題：例如，每個連續的 2 16 = 65536 個狀態對象可以被視為一個「組」。然而，這些想法更為複雜；基於莖的方法很簡單，並且可以調整激勵措施，因為通常莖下的所有數據都與同一應用程序或用戶相關。 基於地址周期的狀態到期建議 如果我們想完全避免任何永久狀態增長，甚至是 32 位元組存根，該怎麼辦？由於復活衝突，這是一個難題：如果一個狀態對象被刪除，稍後 EVM 執行會將另一個狀態對象置於完全相同的位置，但之後關心原始狀態對象的人回來並嘗試恢復它，該怎麼辦？當部分狀態到期時，「存根」會阻止創建新數據。隨著狀態完全到期，我們甚至無法存儲存根。 基於地址周期的設計是解決這個問題的最著名的想法。我們不是用一棵狀態樹存儲整個狀態，而是有一個不斷增長的狀態樹列表，並且任何讀取或寫入的狀態都會保存在最新的狀態樹中。每個時期（例如： 1 年）添加一次新的空狀態樹。老樹都凍得嚴嚴實實的。完整節點僅存儲最近的兩棵樹。如果一個狀態對象在兩個周期內沒有被觸及，從而落入過期樹中，它仍然可以被讀取或寫入，但交易需要證明它的 Merkle 證明 – 一旦證明，就會保存一個副本再次在最新的樹中。 使這對用戶和開發人員都友好的一個關鍵思想是地址周期的概念。地址周期是屬於地址一部分的數字。關鍵規則是具有地址周期 N 的地址只能在周期 N 期間或之後（即，當狀態樹列表達到長度 N 時）被讀取或寫入。如果你要保存一個新的狀態對象（例如，一個新的合約，或者一個新的 ERC 20 餘額），如果你確保將狀態對象放入地址周期為 N 或 N-1 的合約中，那麼你可以保存立即進行，無需提供證據證明之前什麼都沒有。另一方面，在舊地址期間進行的任何添加或編輯都需要證明。 這種設計保留了以太坊當前的大部分屬性，不需要額外的計算，允許幾乎像現在一樣編寫應用程序（ERC 20 需要重寫，以確保地址周期為 N 的地址餘額存儲在子合約中，本身有地址周期 N)，解決了「用戶進山洞五年」的問題。然而，它有一個大問題：地址需要擴展到 20 位元組以上才能適應地址周期。 Address space extension 地址空間擴展 一項建議是引入一種新的 32 位元組地址格式，其中包括版本號、地址周期號和擴展散列。 0x01 （紅色） 0000 （橙色） 000001 （綠色） 57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF（藍色）。 紅色的是版本號。這裡橙色的四個零旨在作為空白空間，將來可以容納分片編號。綠色是地址周期號。藍色是 26 位元組的哈希值。 這裡的關鍵挑戰是向後兼容性。現有合約是圍繞 20 位元組地址設計的，並且通常使用嚴格的位元組打包技術，明確假設地址正好是 20 位元組長。解決這個問題的一個想法涉及轉換映射，其中與新式地址交互的舊式合約將看到新式地址的 20 位元組哈希值。然而，確保其安全性存在很大的複雜性。 地址空間收縮 另一種方法採取相反的方向：我們立即禁止一些 2 128 大小的地址子範圍（例如，所有以 0x ffffffff 開頭的地址），然後使用該範圍引入具有地址周期和 14 位元組哈希值的地址。 0xffffffff000169125 d5dFcb7B8C2659029395bdF 這種方法做出的主要犧牲是引入了反事實地址的安全風險：持有資產或許可權的地址，但其代碼尚未發布到鏈上。風險涉及有人創建一個地址，該地址聲稱擁有一段（尚未發布）代碼，但也有另一段有效的代碼散列到同一地址。今天計算這樣的碰撞需要 2 80 個哈希；地址空間收縮會將這個數字減少到易於訪問的 2 56 個哈希值。 關鍵風險領域，即非單一所有者持有的錢包的反事實地址，在今天相對罕見，但隨著我們進入多 L2 世界，可能會變得更加常見。唯一的解決方案是簡單地接受這種風險，但要確定可能出現問題的所有常見用例，並提出有效的解決方法。 與現有研究有哪些聯繫？ 早期提案 區塊鏈清潔； 再生； 以太坊狀態大小管理理論； 無狀態和狀態過期的一些可能路徑； 部分狀態到期提案 EIP-7736 ； 地址空間擴展文檔 原始提案； Ipsilon 評論； 博客文章評論； 如果我們失去碰撞抵抗力會破壞什麼。 還需要做什麼，需要權衡什麼？ 我認為未來有四種可行的道路： 我們做到無狀態，並且從不引入狀態過期。狀態正在不斷增長（儘管緩慢：我們可能看不到它 超過 8 TB 數十年），但只需要由相對 特殊類別的用戶：甚至 PoS 驗證器也不需要 狀態。需要訪問部分狀態的一個功能是包含列表生成，但我們可以以分散的方式完成此操作：每個用戶負責維護狀態樹中包含其自己帳戶的部分。當他們廣播交易時，他們會廣播交易並附帶驗證步驟期間訪問的狀態對象的證明（這適用於 EOA 和 ERC-4337 帳戶）。然後，無狀態驗證器可以將這些證明組合成整個包含列表的證明。 我們進行部分狀態到期，並接受一個低得多但仍然非零的永久狀態大小增長率。這個結果可以說類似於涉及對等網路的歷史過期提案如何接受每個客戶端必須存儲較低但固定百分比的歷史數據的低得多但仍然非零的永久歷史存儲增長率。 我們通過地址空間擴展來進行狀態過期。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括現有應用程序。 我們通過地址空間收縮來進行狀態過期。這將涉及一個多年的過程，以確保所有涉及地址衝突的安全風險（包括跨鏈情況）都得到處理。 重要的一點是，無論是否實施依賴於地址格式更改的狀態到期方案，最終都必須解決有關地址空間擴展和收縮的難題。如今，生成地址衝突大約需要 2 80 個哈希值，對於資源極其豐富的參與者來說，這種計算負載已經是可行的：GPU 可以執行大約 2 27 個哈希值，因此運行一年可以計算 2 52 ，因此所有世界上約 2 30 個 GPU 可以在約 1/4 年內計算一次碰撞，而 FPGA 和 ASIC 可以進一步加速這一過程。未來，此類攻擊將會向越來越多的人開放。因此，實施完全狀態到期的實際成本可能不像看起來那麼高，因為無論如何我們都必須解決這個非常具有挑戰性的地址問題。 它如何與路線圖的其他部分交互？ 進行狀態過期可能會使從一種狀態樹格式到另一種狀態樹格式的轉換變得更容易，因為不需要轉換過程：您可以簡單地開始使用新格式創建新樹，然後進行硬分叉來…