以太坊協議可能的未來（五）：The Purge

本文深入了解如何在不犧牲效能的同時簡化區塊鏈架構，提升網路效率和永續性。

譯文：Possible futures of the Ethereum protocol, part 5: The Purge（vitalik.eth）

作者： vitalik.eth

編譯： ChoeyGit，183Aaros，LXDAO

  譯者前言

作為一名區塊鏈技術、以太坊生態的關注者與學習者，當看到 Vitalik 提出的"The Purge"計劃，深感振奮與期待。這項計畫提出了一個獨特的發展想法：在區塊鏈追求功能擴展的背景下，轉而透過優化和簡化系統架構來提升網路效率。該計畫主要聚焦於解決區塊鏈數據膨脹問題，簡化系統複雜度，以期降低參與門檻，提升網路的可持續性。

隨著區塊鏈技術的快速發展，網路數據持續成長、系統架構日益複雜的困難逐漸顯現。特別是在 Layer 2 解決方案廣泛應用的今天，提供了更高的擴展性，同時也為系統帶來了額外的複雜性。在這樣的背景下，本文的"The Purge"計劃提出了一個新的思考方向。

這條技術路線是否能在不影響網路效能的前提下實現有效瘦身？如何在簡化和功能之間取得平衡？接下來請跟著文章一起對這些問題進行深入探討。

本文概述

本文共約 10,000 字，有 3 個部分，閱讀完本文預計需要 50 分鐘。

1.   歷史過期（History expiry）
2.   狀態過期（State expiry）
3. 特性清理（Feature cleanup）

  正文內容

《以太坊協議可能的未來（五）：The Purge》

特別感謝 Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden 和 Tomasz Stanczak 的回饋和審閱。

以太坊面臨這樣一個挑戰：預設情況下，區塊鏈協議的膨脹和複雜度都會隨時間推移而增長。這種情況主要體現在兩個方面：

歷史資料：無論何時（在鏈上）產生的交易、創建的帳戶，都需要被所有客戶端永久存儲，同時新客戶端在進行全節點同步時也需要下載全部資料。這導致即使鏈的處理容量保持不變，客戶端的負載和同步時間也會持續增加。

協定特性：新增特性比移除舊特性容易得多，這導致程式碼複雜度會隨時間不斷增加。

為了以太坊可持續的長期發展，我們需要找到對抗這兩種趨勢的強大措施：隨著時間的推移，不斷降低複雜度和膨脹。同時，我們也需要保留區塊鏈的核心特性：永久性。你可以儲存 NFT、一封寫在交易資料（calldata）中的情書、或是在鏈上部署一個包含百萬美金的智能合約。即使你在山洞中隱居十年，出來的時候發現它還在那裡等著你去閱讀和互動。去中心化應用程式（dapps）需要在確信自身應用運作所依賴的元件，不會因升級而導致破壞性變更的前提下，才能夠放心地實現完全去中心化並移除它們的升級金鑰—— — 特別是 L1 本身。

在保持連續性的同時，最小化或扭轉資料膨脹、複雜度和衰退，我們要在這兩種需求之間尋找一個平衡。我們相信只要我們在這方面投入研究，這絕對是可以實現的。生物體可以做到這一點：雖然大多數人會隨時間衰老，但也有少數幸運兒不會。甚至社會系統也可以實現超長壽命。以太坊已經在幾個方面展示了成功案例：工作量證明機制（Pow）已經被淘汰， SELFDESTRUCT 操作碼（opcode）基本上已經消失，信標鏈（beacon chain）節點現在只儲存最近六個月的歷史數據。這是以太坊在長期可擴展性、技術永續性甚至安全性方面的終極挑戰，旨在為以太坊找到一條更具普適性的發展道路，並朝著長期穩定的最終目標邁進。

 The Purge ：關鍵目標

• 降低客戶端的儲存需求，透過減少或消除每個節點永久儲存所有歷史資料的需求，甚至可能減少對儲存狀態資料的依賴。
• 透過消除不必要的特性來降低協定複雜度。

  本章內容

•   歷史過期（History expiry）
•   狀態過期（State expiry）
• 特性清理（Feature cleanup）

  歷史過期

  我們要解決什麼問題？

