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

• 歷史數據：歷史上任何時刻進行的任何交易和創建的任何帳戶都需要由所有客戶端永久存儲，並由任何新客戶端下載，從而完全同步到網絡。這會導致客戶端負載和同步時間隨著時間的推移不斷增加，即使鏈的容量保持不變。
• 協議特點：添加新功能比刪除舊功能容易得多，從而導致代碼複雜性隨著時間的推移而增加。

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

The Purge (淨化)，2023 年路線圖。

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

The Purge（淨化）：主要目標

• 通過減少或消除每個節點永久存儲所有歷史記錄甚至最終狀態的需要來降低客戶端存儲要求。
• 通過消除不需要的功能，降低協議複雜性

在本文中

• 歷史記錄到期
• 狀態到期
• 功能清除

歷史記錄到期（History expiry）

它解決什麼問題？

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

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

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

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

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

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

與現有研究有哪些聯繫？

• EIP-4444： https://eips.ethereum.org/EIPS/eip-4444
• Torrents 和 EIP-4444： https://ethresear.ch/t/torrents-and-eip-4444/19788
• Portal Network： https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• Portal Network 和 EIP-4444： https://github.com/ethereum/portal-network-specs/issues/308
• Portal 中SSZ對象的分佈式存儲和檢索： https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• 如何提高 Gas 限制（Paradigm）： https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

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

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

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

1. 我們如何努力確保最大的節點集確實存儲了所有數據？
2. 我們將歷史記錄存儲深度集成到協議中？

對於（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）設置以前未觸及的存儲槽） ，該狀態對象永遠處於該狀態。相反，我們想要的是對象隨著時間的推移自動過期。關鍵的挑戰是以實現三個目標的方式做到這一點：

1. 效率：不需要大量的額外計算來運行到期過程
2. 用戶友好性：如果有人進入洞穴五年然後回來，他們不應該失去對 ETH、ERC20、NFT、CDP 頭寸的訪問權……
3. 開發者友好性：開發人員不必切換到完全陌生的思維模型。此外，目前已經僵化且不更新的應用程序應該可以繼續正常運行。

在不滿足這些目標的情況下，解決問題反而變得簡單。例如，我們可以讓每個狀態對象存儲一個表示其到期日期的計數器（通過銷燬 ETH 可以延長過期日期，這可以在讀取或寫入時自動進行），並設置一個循環來「遍歷狀態」並刪除過期的狀態對象。然而，這種方法會引入額外的計算開銷（甚至增加存儲需求），而且顯然無法滿足用戶友好性的要求。對於開發人員來說，處理存儲值偶爾重置為零的邊緣情況也會變得困難。如果在整個合約範圍內設置到期計時器，雖然在技術上簡化了開發人員的工作，但在經濟上卻變得更加棘手：開發人員必須考慮如何將持續的存儲成本「轉嫁」給用戶。

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

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

部分狀態到期

部分狀態到期提案都遵循相同的原則。我們將狀態分成塊。每個人都永久存儲“頂層映射”，其中塊為空或非空。數據 之內 僅當最近訪問過該數據時才存儲每個塊。有一種“復活”機制，如果不再存儲某個塊，任何人都可以通過提供數據內容的證明來恢復該數據。

這些提案的主要區別在於：（i）如何定義”最近”，以及（ii）如何定義”大數據塊”。一個具體的提案是EIP-7736，它基於為 Verkle 樹引入的“莖葉”設計（儘管與任何形式的無狀態樹兼容，如二叉樹）。在這種設計中，相鄰的頭部、代碼和存儲槽存儲在同一個”莖”下。”莖”下存儲的數據最多為 7936 字節（256 * 31）。通常，一個賬戶的整個頭部、代碼以及多個關鍵存儲槽都會存儲在同一個”莖”下。如果某個”莖”下的數據在 6 個月內未被讀取或寫入，該數據將不再存儲，而只保留一個 32 字節的承諾（”存根”）。未來訪問這些數據的交易需要”復活”數據，並提供基於”存根”驗證的證明。

還有其他實現類似想法的方法。例如，如果賬戶級別的粒度不夠精細，我們可以設計一個方案，將”樹”的每個”2^-32”部分都用類似的”莖和葉”機制來管理。

由於激勵因素，這變得更加棘手：攻擊者可以通過將大量數據放入單個子樹並每年發送單個交易來“更新樹”，從而迫使客戶端永久存儲大量狀態。如果您使更新成本與樹大小成正比（或更新持續時間成反比），那麼有人可能會通過將大量數據放入與他們相同的子樹中來傷害其他用戶。人們可以嘗試通過根據子樹大小動態調整粒度來限制這兩個問題：例如，每個連續的 216 = 65536 個狀態對象可以被視為一個“組”。然而，這些想法更為複雜；基於“莖”的方法很簡單，並且可以調整激勵措施，因為通常“莖”下的所有數據都與同一應用程序或用戶相關。

