作者：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、ERC20、NFT、CDP 頭寸的訪問權……

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

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

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

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

Partial state expiry部分狀態到期

部分狀態到期提案都遵循相同的原則。我們將狀態分成塊。每個人都永久存儲“頂級映射”，其中塊為空或非空。僅當最近訪問過該數據時才會存儲每個塊中的數據。有一種“復活”機制，如果不再存儲

這些提案之間的主要區別是：（i）我們如何定義“最近”，以及（ii）我們如何定義“塊”？一個具體的提案是EIP-7736，它建立在為 Verkle 樹引入的“莖葉”設計之上（儘管與任何形式的無狀態狀態兼容，例如二叉樹）。在這種設計中，彼此相鄰的標頭、代碼和存儲槽存儲在同一個“主幹”下。一個莖下存儲的數據最多可以是256 * 31 = 7,936字節。在許多情況下，帳戶的整個標頭和代碼以及許多密鑰存儲槽都將存儲在同一個主幹下。如果給定主幹下的數據在 6 個月內沒有被讀取或寫入，則不再存儲該數據，而是僅存儲該數據的 32 字節承諾（“存根”）。未來訪問該數據的交易將需要“復活”數據，並提供根據存根進行檢查的證明。

還有其他方法可以實現類似的想法。例如，如果帳戶級別的粒度不夠，我們可以制定一個方案，其中樹的每個 1/232部分都由類似的莖葉機制控制。

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

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

如果我們想完全避免任何永久狀態增長，甚至是 32 字節存根，該怎麼辦？由於復活衝突，這是一個難題：如果一個狀態對象被刪除，稍後 EVM 執行會將另一個狀態對象置於完全相同的位置，但之後關心原始狀態對象的人回來並嘗試恢復它，該怎麼辦？當部分狀態到期時，“存根”會阻止創建新數據。隨著狀態完全到期，我們甚至無法存儲存根。

基於地址週期的設計是解決這個問題的最著名的想法。我們不是用一棵狀態樹存儲整個狀態，而是有一個不斷增長的狀態樹列表，並且任何讀取或寫入的狀態都會保存在最新的狀態樹中。每個時期（例如：1 年）添加一次新的空狀態樹。老樹都凍得嚴嚴實實的。完整節點僅存儲最近的兩棵樹。如果一個狀態對象在兩個週期內沒有被觸及，從而落入過期樹中，它仍然可以被讀取或寫入，但交易需要證明它的 Merkle 證明 - 一旦證明，就會保存一個副本再次在最新的樹中。

使這對用戶和開發人員都友好的一個關鍵思想是地址週期的概念。地址週期是屬於地址一部分的數字。關鍵規則是具有地址週期N的地址只能在週期N期間或之後（即，當狀態樹列表達到長度N時）被讀取或寫入。如果你要保存一個新的狀態對象（例如，一個新的合約，或者一個新的ERC20餘額），如果你確保將狀態對象放入地址週期為N或N-1的合約中，那麼你可以保存立即進行，無需提供證據證明之前什麼都沒有。另一方面，在舊地址期間進行的任何添加或編輯都需要證明。

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

Address space extension地址空間擴展

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

0x01（紅色）0000（橙色）000001（綠色）57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF（藍色）。

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

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

地址空間收縮

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

0xffffffff000169125d5dFcb7B8C2659029395bdF

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

關鍵風險領域，即非單一所有者持有的錢包的反事實地址，在今天相對罕見，但隨著我們進入多 L2 世界，可能會變得更加常見。唯一的解決方案是簡單地接受這種風險，但要確定可能出現問題的所有常見用例，並提出有效的解決方法。

與現有研究有哪些聯繫？

早期提案

• 區塊鏈清潔；
• 再生；
• 以太坊狀態大小管理理論；
• 無狀態和狀態過期的一些可能路徑；

部分狀態到期提案

• EIP-7736；

地址空間擴展文檔

• 原始提案；
• Ipsilon 評論；
• 博客文章評論；
• 如果我們失去碰撞抵抗力會破壞什麼。

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

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