截至本文撰寫時，一個全同步（full-synced）的以太坊節點需要大約 1.1 TB 的磁碟空間用於執行客戶端，另外還需要數百 GB 用於儲存共識用戶端。其中絕大部分是歷史數據：包括歷史區塊、交易和收據數據，這些數據大多已有多年歷史。這意味著即使 gas 上限完全不增加，節點的大小每年仍會增加數百 GB。

  它是什麼，如何做到的？

歷史儲存問題有一個關鍵的簡化特性：由於每個區塊通過哈希鏈接（以及其他結構）並指向前一個區塊，這意味著只要對當前狀態達成了共識，就代表著對歷史達成共識。只要網路對最新區塊達成了共識，任何歷史區塊、交易或狀態（帳戶餘額、nonce、代碼、儲存）都可以由任何單一參與者提供，並附帶著默克爾證明（Merkle proof），它允許除了單一參與者以外的所有人為驗證其正確性。當共識使用 N/2-of-N 的信任模型，但歷史是 1-of-N 的信任模型。

這為我們儲存歷史資料的方式提供了許多選擇。一個自然的選擇是讓網路中的每個節點只儲存一小部分資料。這就像 torrent networks 幾十年來的運作方式：雖然整個網路儲存和分發數百萬個文件，但每個參與者只儲存和分發其中的一小部分。也許與直覺相反，這種方法並不一定會降低數據的穩健性。如果透過降低節點運行成本，我們能夠實現一個擁有 10 萬個節點的網絡，其中每個節點隨機存儲 10% 的歷史數據，那麼每條數據就會被複製 1 萬次——這與一個擁有 1 萬個節點且每個節點儲存所有資料的網路具有完全相同的複製因子（replication factor）。

如今，以太坊已經開始逐步擺脫所有節點永久儲存所有歷史資料的模式。共識區塊（即與權益證明共識相關的部分）僅儲存約 6 個月。 Blobs 僅存放約 18 天。 EIP-4444 提案旨在為歷史區塊和收據引入一年的儲存期限。長期目標是建立一個可協調的的儲存期限（可能是約 18 天），在此期間每個節點負責儲存所有數據，之後透過由以太坊節點組成的點對點網路以分散式方式儲存較早的數據。

糾刪碼（erasure codes）可以在保持相同副本因子（replication factor）的同時提高資料穩健性。實際上，為了支援資料可用性採樣，Blobs 本身就已經使用了糾刪碼技術。最簡單的解決方案可能就是重複使用這種糾刪碼技術，並將執行層和共識層的區塊資料也放入 Blobs 中。

  與現研究有哪些關聯？

• EIP-4444 提案:https://eips.ethereum.org/EIPS/eip-4444
• torrent 網路與 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-cryptographyally-secured-retrieval-of-ssz-objects-for-portal-network/19575
• 如何提高 Gas Fee 上限 (Paradigm): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

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

剩餘的主要工作涉及建立和整合一個具體的分散式歷史儲存解決方案- 至少要包含執行層的歷史數據，最終還要包括共識層數據和 Blobs。最簡單的解決方案有兩個：(i) 直接引入現有的 torrent 函式庫，以及 (ii) 一個稱為 Portal 網路的以太坊原生解決方案。一旦這兩個方案中的任何一個被引入，我們就可以啟用 EIP-4444。 EIP-4444 本身不需要硬分叉，但需要一個新的網路協定版本。因此，讓所有客戶端同時啟用該功能是很有價值的，否則當客戶端連接到其他節點時，可能會出現期望下載完整歷史數據，但實際上無法取得的故障風險。

主要權衡的地方在於我們要在多大程度上努力確保「上古」歷史資料的可用性。最簡單的解決方案是從明天開始就停止儲存「上古」歷史數據，轉而依賴現有的歸檔節點和各種中心化服務供應商來進行資料複製。這很容易實現，但這會削弱以太坊作為永久記錄儲存地的地位。更困難但更安全的路徑是先建置並整合 torrent networks，以分散式方式儲存歷史資料。這裡的"我們有多努力"有兩個維度：

1. 我們需要投入多少的努力去確保最大數量的節點真正儲存了所有資料？
2.   我們應該在多大程度上將歷史資料儲存整合到協定中？

對於維度（1）而言，一個極度嚴謹的方案就會涉及到託管證明（proof of custody）：實際要求每個權益證明驗證者存儲一定比例的歷史數據，並定期進行加密檢查以確保他們驗證其儲存情況。另一個較溫和的方案是設定一個自願標準，讓每個客戶端自願儲存一定比例的歷史資料。