基於地址週期的狀態到期建議

如果我們想完全避免任何永久性的狀態增長，甚至是 32 字節的「存根」，該怎麼辦？這是一個棘手的問題，主要是因為復活衝突（Resurrection Conflicts）。設想這樣一個場景：一個狀態對象被刪除後，EVM 執行將另一個狀態對象放在相同位置。然而，之後有人想恢復原始狀態對象，我們該如何處理？在部分狀態到期的情況下，「存根」可以阻止創建新數據。但在完全狀態到期時，我們連「存根」都無法存儲。

基於地址週期的設計是解決此問題的最佳方法。我們不再使用單一狀態樹存儲整個狀態，而是維護一個不斷增長的狀態樹列表。任何讀取或寫入的狀態都會保存在最新的狀態樹中。每個週期（比如：1 年）都會添加一個新的空狀態樹。舊狀態樹保持不變。完整節點只需存儲最近的兩棵狀態樹。如果一個狀態對象在兩個週期內未被訪問，從而落入過期狀態樹，它仍然可以被讀取或寫入。但這時交易需要提供該對象的 Merkle 證明。一旦證明有效，該對象的副本將再次保存在最新的狀態樹中。

地址週期的概念是使這一切對用戶和開發人員都友好的關鍵思想。地址週期是地址中的一個數字部分。核心規則是：地址週期為 N 的地址只能在週期 N 或之後（即當狀態樹列表達到長度 N 時）被讀取或寫入。當用戶需要保存新的狀態對象（如新合約或新的 ERC20 餘額）時，只要確保將狀態對象放入地址週期為 N 或 N-1 的合約中，就可以立即保存，無需提供證明之前不存在任何內容。然而，對舊地址週期中的狀態進行任何添加或編輯都需要提供證明。

這種設計保留了以太坊當前的大部分屬性，不需要額外的計算，允許幾乎像現在一樣編寫應用程序（ERC20 需要重寫，以確保地址週期為 N 的地址餘額存儲在本身具有地址週期為 N 的子合約中)，解決了“用戶進山洞五年”的問題。然而，它有一個大問題： 地址需要擴展到 20 個字節以上才能適應地址週期。

地址空間擴展

一項建議是引入一種新的 32 字節地址格式，其中包括版本號、地址週期號和擴展散列。

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

紅色的是版本號。這裡橙色的四個零旨在作為空白空間，將來可以容納分片編號。綠色是地址週期數。藍色是 26 字節的哈希值。

這裡的關鍵挑戰是向後兼容性。現有合約是圍繞 20 字節地址設計的，並且通常使用嚴格的字節打包技術，明確假設地址正好是 20 字節長。 解決這個問題的一個想法是使用一個轉換映射，其中與新式地址交互的舊式合約將看到新式地址的 20 字節哈希。然而，要確保這一點的安全性，存在著很大的複雜性。

地址空間收縮

另一種方法則相反：我們立即禁止某些 2128- 大小的地址子範圍（例如，以 0xffffffff 0xffffffff），然後使用該範圍引入帶有地址週期和 14 字節哈希值的地址。

0xfffffff000169125d5dFcb7B8C2659029395bdF

這種方法做出的主要犧牲是，它為反事實地址引入了安全風險：持有資產或權限，但代碼尚未發佈到鏈上的地址。風險涉及有人創建一個地址，該地址聲稱擁有一段（尚未發佈）代碼，但也有另一段有效的代碼散列到同一地址。計算這樣的碰撞目前需要2⁸⁰個哈希值；地址空間收縮會將這個數字減少到易於訪問的 2⁵⁶ 個哈希值。

關鍵風險領域是反事實地址，這些地址不由單個所有者持有。雖然這種情況在當前相對罕見，但隨著我們進入多 L2 世界，它可能變得更加普遍。解決這個問題的唯一方法是接受這種風險，同時識別所有可能出現問題的常見用例，併為它們制定有效的緩解策略。

與現有研究有哪些聯繫？

• 早期提案
  • 區塊鏈租金： https://github.com/ethereum/EIPs/issues/35
  • 再生（ReGenesis）： https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• 以太坊狀態大小管理的理論： https://hackmd.io/
• 導致無狀態和狀態過期的幾種可能途徑： https://hackmd.io/
• 部分狀態到期提案
  • EIP-7736： https://eips.ethereum.org/EIPS/eip-7736