• 我們做到無狀態，並且從不引入狀態過期。狀態正在不斷增長（儘管緩慢：我們可能看不到它 超過 8 TB 數十年），但只需要由相對 特殊類別的用戶：甚至 PoS 驗證器也不需要 狀態。需要訪問部分狀態的一個功能是包含列表生成，但我們可以以分散的方式完成此操作：每個用戶負責維護狀態樹中包含其自己帳戶的部分。當他們廣播交易時，他們會廣播交易並附帶驗證步驟期間訪問的狀態對象的證明（這適用於 EOA 和 ERC-4337 帳戶）。然後，無狀態驗證器可以將這些證明組合成整個包含列表的證明。
• 我們進行部分狀態到期，並接受一個低得多但仍然非零的永久狀態大小增長率。這個結果可以說類似於涉及對等網絡的歷史過期提案如何接受每個客戶端必須存儲較低但固定百分比的歷史數據的低得多但仍然非零的永久歷史存儲增長率。
• 我們通過地址空間擴展來進行狀態過期。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括現有應用程序。
• 我們通過地址空間收縮來進行狀態過期。這將涉及一個多年的過程，以確保所有涉及地址衝突的安全風險（包括跨鏈情況）都得到處理。

重要的一點是，無論是否實施依賴於地址格式更改的狀態到期方案，最終都必須解決有關地址空間擴展和收縮的難題。如今，生成地址衝突大約需要 280 個哈希值，對於資源極其豐富的參與者來說，這種計算負載已經是可行的：GPU 可以執行大約 227 個哈希值，因此運行一年可以計算 252，因此所有世界上約 230 個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]。

刪除舊的交易類型：當今的交易類型太多，其中許多可能會被刪除。完全刪除的一個更溫和的替代方案是帳戶抽象功能，智能帳戶可以通過該功能包含處理和驗證舊式交易的代碼（如果他們願意的話）。

LOG 改革：日誌創建布隆過濾器和其他邏輯，增加了協議的複雜性，但實際上並沒有被客戶端使用，因為它太慢了。我們可以刪除這些功能，轉而致力於替代方案，例如使用 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。這會破壞一些應用程序（最明顯的是贊助交易），但將來會更容易升級（例如，對於多維氣體的更高級版本）。EOF 規範已經使 Gas 變得不可觀測，但為了簡化協議，EOF 需要成為強制性的。

靜態分析的改進：如今 EVM 代碼很難進行靜態分析，特別是因為跳轉可能是動態的。這也使得優化 EVM 實現（將 EVM 代碼預編譯為其他語言）變得更加困難。我們可以通過刪除動態跳躍來解決這個問題（或者使它們變得更加昂貴，例如，合約中 JUMPDEST 總數的 Gas 成本呈線性）。 EOF 就是這樣做的，儘管要從中獲得協議簡化收益需要強制執行 EOF。

與現有研究有哪些聯繫？

• 清除的後續步驟；
• 自毀
• SSZ 化 EIPS：[1][2]；
• 無狀態gas成本變化；
• 線性內存定價；
• 預編譯刪除；
• 布隆過濾器移除；
• 一種使用增量可驗證計算進行鏈下安全日誌檢索的方法（閱讀：遞歸 STARK）；

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

進行這種功能簡化的主要權衡是（i）我們簡化的程度和速度與（ii）向後兼容性。以太坊作為一條鏈的價值來自於它是一個平臺，您可以在其中部署應用程序，並確信它在多年後仍然可以工作。與此同時，這種理想也可能走得太遠，用 William Jennings Bryan 的話來說，“將以太坊釘在向後兼容性的十字架上”。如果整個以太坊中只有兩個應用程序使用給定的功能，並且一個應用程序多年來一直擁有零用戶，而另一個應用程序幾乎完全未使用並獲得了總共 57 美元的價值，那麼我們應該刪除該功能，並且如果需要自掏腰包向受害者支付 57 美元。

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

• 開始談論刪除功能 X；
• 進行分析，確定刪除 X 對應用程序造成的影響，具體取決於結果：(i) 放棄該想法，(ii) 按計劃繼續，或 (iii) 確定修改後的“破壞性最小”的方法來刪除 X 和繼續；
• 制定正式的 EIP 來棄用X。確保流行的更高級別基礎設施（例如編程語言、錢包）尊重這一點並停止使用該功能。；
• 最後，實際刪除X；
• 第 1 步和第 4 步之間應該有一個長達多年的管道，並明確說明哪些項目處於哪個步驟。在這一點上，需要在特徵刪除流程的活力和速度與更加保守和將更多資源投入到協議開發的其他領域之間進行權衡，但我們距離帕累託邊界還很遠。

EOF

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

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

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

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

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

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

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

最極端的版本是讓以太坊 L1 “技術上”只是信標鏈，並引入一個最小的虛擬機（例如RISC-V、Cairo或更最小的專門用於證明系統），允許其他人創建自己的彙總。然後，EVM 將變成這些彙總中的第一個。具有諷刺意味的是，這與2019-20 年執行環境提案的結果完全相同，儘管 SNARK 使其實際實施起來更加可行。

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