對於維度（2）而言，基礎實現方案是直接採用現有成果：Portal 已經儲存了包含完整以太坊歷史的 ERA 檔案。一個更全面的實作方案是將其實際連接到同步過程中，這樣如果有人想要同步一個儲存完整歷史的節點或歸檔節點，即使在線上沒有其他歸檔節點的情況下，也可以直接從 Portal 網路進行同步。

他如何與路線圖中的其他部分互動？

如果我們想要讓運作或啟動節點變得極為簡單，那麼降低歷史資料儲存需求可以說比無狀態化更為重要：在節點所需的 1.1 TB 儲存空間中，狀態資料約佔 300 GB，而歷史數據則佔據剩餘的約 800 GB。讓以太坊節點能在智慧手錶上運行，且只需幾分鐘就能完成設定的願景，只有在同時實現了無狀態化和 EIP-4444 的情況下才能實現。

限制歷史資料的儲存為「只需要透過支援最新版本的協定就可以讓較新的以太坊節點實現」提高了可行性，這也讓節點實現變得更簡單。例如，由於 2016 年 DoS 攻擊期間創建的空白儲存槽位已全部移除，現在可以安全地刪除許多相關的程式碼行。同樣，既然向權益證明（PoS）的切換已成為「上古」歷史，客戶端現在可以安全地移除所有與工作量證明（PoW）相關的程式碼。

  狀態過期

  它解決了什麼問題？

即使我們移除了客戶端儲存歷史資料的需求，客戶端的儲存需求仍會持續成長，每年增加約 50 GB，這是因為狀態資料持續成長：帳戶餘額和 nonce 值、合約代碼和合約儲存。使用者只需支付一次性成本，就能對現在和未來的以太坊客戶端施加永久的儲存負擔。

狀態資料比歷史資料更難 “過期”，這是因為 EVM 的基礎設計建立在這樣一個假設之上：一旦狀態物件被創建，它就會永久存在，並且可以被任何交易在任何時候讀取。如果我們引入無狀態化，有一種觀點認為這個問題可能並沒有那麼嚴重：只有特定類別的區塊構建者才需要實際存儲狀態數據，而所有其他節點（甚至包括 inclusion list 的生成！）都可以以無狀態方式運轉。然而，另一種觀點認為我們不應過度依賴無狀態化，最終我們可能還是需要狀態過期以確保以太坊的去中心化。

  它是什麼，如何做到的？

如今，當你建立一個新的狀態物件（可以透過以下三種方式之一實現：(i) 向新帳戶發送 ETH，(ii) 利用程式碼建立的新帳戶，(iii) 設定先前未被使用的存儲槽，該狀態物件將永久存在於狀態中。

1. 效率：運行過期流程時不應該花費大量的額外計算
2. 用戶友善性：如果某人進入山洞五年後重新出現，他們不應該失去對其 ETH、ERC20 代幣、NFT、CDP 頭寸等資產的訪問權限
3. 開發者友善性：開發者不應該被要求切換到一個完全陌生的思維模型。此外，那些目前已經固化且不再更新的應用程式應該能繼續正常運行

如果不考慮滿足這些目標，解決問題其實很簡單。例如，你可以讓每個狀態物件儲存一個過期日期計數器（可以透過銷毀 ETH 來延長期限，這種延長可以在每次讀寫時自動進行），並設定一個循環遍歷狀態以刪除過期狀態物件的流程。然而，這會引入額外的運算（甚至增加儲存需求），而且顯然不符合用戶友善性要求。對開發者來說，處理儲存值有時會重置為零的極端情況也會很困難。如果將過期計時器設置為合約級別，這在技術上確實讓開發者更輕鬆，但在經濟性方面卻帶來更多困難：開發者需要考慮如何將持續的存儲成本 “轉嫁” 給他們的用戶。

這些問題困擾以太坊核心開發社群多年，期間出現過「區塊鏈租金（blockchain rent）」和「激活重生（regenesis）」等提案。最終，我們整合了這些提案中最好的部分，得出了兩類「已知的最不壞的情況」：

•   局部狀態過期解決方案
•   基於位址週期的狀態資料過期機制提案

  局部狀態過期

