Vitalik：Ethereum協議可能的未來—The Purge
作者：Ethereum創始人Vitalik；編譯：鄧通，金色財經
按：本文為Ethereum創始人Vitalik近期發表的“Ethereum協議的未來發展”系列文章的第五部分“PossiblefuturesoftheEthereumprotocol,part5:ThePurge”，第四部分見“Vitalik：Ethereum的未來TheVerge”。第三部分見“Vitalik：EthereumTheScourge階段的關鍵目標”，第二部分見“Vitalik：TheSurge階段Ethereum協議應該怎么發展”，第一部分見“EthereumPoS還有哪些可以改進”。以下為第五部分全文：
Ethereum面臨的挑戰之一是，默認情況下，任何Blockchain協議的膨脹和復雜性都會隨著時間的推移而增加。這發生在兩個方面：
歷史數據：任何交易和任何歷史時刻創建的任何賬戶都需要由所有客戶端永久存儲，并由任何與網絡完全同步的新客戶端下載。這會導致客戶端負載和同步時間隨著時間的推移而不斷增加，即使鏈的容量保持不變。
協議功能：添加新功能比刪除舊功能容易得多，導致代碼復雜性隨著時間的推移而增加。
為了使Ethereum能夠長期維持下去，我們需要對這兩種趨勢施加強大的反壓力，隨著時間的推移減少復雜性和臃腫。但與此同時，我們需要保留Blockchain的一大關鍵屬性：持久性。你可以把NFT、交易調用數據中的情書或包含一百萬美元的智能合約放在鏈上，進入一個山洞十年，出來后發現它仍然在那里等著你閱讀和互動。為了讓dapp放心地完全Decentralization并刪除升級密鑰，他們需要確信他們的依賴項不會以破壞它們的方式升級——尤其是L1本身。
可以使用糾刪碼來提高穩健性，同時保持復制因子不變。事實上，為了支持數據可用性采樣，blob已經采用糾刪碼。最簡單的解決方案可能是重新使用此糾刪碼，并將執行和共識塊數據也放入blob中。現有哪些研究？
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網絡的Ethereum原生解決方案。一旦引入其中任何一個，我們就可以啟用EIP-4444。EIP-4444本身不需要硬分叉，但它確實需要一個新的網絡協議版本。因此，同時為所有客戶端啟用它是有價值的，因為否則客戶端可能會因連接到其他Node而出現故障，這些Node期望下載完整的歷史記錄但實際上并沒有實現。
主要的權衡涉及我們如何努力使“此前”歷史數據可用。最簡單的解決方案是明天停止存儲此前數據，并依靠現有的存檔Node和各種中心化提供商進行復制。這很容易，但這削弱了Ethereum作為記錄永久數據的地位。更難但更安全的方法是首先構建和集成torrent網絡，以分布式方式存儲歷史記錄。這里“我們有多努力”有兩個維度：
我們要多努力才能確保最大數量的Node確實存儲了所有數據？
我們將歷史存儲與協議的集成程度有多深？
對于(1)來說，最嚴謹的方法將涉及保管證明：實際上要求每個權益證明驗證者存儲一定比例的歷史記錄，并定期通過加密方式檢查他們是否這樣做。更溫和的方法是為每個客戶端存儲的歷史記錄百分比設定一個自愿標準。
對于(2)，基本實現僅涉及今天已經完成的工作：Portal已經存儲了包含整個Ethereum歷史記錄的ERA文件。更徹底的實現將涉及將其實際連接到同步過程，這樣如果有人想要同步完整歷史記錄存儲Node或存檔Node，即使沒有其他存檔Node在線，他們也可以通過直接從Portal網絡同步來執行此操作。它如何與路線圖的其他部分互動？
如果我們想讓Node的運行或啟動變得極其簡單，那么減少歷史存儲要求可以說比無狀態更重要：在Node需要的1.1TB中，約300GB是狀態，其余約800GB是歷史。EthereumNode在智能手表上運行且只需幾分鐘即可設置的愿景只有在同時實現無狀態和EIP-4444的情況下才能實現。
限制歷史存儲也使較新的EthereumNode實現更可行地僅支持協議的最新版本，這使它們變得更加簡單。例如，由于2016年DoS攻擊期間創建的空存儲槽已全部被刪除，因此可以安全地刪除許多代碼行。既然切換到權益證明已成為歷史，客戶端可以安全地刪除所有與工作量證明相關的代碼。狀態數據過期它解決了什么問題？
即使我們消除了客戶端存儲歷史記錄的需求，客戶端的存儲需求仍將繼續增長，每年約50GB，因為狀態不斷增長：賬戶余額和隨機數、合約代碼和合約存儲。用戶可以支付一次性費用，永遠給現在和未來的Ethereum客戶端帶來負擔。
狀態比歷史記錄更難“過期”，因為EVM的設計基本假設是，一旦創建了狀態對象，它將永遠存在，并且可以隨時被任何交易讀取。如果我們引入無狀態，有人認為這個問題可能沒那么糟糕：只有一類專門的區塊構建器才需要實際存儲狀態，所有其他Node（甚至包含列表生成！）都可以無狀態運行。然而，有人認為我們不想過分依賴無狀態，最終我們可能希望狀態過期以保持Ethereum的Decentralization。它是什么？它是如何工作的？
今天，當你創建一個新的狀態對象時（可以通過以下三種方式之一進行：（i）將ETH發送到新賬戶，（ii）使用代碼創建新賬戶，（iii）設置以前未觸及的存儲槽），該狀態對象將永遠處于該狀態。相反，我們想要的是對象隨著時間的推移自動過期。關鍵挑戰是以一種實現三個目標的方式來做到這一點：
效率：不需要大量額外的計算來運行到期流程。
用戶友好性：如果有人進入洞穴五年后再回來，他們不應該失去對其ETH、ERC20、NFT、CDP頭寸的訪問權限……
開發者友好性：開發人員不必切換到完全陌生的思維模型。此外，如今僵化且不更新的應用程序應該繼續合理地運行。
無需滿足這些目標，問題也很容易解決。例如，您可以讓每個狀態對象還存儲一個計數器來記錄其到期日期（可以通過銷毀ETH來延長，這可以在讀取或寫入時自動發生），并有一個循環遍歷狀態以刪除過期狀態對象的過程。但是，這引入了額外的計算（甚至存儲要求），并且肯定不能滿足用戶友好性要求。開發人員也很難推理涉及存儲值有時重置為零的極端情況。如果您將到期計時器設為合約范圍內，這在技術上使開發人員的工作變得更容易，但會使經濟變得更加困難：開發人員必須考慮如何將持續的存儲成本“轉嫁”給他們的用戶。
這些都是Ethereum核心開發社區多年來一直在努力解決的問題，包括“Blockchain租金”和“再生”等提案。最終，我們結合了提案中最好的部分，并集中于兩類“已知最不壞的解決方案”：
部分狀態到期解決方案。
基于地址周期的狀態到期提案。部分狀態過期
部分狀態過期提案都遵循相同的原則。我們將狀態分成塊。每個人都永久存儲“頂層映射”，其中哪些塊是空的或非空的。每個塊中的數據僅在最近訪問過的情況下才會存儲。有一個“復活”機制，如果某個塊不再存儲，任何人都可以通過提供數據是什么的證明來恢復該數據。
這些提案之間的主要區別是：（i）我們如何定義“最近”，以及（ii）我們如何定義“塊”？一個具體的提案是EIP-7736，它建立在為Verkle樹引入的“莖葉”設計之上（盡管與任何形式的無狀態樹兼容，例如二叉樹）。在這種設計中，彼此相鄰的標頭、代碼和存儲槽存儲在同一個“莖”下。存儲在莖下的數據最多可以是256*31=7,936字節。在許多情況下，賬戶的整個標題和代碼以及許多密鑰存儲槽都將存儲在同一個主干下。如果給定主干下的數據在6個月內未被讀取或寫入，則不再存儲數據，而是只存儲對數據的32字節承諾（“存根”）。未來訪問該數據的交易將需要“復活”數據，并提供與存根核對的證明。
這種設計保留了Ethereum的大部分當前屬性，額外計算量非常小，允許應用程序幾乎像現在一樣編寫（ERC20需要重寫，以確保地址周期為N的地址的余額存儲在本身具有地址周期N的子合約中），并解決了“用戶進入洞穴五年”的問題。然而，它有一個大問題：地址需要擴展到20個字節以上才能適合地址周期。地址空間擴展
一項提議是引入一種新的32字節地址格式，其中包括版本號、地址周期號和擴展哈希值。
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
紅色是版本號。此處橙色的四個零表示空白，將來可以容納分片號。綠色是地址周期號。藍色是26字節哈希值。
此處的關鍵挑戰是向后兼容性。現有合約是圍繞20字節地址設計的，并且通常使用緊密字節打包技術，明確假設地址正好是20字節長。解決這個問題的一個想法是使用轉換圖，其中與新式地址交互的舊式合約將看到新式地址的20字節哈希值。但是，要確保其安全，需要付出相當大的努力。地址空間收縮
另一種方法則相反：我們立即禁止一些2128大小的地址子范圍（例如所有以0xffffffff開頭的地址），然后使用該范圍引入帶有地址周期和14字節哈希值的地址。
0xffffffff000169125d5dFcb7B8C2659029395bdF
這種方法做出的關鍵犧牲是，它為反事實地址引入了安全風險：持有資產或權限但其代碼尚未發布到鏈上的地址。風險涉及有人創建一個地址，該地址聲稱擁有一段（尚未發布的）代碼，但還有另一段有效代碼，該代碼的哈希值指向同一地址。計算這樣的碰撞今天需要280個哈希值；地址空間收縮將把這個數字減少到非常容易獲得的256個哈希值。
關鍵風險領域，不是由單個所有者持有的錢包的反事實地址，在今天是一種相對罕見的情況，但隨著我們進入多L2世界，這種情況可能會變得更加普遍。唯一的解決方案是簡單地接受這種風險，但要確定所有可能出現問題的常見用例，并提出有效的解決方法。現有哪些研究？
早期提案
Blockchain租用費：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
Ethereum狀態大小管理理論：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還剩下什么要做？需要權衡什么？
我認為未來有四條可行的路徑：
我們實行無狀態，并且從不引入狀態過期。狀態在不斷增長（盡管增長緩慢：幾十年內我們可能都不會看到它超過8TB），但只需要由相對專業的用戶類別持有：甚至PoS驗證者也不需要狀態。
需要訪問部分狀態的一個功能是包含列表生成，但我們可以以分散的方式實現這一點：每個用戶負責維護包含自己賬戶的狀態樹部分。當他們廣播交易時，他們會廣播在驗證步驟期間訪問的狀態對象的證明（這適用于EOA和ERC-4337賬戶）。然后，無狀態驗證者可以將這些證明組合成整個包含列表的證明。
我們實行部分狀態過期，并接受低得多但仍非零的永久狀態大小增長率。這種結果可能類似于涉及對等網絡的歷史到期提案，該提案接受每個客戶端必須存儲較低但固定百分比的歷史數據的永久歷史存儲增長率，但增長率要低得多，但仍然不為零。
我們確實聲明了到期日期，并擴展了地址空間。這將涉及一個多年的過程，以確保地址格式轉換方法有效且安全，包括對于現有應用程序。
我們確實聲明了到期日期，并收縮了地址空間。這將涉及一個多年的過程，以確保處理涉及地址沖突（包括跨鏈情況）的所有安全風險。
一個重要的點是，無論是否實施依賴于地址格式更改的狀態到期方案，最終都必須解決地址空間擴展和收縮的難題。今天，大約需要2^80個哈希才能產生地址沖突，對于資源極其豐富的參與者來說，這種計算負荷已經是可行的：GPU可以進行大約2^27個哈希，因此運行一年可以計算2^52個，因此世界上所有約2^30個GPU可以在約1/4年的時間內計算出沖突，而FPGA和ASIC可以進一步加速這一過程。未來，此類攻擊將對越來越多的人開放。因此，實施完整狀態到期的實際成本可能沒有看起來那么高，因為無論如何我們都必須解決這個非常具有挑戰性的地址問題。它如何與路線圖的其他部分互動？
執行狀態到期可能會使從一種狀態樹格式到另一種狀態樹格式的轉換變得更容易，因為不需要轉換過程：您可以簡單地開始使用新格式制作新樹，然后稍后進行硬分叉以轉換舊樹。因此，雖然狀態到期很復雜，但它確實有助于簡化路線圖的其他方面。功能清理它解決了什么問題？
安全性、可訪問性和可信中立性的關鍵先決條件之一是簡單性。如果協議美觀且簡單，則出現錯誤的可能性就會降低。它增加了新開發人員能夠加入并使用它的任何部分的機會。它更有可能是公平的，并且更容易抵御特殊利益。不幸的是，協議與任何社會系統一樣，默認情況下會隨著時間的推移變得更加復雜。如果我們不想讓Ethereum陷入日益復雜的黑洞，我們需要做以下兩件事之一：（i）停止進行更改并使協議僵化，（ii）能夠實際刪除功能并降低復雜性。中間路線，即對協議進行較少的更改，同時隨著時間的推移至少消除一點復雜性，也是可能的。本節將討論如何減少或消除復雜性。它是什么？它是如何工作的？
沒有一個大的單一修復可以降低協議復雜性；問題的本質是存在許多小修復。
一個基本已經完成的例子，可以作為如何處理其他問題的藍圖，即刪除SELFDESTRUCT操作碼。SELFDESTRUCT操作碼是唯一可以修改單個塊內無限數量的存儲槽的操作碼，需要客戶端實現更大的復雜性以避免DoS攻擊。該操作碼的最初目的是實現自愿狀態清除，允許狀態大小隨著時間的推移而減少。實際上，很少有人最終使用它。該操作碼被削弱，只允許在Dencun硬分叉中在同一筆交易中創建的自毀賬戶。這解決了DoS問題，并允許顯著簡化客戶端代碼。將來，最終完全刪除該操作碼可能是有意義的。
迄今為止已確定的一些協議簡化機會的關鍵示例包括以下內容。首先，一些EVM之外的示例；這些示例相對非侵入性，因此更容易達成共識并在更短的時間內實施。
RLP→SSZ轉換：最初，Ethereum對象使用一種稱為RLP的編碼進行序列化。如今，信標鏈使用SSZ，它在許多方面都明顯更好，包括不僅支持序列化，還支持哈希。最終，我們希望完全擺脫RLP，并將所有數據類型移至SSZ結構，這反過來會使升級變得更加容易。目前為此提出的EIP包括[1][2][3]。
刪除舊交易類型：如今的交易類型太多，其中許多類型可能會被刪除。完全刪除的一個更溫和的替代方案是賬戶抽象功能，通過該功能，智能賬戶可以包含處理和驗證舊式交易的代碼（如果它們愿意的話）。
LOG改革：日志創建bloom過濾器和其他邏輯，增加了協議的復雜性，但由于速度太慢，客戶端實際上不會使用它。我們可以刪除這些功能，而是將精力投入到替代方案中，例如使用SNARK等現代技術的協議外Decentralization日志讀取工具。
最終取消信標鏈同步委員會機制：同步委員會機制最初是為了實現Ethereum的輕客戶端驗證而引入的。然而，它增加了協議的復雜性。最終，我們將能夠使用SNARK直接驗證Ethereum共識層，這將消除對專用輕客戶端驗證協議的需求。通過創建更“原生”的輕客戶端協議，該協議涉及驗證來自Ethereum共識驗證器隨機子集的簽名。
數據格式協調：今天，執行狀態存儲在MerklePatricia樹中，共識狀態存儲在SSZ樹中，并且blob以KZG承諾的形式提交。在未來，為區塊數據和狀態創建單一統一格式是有意義的。這些格式將涵蓋所有重要需求：(i)無狀態客戶端的簡單證明，(ii)數據的序列化和擦除編碼，(iii)標準化數據結構。
刪除信標鏈委員會：最初引入此機制是為了支持特定版本的執行分片。相反，我們最終通過L2和blob進行分片。因此，委員會是不必要的，因此正在努力將其刪除。
刪除混合字節序：EVM是大端字節序，共識層是小端字節序。重新協調并使所有內容都為大端字節序（可能是大端字節序，因為EVM更難更改）可能是有意義的。
現在，EVM內部的一些示例：
簡化gas機制：當前的gas規則尚未得到很好的優化，無法明確限制驗證區塊所需的資源數量。這方面的關鍵示例包括(i)存儲讀/寫成本，旨在限制區塊中的讀/寫次數，但目前非常隨意，以及(ii)內存填充規則，目前很難估計EVM的最大內存消耗。建議的修復包括無狀態gas成本更改，將所有與存儲相關的成本協調為一個簡單的公式，以及內存定價建議。
刪除預編譯：Ethereum當今擁有的許多預編譯既不必要地復雜又相對未使用，并且占共識失敗險情的很大比例，但實際上并未被任何應用程序使用。處理此問題的兩種方法是(i)直接刪除預編譯，以及(ii)用實現相同邏輯的（不可避免地更昂貴的）EVM代碼替換它。此EIP草案建議首先對身份預編譯執行此操作；稍后，RIPEMD160、MODEXP和BLAKE可能會被刪除。
刪除gas可觀察性：使EVM執行不再能夠看到它還剩下多少gas。這會破壞一些應用程序（最明顯的是贊助交易），但將來可以更輕松地進行升級（例如，對于更高級的多維gas版本）。EOF規范已經使gas不可觀察，但為了有助于協議簡化，EOF需要成為強制性的。
靜態分析的改進：今天的EVM代碼很難進行靜態分析，特別是因為跳轉可以是動態的。這也使得制作優化的EVM實現（將EVM代碼預編譯成其他語言）變得更加困難。我們可以通過刪除動態跳轉（或使它們更加昂貴，例如，gas成本與合約中JUMPDEST的總數成線性關系）來解決這個問題。EOF就是這樣做的，但從中獲得協議簡化收益需要使EOF成為強制性的。現有哪些研究？
Purge的后續步驟：https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
SELFDESTRUCT：https://hackmd.io/@vbuterin/selfdestruct
SSZ-ificationEIPS：[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)向后兼容性。Ethereum作為一條鏈的價值在于它是一個平臺，您可以在其中部署應用程序并確信它在多年后仍能正常工作。與此同時，也有可能將這一理想發揮得太過，用威廉·詹寧斯·布萊恩的話來說，“將Ethereum釘在向后兼容性的十字架上”。如果整個Ethereum中只有兩個應用程序使用某個功能，其中一個多年來沒有用戶，而另一個幾乎完全沒有使用，并且總共獲得了57美元的價值，那么我們應該刪除該功能，如果需要，可以自掏腰包向受害者支付57美元。
更廣泛的社會問題是創建一個標準化的管道，用于進行非緊急的向后兼容性破壞性更改。解決此問題的一種方法是檢查和擴展現有先例，例如SELFDESTRUCT流程。該管道看起來如下所示：
步驟1：開始討論刪除功能X。
步驟2：進行分析以確定刪除X對應用程序的破壞程度，根據結果，選擇(i)放棄這個想法，(ii)按計劃進行，或(iii)確定一種經過修改的“破壞性最小”的刪除X的方法并繼續進行。
步驟3：制定正式的EIP以棄用X。確保流行的高級基礎設施（例如編程語言、錢包）尊重這一點并停止使用該功能。
步驟4：最后，實際刪除X。
在第1步和第4步之間應該有一個長達數年的流程，并明確說明哪些項目處于哪個步驟。此時，需要在功能移除流程的力度和速度與更為保守和將更多資源投入協議開發的其他領域之間進行權衡，但我們距離Pareto 前沿還很遠。EOF
針對EVM提出的一組主要更改是EVM對象格式(EOF)。EOF引入了大量更改，例如禁止gas可觀察性、代碼可觀察性（即無CODECOPY）、僅允許靜態跳轉。目標是允許EVM進行更多升級，以具有更強大的屬性，同時保持向后兼容性（因為EOF之前的EVM仍然存在）。
這樣做的好處是，它為添加新的EVM功能和鼓勵遷移到具有更強保證的更嚴格EVM創造了一條自然途徑。它的缺點是，它顯著增加了協議的復雜性，除非我們能找到最終棄用和刪除舊EVM的方法。一個主要問題是：EOF在EVM簡化提案中扮演什么角色，尤其是如果目標是降低整個EVM的復雜性？它如何與路線圖的其他部分互動？
路線圖其余部分中的許多“改進”提案也是簡化舊功能的機會。重復上面的一些例子：
切換到單槽終結性使我們有機會取消委員會、重新制定經濟學并進行其他與權益證明相關的簡化。
完全實現賬戶抽象讓我們可以刪除許多現有的交易處理邏輯，方法是將其移入一段“默認賬戶EVM代碼”，所有EOA都可以用它替換。
如果我們將Ethereum狀態移動到二進制哈希樹，這可以與新版本的SSZ協調一致，以便所有Ethereum數據結構都可以以相同的方式進行哈希處理。更激進的方法：將協議的大部分內容轉化為合約代碼
更激進的Ethereum簡化策略是保持協議原樣，但將協議的大部分內容從協議功能轉變為合約代碼。
最極端的版本是讓EthereumL1“技術上”只是信標鏈，并引入一個最小的VM（例如RISC-V、Cairo或專門用于證明系統的更簡單的VM），允許任何其他人創建自己的匯總。然后，EVM將成為這些匯總中的第一個。具有諷刺意味的是，這與2019-20年的執行環境提案的結果完全相同，盡管SNARK使其實際實施起來更加可行。
更溫和的方法是保持信標鏈與當前Ethereum執行環境之間的關系不變，但對EVM進行就地交換。我們可以選擇RISC-V、Cairo或其他VM作為新的“官方EthereumVM”，然后將所有EVM合約強制轉換為解釋原始代碼邏輯的新VM代碼（通過編譯或解釋）。從理論上講，甚至可以將“目標VM”作為EOF版本來完成此操作。
特別感謝JustinDrake、TimBeiko、MattGarnett、PiperMerriam、MariusvanderWijden和TomaszStanczak的反饋和評論。