• 地址空間擴展文件
  • 原提案： https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Ipsilon 評論： https://notes.ethereum.org/
  • 博客文章評論： https://medium.com/
• 如果我們失去抗碰撞性會發生什麼： https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

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

我認為未來有四種可行的道路：

• 我們實行無狀態，並且不引入狀態到期。狀態在不斷增長（儘管增長緩慢：幾十年內我們可能不會看到它超過 8 TB），但只需要由相對專業的用戶類別持有：甚至 PoS 驗證器也不需要狀態。

包含列表生成是需要訪問部分狀態的一項功能，但我們可以通過去中心化的方式實現：每個用戶負責維護狀態樹中包含自己賬戶的部分。用戶廣播交易時，會同時廣播驗證步驟中所訪問狀態對象的證明（適用於 EOA 和 ERC-4337 賬戶）。無狀態驗證器隨後可以將這些證明組合，生成完整的包含列表證明。

• 我們實施部分狀態到期，並接受一個低得多但仍然非零的永久狀態規模增長率。這一結果可以說類似於涉及對等網絡的歷史到期提案——如何接受一個低得多但仍然非零的永久歷史存儲增長率，因為每個客戶端必須存儲一個較低但固定百分比的歷史數據。
• 我們使用地址空間擴展來進行狀態到期。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括現有應用程序。
• 我們使用地址空間收縮來進行狀態到期。這將涉及一個多年的過程，以確保所有涉及地址衝突的安全風險（包括跨鏈情況）都得到處理。

重要的一點是，無論是否實施依賴於地址格式更改的狀態到期方案，最終都必須解決有關地址空間擴展和收縮的難題。今天，大約需要 2⁸⁰ 哈希值來生成地址衝突，對於資源極其豐富的參與者來說，這種計算負載已經是可行的：GPU 可以進行大約 2²⁷ 哈希值運算，因此運行一年可以計算 2⁵² 次，因此世界上所有約“2 的 30 次方”個 GPU 都可以在 約 1/4 年的時間內計算一次碰撞，而 FPGA 和 ASIC 可以進一步加速這一過程。在未來，此類攻擊將會向越來越多的人開放。因此，實現完全狀態到期的實際成本可能沒有看起來那麼高，因為無論如何我們都必須解決這個非常具有挑戰性的地址問題。

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

進行狀態過期可能會使從一種狀態樹格式到另一種狀態樹格式的轉換變得更容易，因為不需要轉換過程：您可以簡單地開始使用新格式創建新樹，然後執行硬分叉來轉換舊樹。因此，雖然狀態到期很複雜，但它確實有利於簡化路線圖的其他方面。

功能清理（Feature cleanup）

它解決什麼問題？

安全性、可訪問性和可用性的關鍵先決條件之一 可信的中立性 是簡單。如果協議美觀且簡單，就會減少出現錯誤的可能性。它增加了新開發人員能夠參與其中的任何部分的機會。它更有可能是公平的，也更容易抵禦特殊利益。不幸的是，協議就像任何社交系統一樣，默認情況下會隨著時間的推移而變得更加複雜。如果我們不希望以太坊陷入日益複雜的黑洞，我們需要做以下兩件事之一：（i）停止進行更改並使協議僵化， (ii) 能夠實際刪除功能並降低複雜性。一種中間路線，即對協議進行較少的更改，並且隨著時間的推移至少消除一點複雜性，這也是可能的做到的。本節將討論如何減少或消除複雜性。

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

沒有任何重大的單一修復可以降低協議的複雜性；這個問題的本質是有許多小的解決辦法。

一個基本已經完成的示例是刪除 SELFDESTRUCT 操作碼。 SELFDESTRUCT 操作碼是唯一可以修改單個塊內無限數量存儲槽的操作碼，要求客戶端實現顯著更高的複雜性以避免 DoS 攻擊。該操作碼的最初目的是實現自願狀態清算，從而允許狀態大小隨著時間的推移而減小。實際上，很少有人最終使用它。在 Dencun 硬分叉中，該操作碼被削弱為僅允許在同一交易中創建的自毀賬戶。這解決了 DoS 問題，並允許顯著簡化客戶端代碼。 未來，最終完全刪除該操作碼可能是有意義的。

迄今為止，已確定了一些關鍵的協議簡化機會。首先，讓我們看看 EVM 之外的例子。這些變更相對非侵入性，因此更容易達成共識並在短期內實施。