所有局部狀態過期提案都遵循相同的原則。我們將狀態資料分割成多個資料塊。每個人都永久儲存一個 “頂層映射表”，用於標記哪些資料塊是空的或非空的。每個資料塊內的資料只有在近期被存取過的情況下才會被儲存。同時存在一個「啟動」機制：如果某個資料塊不再被存儲，任何人都可以透過提供該資料的證明來使其恢復。

這些提案之間的主要區別在於：(i) 如何定義 “近期”，以及 (ii) 如何定義 “資料塊”。其中一個具體的提案是 EIP-7736，它基於為 Verkle 樹引入的 “莖葉結構（stem-and-leaf）” 設計（儘管它與任何形式的無狀態化都兼容，例如二叉樹）。在這個設計中，相鄰的頭部、代碼和儲存槽都儲存在同一個「莖」下。每個莖下儲存的資料最多為 256 * 31 = 7,936 位元組。在許多情況下，一個帳戶的整個頭部、代碼以及許多關鍵儲存槽都會儲存在同一個莖下。如果某個莖下的資料在 6 個月內沒有被讀取或寫入，這些資料就不再存儲，取而代之的是只儲存一個 32 位元組的承諾（「存根」）。未來存取這些數據的交易需要「啟動」這些數據，並提供一個可以與存根（stub）進行檢查的證明。

還有其他方式可以實現類似的想法。例如，如果帳戶層級的粒度不夠細，我們可以設計一個方案，讓狀態樹的每 1/232 的部分都由類似的莖葉機制（stem-and-leaf）來管理。

但這種方法會使激勵機制的實現更為棘手：攻擊者可能透過在單個子狀態樹中存入大量數據，然後每年發送一個交易來 “更新狀態樹 “，從而強制客戶端永久存儲大量狀態。如果將更新成本設定為與狀態樹的大小成正比（或更新持續時間與樹的大小成反比），那麼攻擊者可能會在同一個子級狀態樹中存入大量資料來騷擾其他使用者。我們可以嘗試透過基於子級狀態樹大小的動態粒度來限制這兩個問題：例如，每連續的 2^16 = 65536 個狀態物件可以被視為一個「群組」。然而，這些想法都更為複雜；相比之下，基於莖的方法簡單，並且能夠很好地協調激勵機制，因為通常一個莖下的所有數據都與同一個應用程式或用戶相關。

  基於位址週期的狀態過期機制提案

如果我們想完全避免永久性的狀態成長，甚至連 32 位元組的存根都不想保留，該怎麼辦？這是一個棘手的問題，因為會出現激活衝突：假設一個狀態對像被移除後，後續的 EVM 執行在完全相同的位置放置了另一個狀態對象，而這時關心原始狀態對象的人回來嘗試恢復它，會發生什麼事？在局部狀態過期方案中，「存根」可以防止新資料被建立。但在完全狀態過期方案中，我們連存根都無法儲存。

基於地址週期（address-period-bssed）的設計是解決這個問題最好的已知方案。它不是使用一棵狀態樹來儲存整個狀態，而是維護一個持續成長的狀態樹列表，任何被讀取或寫入的狀態都會被保存在最新的狀態樹中。每個週期（比如說：1 年）都會增加一棵新的空狀態樹。較舊的狀態樹會被完全凍結。全節點只需要儲存最近的兩棵狀態樹。如果某個狀態物件在兩個週期內都未被訪問，因此落入了過期的狀態樹中，它仍然可以被讀取或寫入，但相關交易需要為其提供默克爾證明—— 一旦證明成功，該狀態的副本就會再次被保存在最新的狀態樹中。

使這一切對用戶和開發者友好的一個關鍵概念是「地址週期」。地址週期是地址的一部分。一個關鍵規則是：具有位址週期 N 的位址只能在週期 N 期間或之後被讀取或寫入（即當狀態樹列表長度達到 N 時） 。如果你要保存一個新的狀態物件（例如：一個新合約或一個新的 ERC20 餘額），只要確保將該狀態物件放入位址週期為 N 或 N-1 的合約中，就可以立即儲存，而無需提供之前該位置為空的證明。但另一方面，對更早地址週期的狀態進行任何新增或編輯都需要提供證明。

這個設計保留了以太坊當前的大部分特性，額外的計算開銷很小，而且允許應用程式幾乎可以按照現在的方式編寫（不過 ERC20 需要重寫，以確保地址週期為 N 的地址的餘額被存儲在一個同樣具有地址週期 N 的子合約中），並解決了「用戶進入山洞五年」的問題。然而，它有一個重大問題：位址需要擴展到超過 20 位元組才能容納位址週期。

  位址空間擴充

