作者:以太坊創始人Vitalik;編譯:鄧通,金色財經
按:本文為以太坊創始人Vitalik近期發表的「以太坊協議的未來發展」系列文章的第五部分「Possible futures of the Ethereum protocol, part 5: The Purge」,第四部分見「Vitalik:以太坊的未來The Verge」。第三部分見「Vitalik:以太坊The Scourge階段的關鍵目標」,第二部分見「Vitalik:The Surge階段以太坊協議應該怎麼發展」,第一部分見「以太坊PoS還有哪些可以改進」。以下為第五部分全文:
特別感謝 Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、marius van der Wijden 和 Tomasz Stanczak 的反饋和評論。
以太坊面臨的挑戰之一是,默認情況下,任何區塊鏈協議的膨脹和複雜性都會隨著時間的推移而增加。這發生在兩個方面:
- 歷史數據:任何交易和任何歷史時刻創建的任何賬戶都需要由所有客戶端永久存儲,並由任何與網絡完全同步的新客戶端下載。這會導致客戶端負載和同步時間隨著時間的推移而不斷增加,即使鍊的容量保持不變。
- 協議功能:添加新功能比刪除舊功能容易得多,導致代碼複雜性隨著時間的推移而增加。
The Purge, 2023 年路線圖。
如果我們專心致志,在這兩種需求之間取得平衡,在保持連續性的同時盡量減少或扭轉膨脹、複雜性和衰退,是絕對可能的。生物體可以做到這一點:雖然大多數生物體會隨著時間推移而衰老,但幸運的是少數生物體不會衰老。即使是社會系統也可以擁有極長的壽命。在一些情況下,以太坊已經取得了成功:工作量證明已經消失,SELFDESTRUCT 操作碼基本消失,信標鏈節點已經存儲舊數據最多六個月。以更普遍的方式為以太坊找到這條道路,並朝著長期穩定的最終結果邁進,這是以太坊長期可擴展性、技術可持續性甚至安全性的終極挑戰。
The Purge:主要目標
- 通過減少或消除每個節點永久存儲所有歷史記錄的需求來減少客戶端存儲要求,甚至可能最終聲明
- 通過消除不需要的功能來降低協議複雜性
歷史數據過期
它解決了什麼問題?截至撰寫本文時,完全同步的以太坊節點需要大約 1.1 TB 的磁盤空間用於執行客戶端,另外還需要幾百 GB 的空間用於共識客戶端。其中絕大部分是歷史數據:有關歷史區塊、交易和收據的數據,其中大部分都是多年前的數據。這意味著即使 gas 限制根本沒有增加,節點的大小每年也會增加數百 GB。它是什麼?它是如何工作的?歷史存儲問題的一個關鍵簡化特性是,由於每個塊通過哈希鏈接(和其他結構)指向前一個塊,因此對當前達成共識就足以對歷史達成共識。只要網絡對最新塊達成共識,任何歷史塊、交易或狀態(賬戶餘額、隨機數、代碼、存儲)都可以由任何單個參與者提供,並附帶 Merkle 證明,並且該證明允許任何其他人驗證其正確性。雖然共識是 N/2-of-N 信任模型,但歷史是 1-of-N 信任模型。
這為我們存儲歷史記錄的方式開闢了很多選擇。一個自然的選擇是每個節點僅存儲一小部分數據的網絡。這就是 torrent 網絡幾十年來的工作方式:雖然網絡總共存儲和分發數百萬個文件,但每個參與者只存儲和分發其中的幾個。也許違反直覺,這種方法甚至不一定會降低數據的穩健性。如果通過降低節點運行成本,我們可以實現一個擁有 100,000 個節點的網絡,其中每個節點隨機存儲 10% 的歷史記錄,那麼每條數據將被複製 10,000 次 -- 與每個節點存儲所有內容的 10,000 個節點網絡的複製因子完全相同。
今天,以太坊已經開始擺脫所有節點永久存儲所有歷史記錄的模型。共識區塊(即與權益證明共識相關的部分)僅存儲約 6 個月。Blob 僅存儲約 18 天。EIP-4444 旨在為歷史區塊和收據引入一年的存儲期。長期目標是有一個協調的時期(可能是約 18 天),在此期間每個節點負責存儲所有內容,然後有一個由以太坊節點組成的對等網絡,以分布式方式存儲舊數據。
可以使用糾刪碼來提高穩健性,同時保持複製因子不變。事實上,為了支持數據可用性採樣,blob 已經採用糾刪碼。最簡單的解決方案可能是重新使用此糾刪碼,並將執行和共識塊數據也放入 blob 中。
現有哪些研究?EIP-4444:https://eips.ethereum.org/EIPS/eip-4444
Torrents 和 EIP-4444:https://ethresear.ch/t/torrents-and-eip-4444/19788
Portal 網絡:https://ethereum.org/en/developers/docs/networking-layer/portal-network/
Portal 網絡和 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 限制(範式):https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2
剩下要做什麼,又有哪些權衡?剩下的主要工作涉及構建和集成一個具體的分布式解決方案來存儲歷史記錄 -- 至少是執行歷史記錄,但最終也包括共識和 blob。最簡單的解決方案是 (i) 簡單地引入現有的 torrent 庫,以及 (ii) 一個名為 Portal 網絡的以太坊原生解決方案。一旦引入其中任何一個,我們就可以啟用 EIP-4444。EIP-4444 本身不需要硬分叉,但它確實需要一個新的網絡協議版本。因此,同時為所有客戶端啟用它是有價值的,因為否則客戶端可能會因連接到其他節點而出現故障,這些節點期望下載完整的歷史記錄但實際上並沒有實現。
主要的權衡涉及我們如何努力使「此前」歷史數據可用。最簡單的解決方案是明天停止存儲此前數據,並依靠現有的存檔節點和各種中心化提供商進行複製。這很容易,但這削弱了以太坊作為記錄永久數據的地位。更難但更安全的方法是首先構建和集成 torrent 網絡,以分布式方式存儲歷史記錄。這裡「我們有多努力」有兩個維度:
- 我們要多努力才能確保最大數量的節點確實存儲了所有數據?
- 我們將歷史存儲與協議的集成程度有多深?
對於 (2),基本實現僅涉及今天已經完成的工作:portal 已經存儲了包含整個以太坊歷史記錄的 ERA 文件。更徹底的實現將涉及將其實際連接到同步過程,這樣如果有人想要同步完整歷史記錄存儲節點或存檔節點,即使沒有其他存檔節點在線,他們也可以通過直接從 Portal 網絡同步來執行此操作。
它如何與路線圖的其他部分互動?如果我們想讓節點的運行或啟動變得極其簡單,那麼減少歷史存儲要求可以說比無狀態更重要:在節點需要的 1.1 TB 中,約 300 GB 是狀態,其餘約 800 GB 是歷史。以太坊節點在智能手錶上運行且只需幾分鐘即可設置的願景只有在同時實現無狀態和 EIP-4444 的情況下才能實現。
限制歷史存儲也使較新的以太坊節點實現更可行地僅支持協議的最新版本,這使它們變得更加簡單。例如,由於 2016 年 DoS 攻擊期間創建的空存儲槽已全部被刪除,因此可以安全地刪除許多代碼行。既然切換到權益證明已成為歷史,客戶端可以安全地刪除所有與工作量證明相關的代碼。
狀態數據過期
它解決了什麼問題?即使我們消除了客戶端存儲歷史記錄的需求,客戶端的存儲需求仍將繼續增長,每年約 50 GB,因為狀態不斷增長:賬戶餘額和隨機數、合約代碼和合約存儲。用戶可以支付一次性費用,永遠給現在和未來的以太坊客戶端帶來負擔。狀態比歷史記錄更難「過期」,因為 EVM 的設計基本假設是,一旦創建了狀態對象,它將永遠存在,並且可以隨時被任何交易讀取。如果我們引入無狀態,有人認為這個問題可能沒那麼糟糕:只有一類專門的區塊構建器才需要實際存儲狀態,所有其他節點(甚至包含列表生成!) 都可以無狀態運行。然而,有人認為我們不想過分依賴無狀態,最終我們可能希望狀態過期以保持以太坊的去中心化。
它是什麼?它是如何工作的?今天,當你創建一個新的狀態對象時(可以通過以下三種方式之一進行:(i)將 ETH 發送到新賬戶,(ii)使用代碼創建新賬戶,(iii)設置以前未觸及的存儲槽),該狀態對象將永遠處於該狀態。相反,我們想要的是對象隨著時間的推移自動過期。關鍵挑戰是以一種實現三個目標的方式來做到這一點:
- 效率:不需要大量額外的計算來運行到期流程。
- 用戶友好性:如果有人進入洞穴五年後再回來,他們不應該失去對其 ETH、ERC20、NFT、CDP 頭寸的訪問權限……
- 開發者友好性:開發人員不必切換到完全陌生的思維模型。此外,如今僵化且不更新的應用程序應該繼續合理地運行。
這些都是以太坊核心開發社區多年來一直在努力解決的問題,包括「區塊鏈租金」和「再生」等提案。最終,我們結合了提案中最好的部分,並集中於兩類「已知最不壞的解決方案」:
- 部分狀態到期解決方案。
- 基於地址周期的狀態到期提案。
這些提案之間的主要區別是:(i)我們如何定義「最近」,以及(ii)我們如何定義「塊」?一個具體的提案是 EIP-7736,它建立在為 Verkle 樹引入的「莖葉」設計之上(盡管與任何形式的無狀態樹兼容,例如二叉樹)。在這種設計中,彼此相鄰的標頭、代碼和存儲槽存儲在同一個「莖」下。存儲在莖下的數據最多可以是 256 * 31 = 7,936 字節。在許多情況下,賬戶的整個標題和代碼以及許多密鑰存儲槽都將存儲在同一個主幹下。如果給定主幹下的數據在 6 個月內未被讀取或寫入,則不再存儲數據,而是只存儲對數據的 32 字節承諾(「存根」)。未來訪問該數據的交易將需要「復活」數據,並提供與存根核對的證明。
還有其他方法可以實現類似的想法。例如,如果賬戶間隔不夠,我們可以製定一個方案,其中樹的每個 1/232 部分都由類似的莖葉機制控制。
由於激勵因素,這更加棘手:攻擊者可以通過將大量數據放入單個子樹並每年發送單個交易來「更新樹」,從而迫使客戶端永久存儲大量狀態。如果使更新成本與樹大小成比例(或更新持續時間與樹大小成反比),那麼有人可能會通過將大量數據放入與他們相同的子樹中來傷害另一個用戶。可以嘗試通過根據子樹大小使賬戶間隔動態化來限制這兩個問題:例如,每個連續的 2^16 = 65536 個狀態對象可以被視為一個「組」。然而,這些想法更複雜;基於詞幹的方法很簡單,並且可以協調激勵措施,因為通常詞幹下的所有數據都與同一個應用程序或用戶相關。
基於地址周期的狀態過期提案如果我們想完全避免任何永久性的狀態增長,即使是 32 字節的存根,該怎麼辦?這是一個難題:如果狀態對象被刪除,稍後的 EVM 執行將另一個狀態對象放在完全相同的位置,但之後關心原始狀態對象的人回來並試圖恢復它,該怎麼辦?對於部分狀態過期,「存根」會阻止創建新數據。對於完整狀態過期,我們甚至無法存儲存根。
基於地址周期的設計是解決此問題的最佳方法。我們有一個不斷增長的狀態樹列表,而不是用一棵狀態樹存儲整個狀態,並且任何讀取或寫入的狀態都會保存在最新的狀態樹中。每周期(想想:1 年)添加一次新的空狀態樹。較舊的狀態樹是固定的。完整節點只需要存儲最近的兩棵樹。如果狀態對象在兩個周期內未被觸及並因此落入過期樹,它仍然可以被讀取或寫入,但交易需要為其證明 Merkle 證明 -- 一旦這樣做,副本將再次保存在最新的樹中。
使這一切對用戶和開發人員友好的一個關鍵思想是地址周期的概念。地址周期是地址的一部分的數字。一個關鍵規則是,地址周期為 N 的地址只能在周期 N 期間或之後讀取或寫入(即當狀態樹列表達到長度 N 時)。如果您要保存新的狀態對象(例如,新合約或新的 ERC20 餘額),如果您確保將狀態對象放入地址周期為 N 或 N-1 的合約中,那麼您可以立即保存它,而無需提供之前沒有任何內容的證明。另一方面,對舊地址周期中的任何狀態添加或編輯都需要證明。
這種設計保留了以太坊的大部分當前屬性,額外計算量非常小,允許應用程序幾乎像現在一樣編寫(ERC20 需要重寫,以確保地址周期為 N 的地址的餘額存儲在本身具有地址周期 N 的子合約中),並解決了「用戶進入洞穴五年」的問題。然而,它有一個大問題:地址需要擴展到 20 個字節以上才能適合地址周期。
地址空間擴展一項提議是引入一種新的 32 字節地址格式,其中包括版本號、地址周期號和擴展哈希值。
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
紅色是版本號。此處橙色的四個零表示空白,將來可以容納分片號。綠色是地址周期號。藍色是 26 字節哈希值。
此處的關鍵挑戰是向後兼容性。現有合約是圍繞 20 字節地址設計的,並且通常使用緊密字節打包技術,明確假設地址正好是 20 字節長。解決這個問題的一個想法是使用轉換圖,其中與新式地址交互的舊式合約將看到新式地址的 20 字節哈希值。但是,要確保其安全,需要付出相當大的努力。
地址空間收縮另一種方法則相反:我們立即禁止一些 2128 大小的地址子範圍(例如所有以 0xffffffff 開頭的地址),然後使用該範圍引入帶有地址周期和 14 字節哈希值的地址。
0xffffffff000169125d5dFcb7B8C2659029395bdF
這種方法做出的關鍵犧牲是,它為反事實地址引入了安全風險:持有資產或權限但其代碼尚未發布到鍊上的地址。風險涉及有人創建一個地址,該地址聲稱擁有一段(尚未發布的)代碼,但還有另一段有效代碼,該代碼的哈希值指向同一地址。計算這樣的碰撞今天需要 280 個哈希值;地址空間收縮將把這個數字減少到非常容易獲得的 256 個哈希值。
關鍵風險領域,不是由單個所有者持有的錢包的反事實地址,在今天是一種相對罕見的情況,但隨著我們進入多 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/@vbuterin/state_size_management
無狀態和狀態過期的幾種可能路徑:https://hackmd.io/@vbuterin/state_expiry_paths
部分狀態過期提案
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/@ipsilon/address-space-extension-exploration
博客文章評論:https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
如果我們失去碰撞阻力會發生什麼:https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356
還剩下什麼要做?需要權衡什麼?我認為未來有四條可行的路徑:
- 我們實行無狀態,並且從不引入狀態過期。狀態在不斷增長(儘管增長緩慢:幾十年內我們可能都不會看到它超過 8 TB),但只需要由相對專業的用戶類別持有:甚至 PoS 驗證者也不需要狀態。
需要訪問部分狀態的一個功能是包含列表生成,但我們可以以分散的方式實現這一點:每個用戶負責維護包含自己賬戶的狀態樹部分。當他們廣播交易時,他們會廣播在驗證步驟期間訪問的狀態對象的證明(這適用於 EOA 和 ERC-4337 賬戶)。然後,無狀態驗證者可以將這些證明組合成整個包含列表的證明。
- 我們實行部分狀態過期,併接受低得多但仍非零的永久狀態大小增長率。這種結果可能類似於涉及對等網絡的歷史到期提案,該提案接受每個客戶端必須存儲較低但固定百分比的歷史數據的永久歷史存儲增長率,但增長率要低得多,但仍然不為零。
- 我們確實聲明了到期日期,並擴展了地址空間。這將涉及一個多年的過程,以確保地址格式轉換方法有效且安全,包括對於現有應用程序。
- 我們確實聲明了到期日期,並收縮了地址空間。這將涉及一個多年的過程,以確保處理涉及地址衝突(包括跨鏈情況)的所有安全風險。
它如何與路線圖的其他部分互動?執行狀態到期可能會使從一種狀態樹格式到另一種狀態樹格式的轉換變得更容易,因為不需要轉換過程:您可以簡單地開始使用新格式製作新樹,然後稍後進行硬分叉以轉換舊樹。因此,雖然狀態到期很複雜,但它確實有助於簡化路線圖的其他方面。
功能清理
它解決了什麼問題?安全性、可訪問性和可信中立性的關鍵先決條件之一是簡單性。如果協議美觀且簡單,則出現錯誤的可能性就會降低。它增加了新開發人員能夠加入並使用它的任何部分的機會。它更有可能是公平的,並且更容易抵禦特殊利益。不幸的是,協議與任何社會系統一樣,默認情況下會隨著時間的推移變得更加複雜。如果我們不想讓以太坊陷入日益複雜的黑洞,我們需要做以下兩件事之一:(I)停止進行更改並使協議僵化,(ii)能夠實際刪除功能並降低複雜性。中間路線,即對協議進行較少的更改,同時隨著時間的推移至少消除一點複雜性,也是可能的。本節將討論如何減少或消除複雜性。它是什麼?它是如何工作的?沒有一個大的單一修復可以降低協議複雜性;問題的本質是存在許多小修復。
一個基本已經完成的例子,可以作為如何處理其他問題的藍圖,即刪除 SELFDESTRUCT 操作碼。SELFDESTRUCT 操作碼是唯一可以修改單個塊內無限數量的存儲槽的操作碼,需要客戶端實現更大的複雜性以避免 DoS 攻擊。該操作碼的最初目的是實現自願狀態清除,允許狀態大小隨著時間的推移而減少。實際上,很少有人最終使用它。該操作碼被削弱,只允許在 Dencun 硬分叉中在同一筆交易中創建的自毀賬戶。這解決了 DoS 問題,並允許顯著簡化客戶端代碼。將來,最終完全刪除該操作碼可能是有意義的。
迄今為止已確定的一些協議簡化機會的關鍵示例包括以下內容。首先,一些 EVM 之外的示例;這些示例相對非侵入性,因此更容易達成共識並在更短的時間內實施。
- RLP → SSZ 轉換:最初,以太坊對象使用一種稱為 RLP 的編碼進行序列化。如今,信標鏈使用 SSZ,它在許多方面都明顯更好,包括不僅支持序列化,還支持哈希。最終,我們希望完全擺脫 RLP,並將所有數據類型移至 SSZ 結構,這反過來會使升級變得更加容易。目前為此提出的 EIP 包括 [1] [2] [3]。
- 刪除舊交易類型:如今的交易類型太多,其中許多類型可能會被刪除。完全刪除的一個更溫和的替代方案是賬戶抽象功能,通過該功能,智能賬戶可以包含處理和驗證舊式交易的代碼(如果它們願意的話)。
- LOG 改革:日誌創建bloom過濾器和其他邏輯,增加了協議的複雜性,但由於速度太慢,客戶端實際上不會使用它。我們可以刪除這些功能,而是將精力投入到替代方案中,例如使用 SNARK 等現代技術的協議外去中心化日誌讀取工具。
- 最終取消信標鏈同步委員會機制:同步委員會機制最初是為了實現以太坊的輕客戶端驗證而引入的。然而,它增加了協議的複雜性。最終,我們將能夠使用 SNARK 直接驗證以太坊共識層,這將消除對專用輕客戶端驗證協議的需求。通過創建更「原生」的輕客戶端協議,該協議涉及驗證來自以太坊共識驗證器隨機子集的簽名。
- 數據格式協調:今天,執行狀態存儲在 Merkle Patricia 樹中,共識狀態存儲在 SSZ 樹中,並且 blob 以 KZG 承諾的形式提交。在未來,為區塊數據和狀態創建單一統一格式是有意義的。這些格式將涵蓋所有重要需求:(i) 無狀態客戶端的簡單證明,(ii) 數據的序列化和擦除編碼,(iii) 標準化數據結構。
- 刪除信標鏈委員會:最初引入此機制是為了支持特定版本的執行分片。相反,我們最終通過 L2 和 blob 進行分片。因此,委員會是不必要的,因此正在努力將其刪除。
- 刪除混合字節序: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:https://hackmd.io/@vbuterin/selfdestruct
SSZ-ification 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) 向後兼容性。以太坊作為一條鏈的價值在於它是一個平台,您可以在其中部署應用程序並確信它在多年後仍能正常工作。與此同時,也有可能將這一理想發揮得太過,用威廉·詹寧斯·布萊恩的話來說,「將以太坊釘在向後兼容性的十字架上」。如果整個以太坊中只有兩個應用程序使用某個功能,其中一個多年來沒有用戶,而另一個幾乎完全沒有使用,並且總共獲得了 57 美元的價值,那麼我們應該刪除該功能,如果需要,可以自掏腰包向受害者支付 57 美元。
更廣泛的社會問題是創建一個標準化的管道,用於進行非緊急的向後兼容性破壞性更改。解決此問題的一種方法是檢查和擴展現有先例,例如 SELFDESTRUCT 流程。該管道看起來如下所示:
- 步驟 1:開始討論刪除功能 X。
- 步驟 2:進行分析以確定刪除 X 對應用程序的破壞程度,根據結果,選擇 (i) 放棄這個想法,(ii) 按計劃進行,或 (iii) 確定一種經過修改的「破壞性最小」的刪除 X 的方法並繼續進行。
- 步驟 3:制定正式的 EIP 以棄用 X。確保流行的高級基礎設施(例如編程語言、錢包)尊重這一點並停止使用該功能。
- 步驟 4:最後,實際刪除 X。
EOF針對 EVM 提出的一組主要更改是 EVM 對象格式 (EOF)。EOF 引入了大量更改,例如禁止 gas 可觀察性、代碼可觀察性(即無 CODECOPY)、僅允許靜態跳轉。目標是允許 EVM 進行更多升級,以具有更強大的屬性,同時保持向後兼容性(因為 EOF 之前的 EVM 仍然存在)。
這樣做的好處是,它為添加新的 EVM 功能和鼓勵遷移到具有更強保證的更嚴格 EVM 創造了一條自然途徑。它的缺點是,它顯著增加了協議的複雜性,除非我們能找到最終棄用和刪除舊 EVM 的方法。一個主要問題是:EOF 在 EVM 簡化提案中扮演什麼角色,尤其是如果目標是降低整個 EVM 的複雜性?
它如何與路線圖的其他部分互動?路線圖其餘部分中的許多「改進」提案也是簡化舊功能的機會。重複上面的一些例子:
- 切換到單槽終結性使我們有機會取消委員會、重新制定經濟學並進行其他與權益證明相關的簡化。
- 完全實現賬戶抽象讓我們可以刪除許多現有的交易處理邏輯,方法是將其移入一段「默認賬戶 EVM 代碼」,所有 EOA 都可以用它替換。
- 如果我們將以太坊狀態移動到二進製哈希樹,這可以與新版本的 SSZ 協調一致,以便所有以太坊數據結構都可以以相同的方式進行哈希處理。
最極端的版本是讓以太坊 L1「技術上」只是信標鏈,並引入一個最小的 VM(例如 RISC-V、cairo 或專門用於證明系統的更簡單的 VM),允許任何其他人創建自己的匯總。然後,EVM 將成為這些匯總中的第一個。具有諷刺意味的是,這與 2019-20 年的執行環境提案的結果完全相同,儘管 SNARK 使其實際實施起來更加可行。
更溫和的方法是保持信標鏈與當前以太坊執行環境之間的關係不變,但對 EVM 進行就地交換。我們可以選擇 RISC-V、cairo 或其他 VM 作為新的「官方以太坊 VM」,然後將所有 EVM 合約強制轉換為解釋原始代碼邏輯的新 VM 代碼(通過編譯或解釋)。從理論上講,甚至可以將「目標 VM」作為 EOF 版本來完成此操作。