• RLP → SSZ 轉變：最初，以太坊使用一種稱為 RLP的編碼進行序列化。 RLP 是無類型的，而且沒有必要那麼複雜。如今，信標鏈使用 SSZ, 它在很多方面都明顯更好，包括不僅支持序列化，還支持哈希。最終，我們希望完全擺脫 RLP，並將所有數據類型轉移到 SSZ 結構中，這反過來會使升級變得更加容易。為此提出的當前 EIP 包括 [1] [2] [3]。
• 刪除舊的交易類型：當今的交易類型太多，其中許多可能會被刪除。完全刪除的一個更溫和的替代方案是帳戶抽象功能，智能帳戶可以通過該功能包含處理和驗證舊式交易的代碼（如果他們願意的話）。
• 日誌（LOG）改革：日誌創建了 Bloom 過濾器和其他邏輯，增加了協議的複雜性，但實際上並沒有被客戶端使用，因為它太慢了。我們可以 刪除這些功能，而是將精力投入替代方案，例如使用 SNARK 等現代技術的協議外去中心化日誌讀取工具。
• 最終取消信標鏈同步委員會機制：同步委員會機制最初是為了實現以太坊的輕客戶端驗證而引入的。然而，它增加了協議的複雜性。最終，我們將能夠使用 SNARK 直接驗證以太坊共識層，這將消除對專用輕客戶端驗證協議的需求。通過創建更「原生」的輕客戶端協議（涉及驗證來自以太坊共識驗證器隨機子集的簽名），或許共識的改變可以使我們更早地取消同步委員會。
• 數據格式統一：目前，執行狀態存儲在 Merkle Patricia 樹中，共識狀態存儲在 SSZ 樹中，而 Blob 則通過 KZG 承諾進行承諾。未來，為區塊數據和狀態創建單一的統一格式是有意義的。這些格式將滿足所有重要需求：（i）無狀態客戶端的簡單證明，（ii）數據的序列化和擦除編碼，（iii）標準化數據結構。
• 取消信標鏈委員會：該機制最初是為了支持特定版本的執行分片而引入的。相反，我們最終通過 L2 和 blob 進行分片。因此，委員會是不必要的，我們正在進行取消委員會的行動。
• 刪除混合字節序：EVM 是大字節序，而共識層是小字節序。重新協調並使所有內容都採用大字節序或小字節序可能是有意義的（可能是大字節序，因為 EVM 更難更改）。

以下是 目前 EVM 中的一些示例：

• 簡化 Gas 機制：當前的 Gas 規則未能充分優化，無法準確限制驗證區塊所需的資源量。主要問題包括：（i）存儲讀/寫成本，雖然旨在限制區塊中的讀/寫次數，但目前設定較為隨意；（ii）內存填充規則，使 EVM 的最大內存消耗難以估算。為解決這些問題，建議採取以下措施：實施無狀態 Gas 成本變化，將所有存儲相關成本統一為一個簡單公式；同時引入新的內存定價提案。
• 刪除預編譯：以太坊今天擁有的許多預編譯都不必要地複雜且相對未使用，並且在幾乎沒有被任何應用程序使用的情況下構成了共識失敗的很大一部分。處理這個問題的兩種方法是（i）僅刪除預編譯，以及（ii）用實現相同邏輯的（不可避免地更昂貴的）EVM 代碼片段替換它。此 EIP 草案提議首先對身份預編譯執行此操作；隨後，RIPEMD160、MODEXP 和 BLAKE 可能會被移除。
• 取消 Gas 可觀察性：使 EVM 執行不再能夠看到剩餘的 Gas 量。這將破壞一些應用程序（最明顯的是贊助交易），但將使未來升級更加容易（例如，升級到更高級的多維 Gas 版本）。EOF 規範 已經使 Gas 變得不可觀察，但為了簡化協議，EOF 需要成為強制性的。
• 靜態分析的改進：如今 EVM 代碼很難進行靜態分析，特別是因為跳轉可能是動態的。這也使得優化 EVM 實現（將 EVM 代碼預編譯為其他語言）變得更加困難。我們可以通過刪除動態跳轉（或使其更加昂貴，例如，Gas 成本與合約中 JUMPDEST 的總數成線性關係）來解決這個問題。EOF 可以做到這一點，但要從中獲得協議簡化的好處，則需要強制執行 EOF。

與現有研究有哪些聯繫？

• 淨化的後續步驟： https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• SELFDESTRUCT（自毀）： https://hackmd.io/
• SSZ 化 EIPS： [1] [2] [3]
• 無狀態 Gas 成本變化： https://eips.ethereum.org/EIPS/eip-4762
• 線性內存定價： https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• 預編譯刪除： https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Bloom 過濾器移除： https://eips.ethereum.org/EIPS/eip-7668
• 一種使用增量可驗證計算進行鏈下安全日誌檢索的方法（閱讀：遞歸 STARK）： https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

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