一個提議是引入一種新的 32 位元組位址格式，其中包含版本號、位址週期號和擴展雜湊值。

紅色部分是版本號。這裡的橘色四個零是預留的空間，未來可用於存放分片號。綠色部分是地址週期號。藍色部分是 26 位元組的雜湊值。

這裡的關鍵挑戰是向後相容性。現有的合約是基於 20 位元組位址設計的，而且經常使用緊湊的位元組打包技術，這些技術明確假設位址長度恰好是 20 位元組。解決這個問題的一個想法是使用轉換映射表，讓與新式位址互動的舊式合約看到的是新式位址的 20 位元組雜湊值。然而，要確保這種方式的安全性還涉及許多複雜的問題。

  地址空間收縮

另一種方法則相反：我們立即停用一個大小為 2^128 的位址子範圍（例如：所有以 0xffffffff 開頭的位址），然後使用該範圍來引入包含位址週期和 14 位元組雜湊值的位址。

這種方法的主要代價是，它為反事實位址（counterfactual addre sses）帶來了安全風險：這些位址雖然持有資產或權限，但其程式碼尚未發佈到鏈上。風險在於有人可能會建立一個位址，聲稱擁有一段（尚未發布的）程式碼，但同時還有另一段有效程式碼也能哈希到相同位址。目前計算這樣的碰撞需要 2^80 次哈希運算；而位址空間收縮會將這個數字降低到非常容易達到的 2^56 次哈希運算。

主要的風險領域是那些不由單一所有者持有的反事實地址錢包，這在今天是相對罕見的情況，但隨著我們進入 L2 多層拓展（multi-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/stateless-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 帳戶）。無狀態驗證者隨後可以將這些證明組合成完整包含清單的證明。

實施局部狀態過期機制，接受一個雖然大幅降低但仍非零的永久狀態大小成長率。這個結果可以說類似於歷史過期提案中涉及點對點網路的情況：每個客戶端需要儲存一個較低但固定比例的歷史數據，從而接受一個降低但非零的永久歷史儲存成長率。

實施狀態過期機制，同時進行位址空間擴充。這個過程將持續多年，以確保地址格式轉換方法是可行且安全的，這也包括對現有應用程式的安全性保障。

實施狀態過期機制，同時進行位址空間收縮。這個過程將持續多年，以確保所有與地址碰撞相關的安全風險都得到處理，包括跨鏈場景下的風險。

有一個重要觀點是，無論是否實施依賴地址格式變更的狀態過期方案，這些圍繞地址空間擴展和收縮的棘手問題最終都需要解決。目前，產生一個位址碰撞大約需要 2^80 次哈希運算，這種計算負載對於資源極其充足的參與者來說已經是可行的：一個 GPU 每秒可以進行約 2^27 次哈希運算，因此運行一年可以計算 2^52 次，這樣全球約 2^30 個 GPU 在大約 1/4 年內就能計算出一個碰撞，而 FPGA 和 ASIC 還可以進一步加快這個速度。在未來，這種攻擊將對越來越多的人開放。因此，實施完整狀態過期的實際成本可能並沒有看起來那麼高，因為無論如何我們都必須解決這個極具挑戰性的地址問題。

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

實作狀態資料過期機制可能會使狀態樹格式之間的轉換變得更容易，因為不需要轉換過程：你可以直接用新格式建立新的狀態樹，之後再透過硬分叉轉換舊狀態樹。因此，儘管狀態資料過期機制很複雜，但它確實在簡化路線圖的其他方面帶來了好處。

特性清理

  我們要解決什麼問題？

安全性、可訪問性和可信任中立性的關鍵前提之一是簡單性。如果一個協定優雅又簡單，就能降低漏洞的可能性。這也會增加新開發者能夠參與並處理其任何部分的可能性。同時，這種簡單性使得協議更有可能公平，也更容易抵禦特殊利益的影響。不幸的是，協議和任何社會系統一樣，預設會隨著時間變得越來越複雜。如果我們不希望以太坊陷入不斷增加複雜性的黑洞，我們需要做以下兩件事之一：（i）停止變更並讓協議固化，（ii）能夠實際移除某些功能並降低複雜性。另外還有一條中間路線也是可能的：減少協議的變更，同時隨著時間推移逐步降低一些複雜性。本節將討論如何降低或移除複雜性。

