以太坊協議可能的未來（五）：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"計劃提出了一種新的思考方向。

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

本文概述

本文共約 10000 字，有 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 networks 與 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 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）世界，這種情況可能會變得更加普遍。唯一的解決方案就是接受這個風險，並且識別出所有可能出現這個問題的常見使用場景，並提出有效的規避方案。

與現有研究有哪些聯繫？

早期提案

• 區塊鏈租金（Blockchain rent）: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 賬戶）。無狀態驗證者隨後可以將這些證明組合成完整包含列表的證明。

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

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

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

有一個重要觀點是，無論是否實施依賴於地址格式變更的狀態過期方案，這些圍繞地址空間擴展和收縮的棘手問題最終都需要解決。目前，生成一個地址碰撞大約需要 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 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。