進行此類功能簡化的主要權衡在於（i）我們簡化的程度和速度與（ii）向後兼容性之間的平衡。以太坊作為一條鏈的價值源於它是一個平臺，用戶可以在其中部署應用程序，並確信這些應用在多年後仍能正常運行。然而，這種理想也可能被過分強調。借用William Jennings Bryan 的話，我們不應”將以太坊釘在向後兼容性的十字架上”。設想一個場景：如果整個以太坊生態系統中只有兩個應用程序在使用某個特定功能，其中一個多年來沒有用戶，幾乎完全閒置，而且這兩個應用的總價值僅為 57 美元。在這種情況下，我們應該考慮刪除該功能，必要時甚至可以自掏腰包向受影響的用戶補償這 57 美元。

更廣泛的社會問題在於創建一個標準化的管道來進行非緊急的向後兼容性破壞的更改。解決這個問題的一種方法是檢查和擴展現有的先例，例如自毀過程。該流程看起來如下：

• 步驟一： 開始討論刪除功能 X
• 步驟2： 進行分析以確定移除 X 對應用程序造成的影響，根據結果：（i） 放棄這個想法，（ii）按計劃進行，或（iii）找到一種修改後的「破壞性最小」的方法來移除 X，並繼續進行
• 步驟3： 制定正式的EIP來棄用 X。確保流行的高級基礎設施（例如編程語言、錢包）尊重這一點並停止使用該功能。
• 第四步：最後， 實際刪除 X

在第 1 步和第 4 步之間應該有一個持續數年的流程，並明確標識每個項目所處的步驟。此時，我們需要權衡”功能移除流程的力度和速度”與”採取更保守的方法並將更多資源投入協議開發的其他領域”。儘管如此，我們距離”帕累託前沿（Pareto frontier）”還有相當長的距離。

EOF

對 EVM 提出的一系列主要更改是 EVM 對象格式 (EOF)。 EOF引入了大量的改變，例如禁止gas可觀察性、代碼可觀察性（即無CODECOPY）、僅允許靜態跳轉。目標是允許 EVM 以具有更強屬性的方式進行更多升級，同時保持向後兼容性（因為 EOF 之前的 EVM 仍然存在）。

這樣做的優點是，它創建了一條添加新 EVM 功能的自然路徑，並鼓勵遷移到具有更強保證的更嚴格的 EVM。它的缺點是它顯著 增加 協議複雜性，除非我們能找到一種方法最終棄用並刪除舊的 EVM。一個主要問題是： EOF 在 EVM 簡化提案中發揮什麼作用，特別是如果目標是降低整個 EVM 的複雜性？

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

路線圖其餘部分中的許多“改進”建議也是對舊功能進行簡化的機會。重複上面的一些例子：

• 切換到單槽最終性使我們有機會取消委員會、重新設計經濟學並進行其他與權益證明相關的簡化。
• 完全實現賬戶抽象可以讓我們刪除大量現有的交易處理邏輯，將其移至所有 EOA 都可以替換的“默認賬戶 EVM 代碼”中。
• 如果我們將以太坊狀態轉移到二進制哈希樹，這可以與新版本的 SSZ 協調一致，以便所有以太坊數據結構都可以以相同的方式進行哈希處理。

更激進的方法：將協議的大部分內容轉化為合約代碼

一個更激進的以太坊簡化策略是保持協議不變，但將其大部分從協議功能轉移到合約代碼。

最激進的方案是將以太坊 L1 “技術上”簡化為信標鏈，並引入一個精簡的虛擬機（VM）。這可以是RISC-V、Cairo，或專為證明系統設計的更簡單 VM。這種設計將允許開發者創建自己的 Rollup，而 EVM 將成為這些 Rollups 中的首個實例。有趣的是，這一方案與2019-20 年提出的執行環境方案殊途同歸，儘管 SNARK 技術的進步使得這一設想更易實現。

一種更溫和的方法是，保持信標鏈和當前以太坊執行環境之間的關係不變，但對 EVM 進行就地交換。我們可以選擇 RISC-V、Cairo 或其他 VM 作為新的“官方以太坊 VM”，然後將所有 EVM 合約強制轉換為解釋原始代碼邏輯的新 VM 代碼（通過編譯或解釋）。理論上來說，甚至可以將這個”目標 VM”作為 EOF 的一個版本來實現。

免責聲明：

1. 本文轉載自【Vitalik Buterin】，所有版權歸原作者所有【Vitalik Buterin】。若對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。