它是什麼，如何做到的？

不存在一個能夠降低協定複雜性的統一大型解決方案；問題的本質在於存在許多小的修復方法。

這裡有一個已基本完成且可以作為處理其他類似情況參考的例子，那就是 SELFDESTRUCT 操作碼的移除。 SELFDESTRUCT 操作碼是唯一能在單一區塊內修改無限數量儲存槽的操作碼，這要求用戶端實現更多的複雜性來避免 DoS 攻擊。這個操作碼最初的目的是實現自願的狀態清理，使狀態資料大小能隨時間減少。但實踐中很少有人最終使用它。在 Dencun 硬分叉中，該操作碼被削弱，只允許自毀在同一交易中創建的帳戶。這解決了 DoS 問題，並使客戶端程式碼得到顯著簡化。在未來，完全移除這個操作碼可能是合理的。

目前已確定的一些關鍵的協議簡化機會包括以下幾點。首先是一些 EVM 以外的例子；這些變更相對來說影響較小，因此更容易在短期內達成共識並實施。

• RLP 到 SSZ 的轉換：最初，以太坊物件使用一種稱為 RLP 的編碼方式進行序列化。 RLP 是無類型的，且存在不必要的複雜性。如今，信標鏈使用 SSZ，這在許多方面都有顯著優勢，不僅支援序列化，還支援雜湊運算。我們希望最終完全摒棄 RLP，將所有資料類型轉換為 SSZ 結構體，這反過來會使升級變得更加容易。目前相關的 EIP 提案包括 [1]https://eips.ethereum.org/EIPS/eip-6465[2]https://eips.ethereum.org/EIPS/eip-6465[3]https://eips .ethereum.org/EIPS/eip-6465
• 移除舊交易類型：目前存在太多交易類型，其中許多都可以移除。相比完全移除，一個更溫和的替代方案是引入帳戶抽象特性，允許智慧帳戶根據需要選擇包含處理和驗證舊式交易的程式碼。
• 日誌改造：日誌會建立布隆過濾器（bloom filters）和其他邏輯，這些增加了協定的複雜性，但由於速度太慢，客戶端實際上並未使用它們。我們可以移除這些特性，轉而投入精力開發替代方案，例如使用 SNARKs 等現代技術的協定外去中心化日誌讀取工具。
• 信標鏈最終移除同步委員會機制：同步委員會機制最初是為了實現以太坊的輕客戶端驗證而引入的。然而，它給協議增加了顯著的複雜性。最終，我們將能夠使用 SNARKs 直接驗證以太坊共識層，這樣就不再需要專門的輕客戶端驗證協定。透過創建一個更「原生」的輕客戶端協議（該協議涉及驗證以太坊共識驗證者隨機子集的簽名），共識的變更可能使我們更早移除同步委員會。
• 資料格式統一化：目前，執行狀態儲存在 Merkle Patricia 樹中，共識狀態儲存在 SSZ 樹中，而 Blobs 則使用 KZG 承諾進行提交。在未來，為區塊資料和狀態資料分別制定統一格式是有意義的。這些格式將滿足所有重要需求：(i) 為無狀態客戶端提供簡單的證明，(ii) 資料的序列化和糾刪碼編碼，(iii) 標準化的資料結構。
• 移除信標鏈委員會：這個機制最初是為了支援執行分片的特定版本而引入的。然而，我們最終透過二層網路和資料塊實現了分片。因此，委員會變得不再必要，目前正在推進移除它們的工作。
• 移除混合位元組序：EVM 採用大端位元組序，而共識層則採用小端位元組序。重新統一並將所有內容統一為其中一種位元組序（可能是大端序，因為 EVM 更難改變）是有意義的。

  現在，讓我們來看看一些在 EVM 內的例子：

