原文標題：《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
解決什麼問題？
截至撰寫本文時，完全同步的以太坊節點需要大約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 中。
與現有研究有哪些關聯？
還需要做什麼，需要權衡什麼？
剩下的主要工作包括建構和整合一個具體的分散式解決方案來儲存歷史記錄——至少是執行歷史記錄，但最終還包括共識和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 位元組位址格式，其中包括版本號、位址週期號和擴展雜湊。
0x 01 （紅色） 0000 （橘色） 000001 （綠色） 57 aE 408398 dF 7 E 5 f 4552091 A 69125 d5 dFcb 7 B 8 C 2659029395 bdF（藍色）。
紅色的是版本號。這裡橙色的四個零旨在作為空白空間，將來可以容納分片編號。綠色是地址週期號。藍色是26 位元組的雜湊值。
這裡的關鍵挑戰是向後相容性。現有合約是圍繞著20 位元組位址設計的，並且通常使用嚴格的位元組打包技術，明確假設位址正好是20 位元組長。解決這個問題的一個想法涉及轉換映射，其中與新式位址互動的舊式合約將看到新式位址的20 位元組雜湊值。然而，確保其安全性存在很大的複雜性。
地址空間收縮
另一種方法採取相反的方向：我們立即禁止一些2 128 大小的位址子範圍（例如，所有以0x ffffffff 開頭的位址），然後使用該範圍引入具有位址週期和14 位元組雜湊值的位址。
0x ffffffff 000169125 d5 dFcb 7 B 8 C2659029395bdF
這種方法做出的主要犧牲是引入了反事實地址的安全風險：持有資產或權限的地址，但其程式碼尚未發佈到鏈上。風險涉及有人創建一個地址，該地址聲稱擁有一段（尚未發布）代碼，但也有另一段有效的代碼散列到同一地址。今天計算這樣的碰撞需要2 80 個哈希；位址空間收縮會將這個數字減少到易於存取的2 56 個哈希值。
關鍵風險領域，即非單一所有者持有的錢包的反事實地址，在今天相對罕見，但隨著我們進入多L2 世界，可能會變得更加常見。唯一的解決方案是簡單地接受這種風險，但要確定可能出現問題的所有常見用例，並提出有效的解決方法。
與現有研究有哪些關聯？
早期提案
部分狀態到期提案
EIP-7736 ；
地址空間擴充文檔
還需要做什麼，需要權衡什麼？
我認為未來有四種可行的道路：
我們做到無狀態，從不引入狀態過期。狀態正在不斷增長（儘管緩慢：我們可能看不到它超過8 TB 數十年），但只需要由相對特殊類別的用戶：甚至PoS 驗證器也不需要狀態。
需要存取部分狀態的一個功能是包含清單生成，但我們可以以分散的方式完成此操作：每個使用者負責維護狀態樹中包含其自己帳戶的部分。當他們廣播交易時，他們會廣播交易並附帶驗證步驟期間存取的狀態物件的證明（這適用於EOA 和ERC-4337 帳戶）。然後，無狀態驗證器可以將這些證明組合成整個包含清單的證明。我們進行部分狀態到期，並接受一個低得多但仍然非零的永久狀態大小增長率。這個結果可以說類似於涉及對等網路的歷史過期提案如何接受每個客戶端必須儲存較低但固定百分比的歷史資料的低得多但仍然非零的永久歷史儲存成長率。
我們透過地址空間擴展來進行狀態過期。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括現有應用程式。
我們透過地址空間收縮來進行狀態過期。這將涉及一個多年的過程，以確保所有涉及地址衝突的安全風險（包括跨鏈情況）都得到處理。
重要的一點是，無論是否實施依賴於位址格式變更的狀態到期方案，最終都必須解決有關位址空間擴展和收縮的難題。如今，生成位址衝突大約需要2 80 個哈希值，對於資源極其豐富的參與者來說，這種計算負載已經是可行的：GPU 可以執行大約2 27 個哈希值，因此運行一年可以計算2 52 ，因此所有世界上約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 改革：日誌建立布隆過濾器和其他邏輯，增加了協議的複雜性，但實際上並沒有被客戶端使用，因為它太慢了。我們可以刪除這些功能，轉而致力於替代方案，例如使用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 草案建議第一步對身分預編譯執行此操作；稍後，RIPEMD 160、MODEXP 和BLAKE 可能會成為刪除的候選者。
去除 gas 可觀察性：使 EVM 執行不再能夠看到它還剩下多少 gas。這會破壞一些應用程式（最明顯的是贊助交易），但將來會更容易升級（例如，對於多維氣體的更高級版本）。 EOF 規範已經使Gas 變得不可觀測，但為了簡化協議，EOF 需要成為強制性的。
靜態分析的改進：如今EVM 程式碼很難進行靜態分析，特別是因為跳轉可能是動態的。這也使得優化EVM 實作（將EVM 程式碼預先編譯為其他語言）變得更加困難。我們可以透過刪除動態跳躍來解決這個問題（或使它們變得更加昂貴，例如，合約中JUMPDEST 總數的Gas 成本呈線性）。 EOF 就是這樣做的，儘管要從中獲得協議簡化收益需要強制執行EOF。
與現有研究有哪些關聯？
一種使用增量可驗證計算進行鏈下安全日誌檢索的方法（閱讀：遞歸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 的一個版本來完成。
