撰文：Vitalik Buterin
編譯：Glendon，Techub News
以太坊面臨的挑戰之一是，預設情況下，任何區塊鏈協議的膨脹和複雜性都會隨著時間的推移而增長。這發生在兩個地方：
歷史資料：歷史上任何時間點進行的任何交易和創建的任何帳戶都需要由所有客戶端永久存儲，並由任何新客戶端下載以完全同步到網路。這會導致客戶端負載和同步時間隨著時間的推移而不斷增加，即使鏈的容量保持不變。
協定特性：新增功能比刪除舊功能要容易得多，這導致程式碼複雜度隨著時間的推移而增加。
為了讓以太坊能夠長期維持下去，我們需要對這兩種趨勢施加強大的反壓力，隨著時間的推移降低複雜性和膨脹。但同時，我們需要保留使區塊鏈變得的重要特性之一：永久性（Permanence） 。你可以把一個NFT、一封交易調用資料（Transaction Calldata）中的情書或是一份包含一百萬美元的智能合約放在鏈上，然後進入一個山洞十年，出來後會發現它仍然在那裡等著你閱讀和互動。對於DApp 而言，要完全去中心化並刪除升級金鑰，它們需要確信其依賴項不會以破壞它們的方式升級——尤其是Layer 1 本身。
The Purge，2023 年路線圖
平衡這兩種需求，並在保持連續性的同時最小化或扭轉膨脹、複雜性和衰退，如果我們用心去做，這是完全可能的。生物體可以做到這一點：雖然大多數生物會隨著時間的流逝而衰老，但少數幸運兒卻不會。即使是社會系統也可以擁有極長的壽命。在某些情況下，以太坊已經取得了成功：工作量證明消失了，SELFDESTRUCT 操作碼基本上消失了，信標鏈節點已經儲存了最多六個月的舊資料。以更通用的方式為以太坊找出這條道路，並朝著長期穩定的最終結果前進，是以太坊長期可擴展性、技術永續性甚至安全性的終極挑戰。
The Purge：關鍵目標
透過減少或消除每個節點永久儲存所有歷史記錄甚至最終狀態的需要來降低客戶端儲存要求。
透過消除不需要的功能來降低協定複雜性。
歷史記錄到期（History expiry）
解決了什麼問題？
截至撰寫本文時，完全同步的以太坊節點需要大約1.1 TB的磁碟空間來執行客戶端，另外還需要數百GB 的磁碟空間用於共識客戶端。其中絕大部分是歷史記錄：有關歷史區塊、交易和收據的數據，其中大部分是多年前的數據。這意味著即使Gas 限制根本沒有增加，節點的大小每年也會增加數百GB。
它是什麼，它是如何運作的？
歷史儲存問題的一個關鍵簡化特證是，由於每個區塊都透過哈希連結（和其他結構）指向前一個區塊，因此對當前達成共識就足以對歷史達成共識。只要網路對最新區塊達成共識，任何歷史區塊或交易或狀態（帳戶餘額、隨機數、代碼、儲存）都可以由任何單一參與者提供，並附帶Merkle 證明，而該證明允許其他任何人驗證其正確性。雖然共識是N/2-of-N 信任模型，但歷史是1-of-N 信任模型。
這為我們儲存歷史資料的方式提供了許多選擇。一個自然的選擇是每個節點僅儲存一小部分資料的網路。這就是Torrent 網路幾十年來的運作方式：雖然網路總共儲存和分發數百萬個文件，但每個參與者只儲存和分發其中的幾個文件。也許與直覺相反，這種方法甚至不一定會降低數據的穩健性。如果透過讓節點運行更便宜，我們可以獲得一個擁有10 萬個節點的網絡，其中每個節點存儲隨機10% 的歷史記錄，那麼每條數據都會被複製10000 次——這與10000 個節點網絡的複製因子完全相同，每個節點儲存所有內容。
如今，以太坊已經開始擺脫所有節點永久儲存所有歷史記錄的模式。共識區塊（即與權益證明共識相關的部分）僅儲存約6 個月。 Blob 僅儲存約18 天。 EIP-4444旨在為歷史區塊和收據引入一年的儲存期。長期目標是有一個協調的時期（可能是約18 天），在此期間每個節點負責儲存所有內容，然後建立一個由以太坊節點組成的對等網絡，以分散式方式儲存舊資料。 （Techub News 註，Blob 是一種資料儲存概念，旨在降低L2 擴充解決方案的交易成本。）
可以使用糾刪碼（Erasure Codes）來提高穩健性（Robustness，即穩健性），同時保持複製因子相同。事實上，為了支援資料可用性取樣，Blob 已經採用糾刪碼。最簡單的解決方案可能是重新使用這種糾刪碼，並將執行和共識區塊資料也放入Blob 中。
與現有研究有哪些關聯？
門戶網路（Portal network ）
還要做些什麼，需要權衡什麼？
剩下的主要工作涉及建構和整合一個具體的分散式解決方案來儲存歷史記錄——至少是執行歷史記錄，但最終也包括共識和Blob。對此，最簡單的解決方案是(i) 簡單地引入現有的torrent 函式庫，以及(ii) 一個名為「 Portal 網路」的以太坊原生解決方案。一旦引入其中任何一個，我們就可以啟用EIP-4444。 EIP-4444 本身不需要硬分叉，但它確實需要新的網路協定版本。因此，同時為所有客戶端啟用它是有價值的，否則將存在客戶端連接到其他節點時發生故障的風險，這些節點期望下載完整的歷史記錄，但實際上卻無法取得。
主要的權衡涉及我們如何努力使“古老的”歷史數據可用。最簡單的解決方案是明天停止儲存古老的歷史記錄，並依靠現有的存檔節點和各種集中式提供者進行複製。這很容易，但這削弱了以太坊作為永久記錄場所的地位。更困難但更安全的方法是先建置和整合torrent 網路以分散式方式儲存歷史記錄。這裡，「我們的努力程度」有兩個維度：
1.我們如何努力確保最大的節點集確實儲存了所有資料？
2.我們如何將歷史記錄儲存深度整合到協定中？
對於（1），一種最偏執的方法是使用託管證明：實際上要求每個權益證明驗證者儲存一定比例的歷史記錄，並定期透過加密方式檢查他們是否這樣做。較溫和的方法是為每個客戶端儲存的歷史記錄百分比設定一個自願標準。
對於（2），基本實作只涉及今天已經完成的工作：Portal 已經儲存了包含整個以太坊歷史的ERA 檔案。更徹底的實現，實際上需要將其連接到同步過程，這樣如果有人想要同步完整歷史記錄儲存節點或存檔節點，即使沒有其他存檔節點在線存在，他們也可以透過直接從Portal 網路同步來實現此操作。
它如何與路線圖的其他部分互動？
如果我們想讓節點運作或啟動變得極為容易，那麼減少歷史儲存需求可以說比無狀態性（Statelessness）更重要：在節點需要的1.1 TB 中，約300 GB 是狀態存儲，其餘約800 GB 是歷史儲存。只有在同時實現無狀態性和EIP-4444 的情況下，以太坊節點在智慧手錶上運行且只需幾分鐘即可設定的願景才能實現。
限制歷史儲存也使得較新的以太坊節點實現更易於僅支援協定的最新版本，從而使它們變得更加簡單。例如，由於2016 年DoS 攻擊期間建立的空白儲存槽已全部刪除，因此現在可以安全地刪除許多程式碼行。既然轉向權益證明已成為歷史，那麼客戶端可以安全地刪除所有與工作量證明相關的程式碼。
狀態到期（State expiry）
它解決了什麼問題？
即使我們消除了客戶端儲存歷史記錄的需求，客戶端的儲存需求仍將繼續成長，每年約50 GB，因為狀態持續成長：帳戶餘額和隨機數、合約程式碼和合約儲存。用戶可以支付一次性費用，永遠給現在和未來的以太坊客戶端帶來負擔。
狀態比歷史記錄更難“過期”，因為EVM 的設計從根本上圍繞著一個假設，即一旦創建了狀態對象，它將永遠存在，並且可以隨時被任何事務讀取。如果我們引入無狀態性，有人認為這個問題可能沒有那麼糟糕：只有一類專門的區塊建構器才需要實際儲存狀態，而所有其他節點（甚至包含清單產生）都可以無狀態運作。然而，有一種觀點認為，我們不想過度依賴無狀態性，最終我們可能希望讓狀態過期以保持以太坊的去中心化。
它是什麼，它是如何運作的？
現在，當你建立一個新的狀態物件時（這可以透過以下三種方式之一實現：（i）將ETH 傳送到新帳戶；（ii）使用程式碼建立新帳戶；（iii）設定先前未觸及的儲存槽），該狀態物件將永遠處於該狀態。相反，我們想要的是物件隨著時間的推移自動過期。要做到這一點，關鍵的挑戰是要實現以下三個目標：
1.效率：不需要大量額外的計算來運行到期過程；
2.使用者友善性：如果「有人進入洞穴五年後再回來」，他們不應該失去對其ETH、ERC20、NFT、CDP 部位的存取權。
3.開發人員友善性：開發人員不必切換到完全不熟悉的思維模型。此外，目前僵化且不更新的應用程式應該可以繼續正常運作。
在不滿足這些目標的情況下，問題很容易解決。例如，使用者可以讓每個狀態物件也儲存一個計數器來表示其到期日期（可以透過銷毀ETH 來延長過期日期，這可以在讀取或寫入時自動發生），並且有一個循環「遍歷狀態」以刪除過期狀態物件的過程。但是，這引入了額外的計算（甚至存儲需求），並且它肯定不能滿足用戶友好性的要求。開發人員也很難推理涉及儲存值有時會重置為零的邊緣情況。如果使用者在整個合約範圍內設定到期計時器，這在技術上使開發人員的工作變得更容易，但在經濟上卻變得更加困難：開發人員必須考慮如何將持續的儲存成本「轉嫁」給用戶。
這些都是以太坊核心開發社群多年來一直在努力解決的問題，包括「區塊鏈租金」和「 再生（Regenesis）」等提案。最終，我們結合了這些提案中最好的部分，並集中在兩類「已知最不糟糕的解決方案」：
部分狀態到期解決方案
基於地址週期的狀態到期建議。
部分狀態到期
部分狀態過期提案都遵循相同的原則。我們將狀態分成多個區塊。每個人都永久儲存「頂層映射（Top-Level Map）」，其中的塊為空或非空。每個區塊中的資料只有在最近被存取時才會被儲存。有一個「復活（Resurrection）」機制，如果某個區塊不再存儲，任何人都可以透過提供資料的證明來恢復該資料。
這些提案之間的主要區別在於：（i）我們如何定義「最近」，以及（ii）我們如何定義「大的資料區塊（Chunk）」？一個具體的提案是EIP-7736 ，它建立在為Verkle 樹引入的“莖和葉”設計之上（儘管與任何形式的無狀態樹兼容，例如二叉樹）。在這種設計中，彼此相鄰的標頭、代碼和儲存槽儲存在同一個「莖」下。儲存在「莖」下的資料最多為「256 * 31 = 7936 位元組」。在許多情況下，帳戶的整個標頭和代碼以及許多密鑰存儲槽都將存儲在同一個“莖”下。如果給定「莖」下的數據在6 個月內未被讀取或寫入，則不再儲存該數據，而是只儲存對該數據的32 位元組承諾（「存根stub」）。未來存取該數據的交易將需要「復活」數據，並提供根據「存根」進行驗證的證明。
還有其他方法可以實現類似的想法。例如，如果帳戶層級的粒度不夠，我們可以製定一個方案，其中「樹」的每個「1/2 的32 次方」部分都由類似的「莖和葉」機制控制。
由於激勵因素，這變得更加棘手：攻擊者可以透過將大量資料放入單個子樹（Subtree）並每年發送單一交易來「更新樹」，從而迫使客戶端永久儲存大量狀態。如果使更新成本與「樹」大小成正比（或更新持續時間成反比），那麼有人可能會透過將大量資料放入與他們相同的子樹中來傷害其他使用者。使用者可以嘗試透過根據子樹大小使粒度動態化來限制這兩個問題：例如，每個連續的「2 的16 次方」= 65536 個狀態物件可以被視為一個「群組」。然而，這些想法更為複雜；基於「莖」的方法很簡單，它與激勵措施保持一致，因為通常「莖」下的所有數據都與同一個應用程式或用戶相關。
基於位址週期的狀態到期建議
如果我們想完全避免任何永久性的狀態增長，即使是32 位元組的「存根」，該怎麼辦？由於復活衝突（ Resurrection Conflicts ），這是一個難題：如果一個狀態物件被刪除，稍後的EVM 執行會將另一個狀態物件放在完全相同的位置，但之後關心原始狀態物件的人回來並試圖恢復它，該怎麼辦？在部分狀態到期時，「存根」會阻止建立新資料。在完全狀態到期的情況下，我們甚至無法儲存「存根」。
基於地址週期的設計是解決此問題的最佳方法。我們不再使用一棵狀態樹來儲存整個狀態，而是擁有一個不斷增長的狀態樹列表，並且任何讀取或寫入的狀態都會保存在最新的狀態樹中。每個週期（例如1 年）新增一次新的空狀態樹。較舊的狀態樹將保持穩定。完整節點僅應儲存最近的兩棵狀態樹。如果狀態物件在兩個週期內未被觸及，因此落入過期狀態樹中，它仍然可以被讀取或寫入，但交易需要證明它的Merkle 證明——一旦證明，副本將再次保存在最新的狀態樹中。
使這一切對使用者和開發人員都友善的一個關鍵思想是地址週期的概念。地址週期是地址一部分的數字。關鍵規則是位址週期為N 的位址只能在週期N 期間或之後（即，當狀態樹清單達到長度N 時）被讀取或寫入。如果使用者要儲存新的狀態物件（例如，一個新合約或新的ERC20 餘額），如果你確保將狀態物件放入位址週期為N 或N-1 的合約中，那麼你可以立即儲存它，無需提供證據證明之前什麼都沒有。另一方面，對舊地址週期中的狀態進行任何新增或編輯都需要證明。
這種設計保留了以太坊當前的大部分特性，額外計算量非常小，允許應用程式幾乎像現在一樣編寫（ERC20 需要重寫，以確保地址週期為N 的地址餘額存儲在本身俱有地址週期為N的子合約中），並解決了「使用者進入山洞五年」的問題。然而，它有一個大問題：位址需要擴展到20 個位元組以上才能適應位址週期。
位址空間擴充（ Address space extension ）
一項提議是引入一種新的32 位元組位址格式，其中包括版本號、位址週期號和擴展雜湊值。
紅色是版本號。橘色的四個零表示空白空間，將來可以容納分片編號。綠色是地址週期號。藍色是26 位元組的雜湊值。
這裡的關鍵挑戰是向後相容性。現有合約是圍繞著20 位元組位址設計的，並且通常使用嚴格的位元組打包技術，明確假設位址正好是20 位元組長。 解決這個問題的一個想法是使用轉換映射（Translation Map），其中與新式位址互動的舊式合約將看到新式位址的20 位元組雜湊。然而，要確保這一點的安全性，存在著很大的複雜性。
位址空間收縮（Address space contraction）
另一種方法則採取相反的方向：我們立即禁止一些「2 的128 次方」大小的位址子範圍（例如，所有以0x ffffffff 開頭的位址），然後使用該範圍引入帶有位址週期和14 字節哈希值的位址。
這種方法的主要犧牲是，它為反事實地址引入了安全風險：持有資產或權限但其程式碼尚未發佈到鏈上的地址。風險在於有人創建一個地址，聲稱擁有一段（尚未發布的）代碼，但還有另一段有效代碼，該代碼的哈希值指向同一地址。計算這樣的碰撞目前需要「2 的80 次方」個哈希值；位址空間收縮會將這個數字減少到易於存取的「2 的56 次方」個哈希值。
關鍵風險領域是反事實地址，即不是由單一所有者持有的錢包，這在今天是一種相對罕見的情況，但隨著我們進入多重L2 世界，這種情況可能會變得更加常見。唯一的解決方案是簡單地接受這種風險，但要確定可能出現問題的所有常見用例，並提出有效的解決方法。
與現有研究有哪些關聯？
早期提案
再生（ReGenesis）
部分狀態到期提案： EIP-7736
位址空間擴充文件：
還要做些什麼，需要權衡什麼？
我認為未來有四條可行的道路：
1.我們實行無狀態，從不引入狀態到期。狀態正在不斷增長（儘管速度緩慢：幾十年內我們可能不會看到它超過8 TB），但只需要由相對專業的用戶類別持有：甚至PoS 驗證器都不需要狀態。
需要存取部分狀態的一個功能是包含清單生成，但我們可以以去中心化的方式實現這一點：每個使用者負責維護狀態樹中包含自己帳戶的部分。當他們廣播交易時，他們會廣播在驗證步驟中存取的狀態物件的證明（這適用於EOA 和ERC-4337 帳戶）。然後，無狀態驗證器可以將這些證明組合成整個包含清單的證明。
2.我們實施部分狀態到期，並接受一個低得多但仍非零的永久狀態大小成長率。這一結果可以說類似於涉及對等網路的歷史到期提案——如何接受一個低得多但仍然非零的永久歷史儲存成長率，因為每個客戶端必須儲存一個較低但固定百分比的歷史數據。
3.我們使用位址空間擴充來進行狀態到期。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括現有應用程式。
4.我們使用位址空間收縮來進行狀態到期。這將涉及一個多年的過程，以確保處理所有涉及地址衝突的安全風險（包括跨鏈情況）。
重要的一點是，無論是否實現依賴於位址格式變更的狀態到期方案，最終都必須解決有關位址空間擴展和收縮的難題。目前，大約需要「2 的80 次方」的雜湊值運算才能產生位址衝突，對於資源極為充足的參與者來說，這種計算負載已經是可行的：GPU 可以進行大約「2 的27 次方」哈希值運算，因此運行一年可以計算「2 的27 次方」次，因此世界上所有約「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。
與現有研究有哪些關聯？
- 清除的後續步驟
- 自毀（SELFDESTRUCT）
- SSZ 化EIPS： [1] [2] [3]
- 無狀態Gas 成本變化
- 線性記憶體定價
- 預編譯刪除
- Bloom 過濾器刪除一種使用增量可驗證計算進行鏈下安全性日誌檢索的方法（閱讀：遞歸STARK）
還要做些什麼，需要權衡什麼？
進行此類功能簡化的主要權衡是（i）我們簡化的程度和速度與（ii）向後相容性。以太坊作為一條鏈的價值在於它是一個平台，用戶可以部署應用程序，並確信它在多年後仍能正常工作。同時，這種理想也有可能被推得太遠了， 用William Jennings Bryan 的話來說，「將以太坊釘在向後相容性的十字架上」。如果整個以太坊中只有兩個應用程式使用給定的功能，其中一個多年來沒有用戶，幾乎完全未使用，並且總共獲得了57 美元的價值，那麼我們應該刪除該功能，如果需要，可以自掏腰包向受害者支付57 美元。
更廣泛的社會問題在於創建一個標準化的流程，用於進行非緊急的向後相容性破壞性的更改。解決此問題的一種方法是檢查和擴展現有先例，例如SELFDESTRUCT 流程。流程如下所示：
- 步驟1：開始討論刪除功能X
- 步驟2：進行分析以確定移除X 對應用程式造成的影響，根據結果：（i） 放棄這個想法，（ii）按計劃進行，或（iii）找到一種修改後的「破壞性最小」的方法來移除X，並繼續進行。
- 步驟3：制定正式的EIP 來棄用X。確保流行的高級基礎設施（例如程式語言、錢包）尊重這一點並停止使用該功能。
- 步驟4：最後，實際刪除X
在第1 步和第4 步之間應該有一個長達數年的流程，並明確說明哪些專案處於哪個步驟。此時，需要在「功能移除流程的力度和速度」與「更為保守和將更多資源投入協議開發的其他領域」之間進行權衡，但我們距離「帕累托前沿（Pareto frontier）」還很遠。 （Techub News 註，帕累托前緣是指在多目標最佳化問題中，所有帕累托最適解的集合）
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 進行原地交換（In-place Swap）。我們可以選擇RISC-V、Cairo 或其他VM 作為新的「官方以太坊VM」，然後強制所有EVM 合約轉換為解釋原始程式碼邏輯的新VM 程式碼（透過編譯或解釋）。從理論上講，甚至可以將“目標VM”作為EOF 的一個版本來完成此操作。