• gas 機制的簡化：目前的 gas 規則在限制驗證區塊所需資源量方面並未得到很好的最佳化。主要的例子包括：(i) 讀寫儲存的成本，這本來應該用於限制區塊中的讀寫次數，但目前實現得相當隨意；以及 (ii) 記憶體填充的規則，目前很難估算 EVM 的最大記憶體消耗。提議的修復方案包括無狀態 gas 成本變更（將所有與儲存相關的成本統一為一個簡單公式），以及這個關於記憶體定價的提案。
• 預編譯合約的移除：以太坊當前的許多預編譯合約既不必要地複雜又很少被使用，且在險些發生的共識失敗事件中佔據了很大比例，卻實際上沒有任何應用在使用它們。處理這個問題有兩種方式：(i) 直接移除預編譯合約，(ii) 用實現相同邏輯的 EVM 程式碼取代它（這不可避免的會增加成本）。這份 EIP 草案建議先對根身分預編譯合約進行這樣的處理；在這之後，RIPEMD 160、MODEXP 和 BLAKE 可能成為移除的候選對象。
• gas 可觀察性的移除：使 EVM 執行過程無法再查看剩餘 gas 總量。這會影響一些應用程式的運作（最明顯的是 sponsored transactions 代付交易），但將使未來的升級變得更容易（例如，用於更高級版本的多維 gas）。 EOF 規範已經使 gas 不可觀察，不過為了實現協議簡化的目的，EOF 需要成為強制性規範。
• 靜態分析的最佳化：目前的 EVM 程式碼很難進行靜態分析，特別是因為跳轉（jumps 程式碼）可以是動態的。這也使得（將 EVM 程式碼預先編譯成其他語言）優化 EVM 的實作變得更加困難。我們可以透過移除動態跳轉來解決這個問題（或使其代價更高，例如，使 gas 成本與合約中 JUMPDEST 的總數呈線性關係）。 EOF 已經實現了這一點，不過要從中獲得協議簡化的收益，則需要強制執行 EOF。

  與現有研究有哪些關聯？

• Purge 的下一個階段: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• 正視問斃：https://hackmd.io/@vbuterin/selfdestruct
•  SSZ 化相關的 EIPS:
  • https://eips.ethereum.org/EIPS/eip-6493
  • https://eips.ethereum.org/EIPS/eip-6466
  • https://eips.ethereum.org/EIPS/eip-6465
• 無狀態 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
• 使用增量可驗證計算（即：遞歸 STARKs）進行鏈下安全日誌擷取的方法：https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

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

進行這類功能簡化的主要權衡在於：(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）還有很遠的距離。

EOF

EVM 物件格式（EOF）是一個已經被提議的 EVM 重大變更集。 EOF 引入了大量改變，例如禁止 gas 可觀察性、禁止程式碼可觀察性（即不允許 CODECOPY）、僅允許靜態跳轉等。其目標是讓 EVM 能夠進行更多升級，以實現更強大的特性，同時保持向後相容性（因為 pre-EOF 版本的 EVM 仍將繼續存在）。

這種方案的優點是為增加新的 EVM 功能提供了一條自然的路徑，並鼓勵遷移到具有更強保障的更嚴格的 EVM。其缺點是會顯著增加協議複雜性，除非我們能找到方法最終廢棄並移除舊版 EVM。一個重要的問題是：在 EVM 簡化提案中 EOF 扮演什麼角色，特別是當整體目標是降低 EVM 複雜性的情況下？

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

路線圖中的許多「最佳化」提案同時也是簡化舊功能的機會。重複一些上述例子：

• 切換到單時隙最終性給我們提供了移除委員會、重構經濟模型以及進行其他權益證明相關簡化的機會。
• 完整實作帳戶抽象化讓我們可以移除大量現有的交易處理邏輯，方法是將這些邏輯轉移到一段「預設帳戶 EVM 代碼」中，所有 EOA 都可以被該程式碼取代。
• 如果我們將以太坊狀態遷移到二元哈希樹，這可以與新版本的 SSZ 協調統一，使得所有以太坊資料結構都能以相同的方式進行哈希處理。

一個更激進的方法是：將協議的大部分內容轉換為合約程式碼。

一個更激進的以太坊簡化策略是：保持協議本身不變，但將其大部分內容從協議特性轉變為合約程式碼。

這種方法最極端的版本是：讓以太坊 L1 在「技術上」僅作為信標鏈存在，同時引入一個最小化的虛擬機器（例如 RISC-V、Cairo 或某種更簡化的、專門用於證明系統的虛擬機器），使得任何人都能創建自己的 rollup。 EVM 則會轉變為這些 rollup 中的第一個。有趣的是，這個結果與 2019-20 年的執行環境提案完全一致，不過 SNARKs 使得實際實施此方案的可能性大大提高。

免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。