Vitalik：以太坊協(xié)議可能的未來—The Purge

作者：以太坊創(chuàng)始人Vitalik；編譯：鄧通，金色財經(jīng)

按：本文為以太坊創(chuàng)始人Vitalik近期發(fā)表的“以太坊協(xié)議的未來發(fā)展”系列文章的第五部分“Possible futures of the Ethereum protocol, part 5: The Purge”，第四部分見“Vitalik：以太坊的未來The Verge”。第三部分見“Vitalik：以太坊The Scourge階段的關(guān)鍵目標(biāo)”，第二部分見“Vitalik：The Surge階段以太坊協(xié)議應(yīng)該怎么發(fā)展”，第一部分見“以太坊PoS還有哪些可以改進(jìn)”。以下為第五部分全文：

以太坊面臨的挑戰(zhàn)之一是，默認(rèn)情況下，任何區(qū)塊鏈協(xié)議的膨脹和復(fù)雜性都會隨著時間的推移而增加。這發(fā)生在兩個方面：

歷史數(shù)據(jù)：任何交易和任何歷史時刻創(chuàng)建的任何賬戶都需要由所有客戶端永久存儲，并由任何與網(wǎng)絡(luò)完全同步的新客戶端下載。這會導(dǎo)致客戶端負(fù)載和同步時間隨著時間的推移而不斷增加，即使鏈的容量保持不變。

協(xié)議功能：添加新功能比刪除舊功能容易得多，導(dǎo)致代碼復(fù)雜性隨著時間的推移而增加。

為了使以太坊能夠長期維持下去，我們需要對這兩種趨勢施加強(qiáng)大的反壓力，隨著時間的推移減少復(fù)雜性和臃腫。但與此同時，我們需要保留區(qū)塊鏈的一大關(guān)鍵屬性：持久性。你可以把 NFT、交易調(diào)用數(shù)據(jù)中的情書或包含一百萬美元的智能合約放在鏈上，進(jìn)入一個山洞十年，出來后發(fā)現(xiàn)它仍然在那里等著你閱讀和互動。為了讓 dapp 放心地完全去中心化并刪除升級密鑰，他們需要確信他們的依賴項不會以破壞它們的方式升級——尤其是 L1 本身。

The Purge, 2023 年路線圖

如果我們專心致志，在這兩種需求之間取得平衡，在保持連續(xù)性的同時盡量減少或扭轉(zhuǎn)膨脹、復(fù)雜性和衰退，是絕對可能的。生物體可以做到這一點：雖然大多數(shù)生物體會隨著時間推移而衰老，但幸運的是少數(shù)生物體不會衰老。即使是社會系統(tǒng)也可以擁有極長的壽命。在一些情況下，以太坊已經(jīng)取得了成功：工作量證明已經(jīng)消失，SELFDESTRUCT 操作碼基本消失，信標(biāo)鏈節(jié)點已經(jīng)存儲舊數(shù)據(jù)最多六個月。以更普遍的方式為以太坊找到這條道路，并朝著長期穩(wěn)定的最終結(jié)果邁進(jìn)，這是以太坊長期可擴(kuò)展性、技術(shù)可持續(xù)性甚至安全性的終極挑戰(zhàn)。

The Purge：主要目標(biāo)

通過減少或消除每個節(jié)點永久存儲所有歷史記錄的需求來減少客戶端存儲要求，甚至可能最終聲明

通過消除不需要的功能來降低協(xié)議復(fù)雜性

歷史數(shù)據(jù)過期

它解決了什么問題？

截至撰寫本文時，完全同步的以太坊節(jié)點需要大約 1.1 TB 的磁盤空間用于執(zhí)行客戶端，另外還需要幾百 GB 的空間用于共識客戶端。其中絕大部分是歷史數(shù)據(jù)：有關(guān)歷史區(qū)塊、交易和收據(jù)的數(shù)據(jù)，其中大部分都是多年前的數(shù)據(jù)。這意味著即使 gas 限制根本沒有增加，節(jié)點的大小每年也會增加數(shù)百 GB。

它是什么？它是如何工作的？

歷史存儲問題的一個關(guān)鍵簡化特性是，由于每個塊通過哈希鏈接（和其他結(jié)構(gòu)）指向前一個塊，因此對當(dāng)前達(dá)成共識就足以對歷史達(dá)成共識。只要網(wǎng)絡(luò)對最新塊達(dá)成共識，任何歷史塊、交易或狀態(tài)（賬戶余額、隨機(jī)數(shù)、代碼、存儲）都可以由任何單個參與者提供，并附帶 Merkle 證明，并且該證明允許任何其他人驗證其正確性。雖然共識是 N/2-of-N 信任模型，但歷史是 1-of-N 信任模型。

這為我們存儲歷史記錄的方式開辟了很多選擇。一個自然的選擇是每個節(jié)點僅存儲一小部分?jǐn)?shù)據(jù)的網(wǎng)絡(luò)。這就是 torrent 網(wǎng)絡(luò)幾十年來的工作方式：雖然網(wǎng)絡(luò)總共存儲和分發(fā)數(shù)百萬個文件，但每個參與者只存儲和分發(fā)其中的幾個。也許違反直覺，這種方法甚至不一定會降低數(shù)據(jù)的穩(wěn)健性。如果通過降低節(jié)點運行成本，我們可以實現(xiàn)一個擁有 100,000 個節(jié)點的網(wǎng)絡(luò)，其中每個節(jié)點隨機(jī)存儲 10% 的歷史記錄，那么每條數(shù)據(jù)將被復(fù)制 10,000 次 —— 與每個節(jié)點存儲所有內(nèi)容的 10,000 個節(jié)點網(wǎng)絡(luò)的復(fù)制因子完全相同。

今天，以太坊已經(jīng)開始擺脫所有節(jié)點永久存儲所有歷史記錄的模型。共識區(qū)塊（即與權(quán)益證明共識相關(guān)的部分）僅存儲約 6 個月。Blob 僅存儲約 18 天。EIP-4444 旨在為歷史區(qū)塊和收據(jù)引入一年的存儲期。長期目標(biāo)是有一個協(xié)調(diào)的時期（可能是約 18 天），在此期間每個節(jié)點負(fù)責(zé)存儲所有內(nèi)容，然后有一個由以太坊節(jié)點組成的對等網(wǎng)絡(luò)，以分布式方式存儲舊數(shù)據(jù)。

可以使用糾刪碼來提高穩(wěn)健性，同時保持復(fù)制因子不變。事實上，為了支持?jǐn)?shù)據(jù)可用性采樣，blob 已經(jīng)采用糾刪碼。最簡單的解決方案可能是重新使用此糾刪碼，并將執(zhí)行和共識塊數(shù)據(jù)也放入 blob 中。

現(xiàn)有哪些研究？

EIP-4444：https://eips.ethereum.org/EIPS/eip-4444

Torrents 和 EIP-4444：https://ethresear.ch/t/torrents-and-eip-4444/19788

Portal 網(wǎng)絡(luò)：https://ethereum.org/en/developers/docs/networking-layer/portal-network/

Portal 網(wǎng)絡(luò)和 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

剩下要做什么，又有哪些權(quán)衡？

剩下的主要工作涉及構(gòu)建和集成一個具體的分布式解決方案來存儲歷史記錄 —— 至少是執(zhí)行歷史記錄，但最終也包括共識和 blob。最簡單的解決方案是 (i) 簡單地引入現(xiàn)有的 torrent 庫，以及 (ii) 一個名為 Portal 網(wǎng)絡(luò)的以太坊原生解決方案。一旦引入其中任何一個，我們就可以啟用 EIP-4444。EIP-4444 本身不需要硬分叉，但它確實需要一個新的網(wǎng)絡(luò)協(xié)議版本。因此，同時為所有客戶端啟用它是有價值的，因為否則客戶端可能會因連接到其他節(jié)點而出現(xiàn)故障，這些節(jié)點期望下載完整的歷史記錄但實際上并沒有實現(xiàn)。

主要的權(quán)衡涉及我們?nèi)绾闻κ埂按饲啊睔v史數(shù)據(jù)可用。最簡單的解決方案是明天停止存儲此前數(shù)據(jù)，并依靠現(xiàn)有的存檔節(jié)點和各種中心化提供商進(jìn)行復(fù)制。這很容易，但這削弱了以太坊作為記錄永久數(shù)據(jù)的地位。更難但更安全的方法是首先構(gòu)建和集成 torrent 網(wǎng)絡(luò)，以分布式方式存儲歷史記錄。這里“我們有多努力”有兩個維度：

我們要多努力才能確保最大數(shù)量的節(jié)點確實存儲了所有數(shù)據(jù)？

我們將歷史存儲與協(xié)議的集成程度有多深？

對于 (1) 來說，最嚴(yán)謹(jǐn)?shù)姆椒▽⑸婕氨９茏C明：實際上要求每個權(quán)益證明驗證者存儲一定比例的歷史記錄，并定期通過加密方式檢查他們是否這樣做。更溫和的方法是為每個客戶端存儲的歷史記錄百分比設(shè)定一個自愿標(biāo)準(zhǔn)。

對于 (2)，基本實現(xiàn)僅涉及今天已經(jīng)完成的工作：Portal 已經(jīng)存儲了包含整個以太坊歷史記錄的 ERA 文件。更徹底的實現(xiàn)將涉及將其實際連接到同步過程，這樣如果有人想要同步完整歷史記錄存儲節(jié)點或存檔節(jié)點，即使沒有其他存檔節(jié)點在線，他們也可以通過直接從 Portal 網(wǎng)絡(luò)同步來執(zhí)行此操作。

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

如果我們想讓節(jié)點的運行或啟動變得極其簡單，那么減少歷史存儲要求可以說比無狀態(tài)更重要：在節(jié)點需要的 1.1 TB 中，約 300 GB 是狀態(tài)，其余約 800 GB 是歷史。以太坊節(jié)點在智能手表上運行且只需幾分鐘即可設(shè)置的愿景只有在同時實現(xiàn)無狀態(tài)和 EIP-4444 的情況下才能實現(xiàn)。

限制歷史存儲也使較新的以太坊節(jié)點實現(xiàn)更可行地僅支持協(xié)議的最新版本，這使它們變得更加簡單。例如，由于 2016 年 DoS 攻擊期間創(chuàng)建的空存儲槽已全部被刪除，因此可以安全地刪除許多代碼行。既然切換到權(quán)益證明已成為歷史，客戶端可以安全地刪除所有與工作量證明相關(guān)的代碼。

狀態(tài)數(shù)據(jù)過期

它解決了什么問題？

即使我們消除了客戶端存儲歷史記錄的需求，客戶端的存儲需求仍將繼續(xù)增長，每年約 50 GB，因為狀態(tài)不斷增長：賬戶余額和隨機(jī)數(shù)、合約代碼和合約存儲。用戶可以支付一次性費用，永遠(yuǎn)給現(xiàn)在和未來的以太坊客戶端帶來負(fù)擔(dān)。

狀態(tài)比歷史記錄更難“過期”，因為 EVM 的設(shè)計基本假設(shè)是，一旦創(chuàng)建了狀態(tài)對象，它將永遠(yuǎn)存在，并且可以隨時被任何交易讀取。如果我們引入無狀態(tài)，有人認(rèn)為這個問題可能沒那么糟糕：只有一類專門的區(qū)塊構(gòu)建器才需要實際存儲狀態(tài)，所有其他節(jié)點（甚至包含列表生成！）都可以無狀態(tài)運行。然而，有人認(rèn)為我們不想過分依賴無狀態(tài)，最終我們可能希望狀態(tài)過期以保持以太坊的去中心化。

它是什么？它是如何工作的？

今天，當(dāng)你創(chuàng)建一個新的狀態(tài)對象時（可以通過以下三種方式之一進(jìn)行：（i）將 ETH 發(fā)送到新賬戶，（ii）使用代碼創(chuàng)建新賬戶，（iii）設(shè)置以前未觸及的存儲槽），該狀態(tài)對象將永遠(yuǎn)處于該狀態(tài)。相反，我們想要的是對象隨著時間的推移自動過期。關(guān)鍵挑戰(zhàn)是以一種實現(xiàn)三個目標(biāo)的方式來做到這一點：

效率：不需要大量額外的計算來運行到期流程。

用戶友好性：如果有人進(jìn)入洞穴五年后再回來，他們不應(yīng)該失去對其 ETH、ERC20、NFT、CDP 頭寸的訪問權(quán)限……

開發(fā)者友好性：開發(fā)人員不必切換到完全陌生的思維模型。此外，如今僵化且不更新的應(yīng)用程序應(yīng)該繼續(xù)合理地運行。

無需滿足這些目標(biāo)，問題也很容易解決。例如，您可以讓每個狀態(tài)對象還存儲一個計數(shù)器來記錄其到期日期（可以通過銷毀 ETH 來延長，這可以在讀取或?qū)懭霑r自動發(fā)生），并有一個循環(huán)遍歷狀態(tài)以刪除過期狀態(tài)對象的過程。但是，這引入了額外的計算（甚至存儲要求），并且肯定不能滿足用戶友好性要求。開發(fā)人員也很難推理涉及存儲值有時重置為零的極端情況。如果您將到期計時器設(shè)為合約范圍內(nèi)，這在技術(shù)上使開發(fā)人員的工作變得更容易，但會使經(jīng)濟(jì)變得更加困難：開發(fā)人員必須考慮如何將持續(xù)的存儲成本“轉(zhuǎn)嫁”給他們的用戶。

這些都是以太坊核心開發(fā)社區(qū)多年來一直在努力解決的問題，包括“區(qū)塊鏈租金”和“再生”等提案。最終，我們結(jié)合了提案中最好的部分，并集中于兩類“已知最不壞的解決方案”：

部分狀態(tài)到期解決方案。

基于地址周期的狀態(tài)到期提案。

部分狀態(tài)過期

部分狀態(tài)過期提案都遵循相同的原則。我們將狀態(tài)分成塊。每個人都永久存儲“頂層映射”，其中哪些塊是空的或非空的。每個塊中的數(shù)據(jù)僅在最近訪問過的情況下才會存儲。有一個“復(fù)活”機(jī)制，如果某個塊不再存儲，任何人都可以通過提供數(shù)據(jù)是什么的證明來恢復(fù)該數(shù)據(jù)。

這些提案之間的主要區(qū)別是：（i）我們?nèi)绾味x“最近”，以及（ii）我們?nèi)绾味x“塊”？一個具體的提案是 EIP-7736，它建立在為 Verkle 樹引入的“莖葉”設(shè)計之上（盡管與任何形式的無狀態(tài)樹兼容，例如二叉樹）。在這種設(shè)計中，彼此相鄰的標(biāo)頭、代碼和存儲槽存儲在同一個“莖”下。存儲在莖下的數(shù)據(jù)最多可以是 256 * 31 = 7,936 字節(jié)。在許多情況下，賬戶的整個標(biāo)題和代碼以及許多密鑰存儲槽都將存儲在同一個主干下。如果給定主干下的數(shù)據(jù)在 6 個月內(nèi)未被讀取或?qū)懭耄瑒t不再存儲數(shù)據(jù)，而是只存儲對數(shù)據(jù)的 32 字節(jié)承諾（“存根”）。未來訪問該數(shù)據(jù)的交易將需要“復(fù)活”數(shù)據(jù)，并提供與存根核對的證明。

還有其他方法可以實現(xiàn)類似的想法。例如，如果賬戶間隔不夠，我們可以制定一個方案，其中樹的每個 1/232 部分都由類似的莖葉機(jī)制控制。

由于激勵因素，這更加棘手：攻擊者可以通過將大量數(shù)據(jù)放入單個子樹并每年發(fā)送單個交易來“更新樹”，從而迫使客戶端永久存儲大量狀態(tài)。如果使更新成本與樹大小成比例（或更新持續(xù)時間與樹大小成反比），那么有人可能會通過將大量數(shù)據(jù)放入與他們相同的子樹中來傷害另一個用戶。可以嘗試通過根據(jù)子樹大小使賬戶間隔動態(tài)化來限制這兩個問題：例如，每個連續(xù)的 2^16 = 65536 個狀態(tài)對象可以被視為一個“組”。然而，這些想法更復(fù)雜；基于詞干的方法很簡單，并且可以協(xié)調(diào)激勵措施，因為通常詞干下的所有數(shù)據(jù)都與同一個應(yīng)用程序或用戶相關(guān)。

基于地址周期的狀態(tài)過期提案

如果我們想完全避免任何永久性的狀態(tài)增長，即使是 32 字節(jié)的存根，該怎么辦？這是一個難題：如果狀態(tài)對象被刪除，稍后的 EVM 執(zhí)行將另一個狀態(tài)對象放在完全相同的位置，但之后關(guān)心原始狀態(tài)對象的人回來并試圖恢復(fù)它，該怎么辦？對于部分狀態(tài)過期，“存根”會阻止創(chuàng)建新數(shù)據(jù)。對于完整狀態(tài)過期，我們甚至無法存儲存根。

基于地址周期的設(shè)計是解決此問題的最佳方法。我們有一個不斷增長的狀態(tài)樹列表，而不是用一棵狀態(tài)樹存儲整個狀態(tài)，并且任何讀取或?qū)懭氲臓顟B(tài)都會保存在最新的狀態(tài)樹中。每周期（想想：1 年）添加一次新的空狀態(tài)樹。較舊的狀態(tài)樹是固定的。完整節(jié)點只需要存儲最近的兩棵樹。如果狀態(tài)對象在兩個周期內(nèi)未被觸及并因此落入過期樹，它仍然可以被讀取或?qū)懭耄灰仔枰獮槠渥C明 Merkle 證明 —— 一旦這樣做，副本將再次保存在最新的樹中。

使這一切對用戶和開發(fā)人員友好的一個關(guān)鍵思想是地址周期的概念。地址周期是地址的一部分的數(shù)字。一個關(guān)鍵規(guī)則是，地址周期為 N 的地址只能在周期 N 期間或之后讀取或?qū)懭耄串?dāng)狀態(tài)樹列表達(dá)到長度 N 時）。如果您要保存新的狀態(tài)對象（例如，新合約或新的 ERC20 余額），如果您確保將狀態(tài)對象放入地址周期為 N 或 N-1 的合約中，那么您可以立即保存它，而無需提供之前沒有任何內(nèi)容的證明。另一方面，對舊地址周期中的任何狀態(tài)添加或編輯都需要證明。

這種設(shè)計保留了以太坊的大部分當(dāng)前屬性，額外計算量非常小，允許應(yīng)用程序幾乎像現(xiàn)在一樣編寫（ERC20 需要重寫，以確保地址周期為 N 的地址的余額存儲在本身具有地址周期 N 的子合約中），并解決了“用戶進(jìn)入洞穴五年”的問題。然而，它有一個大問題：地址需要擴(kuò)展到 20 個字節(jié)以上才能適合地址周期。

地址空間擴(kuò)展

一項提議是引入一種新的 32 字節(jié)地址格式，其中包括版本號、地址周期號和擴(kuò)展哈希值。

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

紅色是版本號。此處橙色的四個零表示空白，將來可以容納分片號。綠色是地址周期號。藍(lán)色是 26 字節(jié)哈希值。

此處的關(guān)鍵挑戰(zhàn)是向后兼容性。現(xiàn)有合約是圍繞 20 字節(jié)地址設(shè)計的，并且通常使用緊密字節(jié)打包技術(shù)，明確假設(shè)地址正好是 20 字節(jié)長。解決這個問題的一個想法是使用轉(zhuǎn)換圖，其中與新式地址交互的舊式合約將看到新式地址的 20 字節(jié)哈希值。但是，要確保其安全，需要付出相當(dāng)大的努力。

地址空間收縮

另一種方法則相反：我們立即禁止一些 2128 大小的地址子范圍（例如所有以 0xffffffff 開頭的地址），然后使用該范圍引入帶有地址周期和 14 字節(jié)哈希值的地址。

0xffffffff000169125d5dFcb7B8C2659029395bdF

這種方法做出的關(guān)鍵犧牲是，它為反事實地址引入了安全風(fēng)險：持有資產(chǎn)或權(quán)限但其代碼尚未發(fā)布到鏈上的地址。風(fēng)險涉及有人創(chuàng)建一個地址，該地址聲稱擁有一段（尚未發(fā)布的）代碼，但還有另一段有效代碼，該代碼的哈希值指向同一地址。計算這樣的碰撞今天需要 280 個哈希值；地址空間收縮將把這個數(shù)字減少到非常容易獲得的 256 個哈希值。

關(guān)鍵風(fēng)險領(lǐng)域，不是由單個所有者持有的錢包的反事實地址，在今天是一種相對罕見的情況，但隨著我們進(jìn)入多 L2 世界，這種情況可能會變得更加普遍。唯一的解決方案是簡單地接受這種風(fēng)險，但要確定所有可能出現(xiàn)問題的常見用例，并提出有效的解決方法。

現(xiàn)有哪些研究？

早期提案

區(qū)塊鏈租用費：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

以太坊狀態(tài)大小管理理論：https://hackmd.io/@vbuterin/state_size_management

無狀態(tài)和狀態(tài)過期的幾種可能路徑：https://hackmd.io/@vbuterin/state_expiry_paths

部分狀態(tài)過期提案

EIP-7736：https://eips.ethereum.org/EIPS/eip-7736

地址空間擴(kuò)展文檔

原始提案：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

如果我們失去碰撞阻力會發(fā)生什么：https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

還剩下什么要做？需要權(quán)衡什么？

我認(rèn)為未來有四條可行的路徑：

我們實行無狀態(tài)，并且從不引入狀態(tài)過期。狀態(tài)在不斷增長（盡管增長緩慢：幾十年內(nèi)我們可能都不會看到它超過 8 TB），但只需要由相對專業(yè)的用戶類別持有：甚至 PoS 驗證者也不需要狀態(tài)。

需要訪問部分狀態(tài)的一個功能是包含列表生成，但我們可以以分散的方式實現(xiàn)這一點：每個用戶負(fù)責(zé)維護(hù)包含自己賬戶的狀態(tài)樹部分。當(dāng)他們廣播交易時，他們會廣播在驗證步驟期間訪問的狀態(tài)對象的證明（這適用于 EOA 和 ERC-4337 賬戶）。然后，無狀態(tài)驗證者可以將這些證明組合成整個包含列表的證明。

我們實行部分狀態(tài)過期，并接受低得多但仍非零的永久狀態(tài)大小增長率。這種結(jié)果可能類似于涉及對等網(wǎng)絡(luò)的歷史到期提案，該提案接受每個客戶端必須存儲較低但固定百分比的歷史數(shù)據(jù)的永久歷史存儲增長率，但增長率要低得多，但仍然不為零。

我們確實聲明了到期日期，并擴(kuò)展了地址空間。這將涉及一個多年的過程，以確保地址格式轉(zhuǎn)換方法有效且安全，包括對于現(xiàn)有應(yīng)用程序。

我們確實聲明了到期日期，并收縮了地址空間。這將涉及一個多年的過程，以確保處理涉及地址沖突（包括跨鏈情況）的所有安全風(fēng)險。

一個重要的點是，無論是否實施依賴于地址格式更改的狀態(tài)到期方案，最終都必須解決地址空間擴(kuò)展和收縮的難題。今天，大約需要 2^80 個哈希才能產(chǎn)生地址沖突，對于資源極其豐富的參與者來說，這種計算負(fù)荷已經(jīng)是可行的：GPU 可以進(jìn)行大約 2^27 個哈希，因此運行一年可以計算 2^52 個，因此世界上所有約 2^30 個 GPU 可以在約 1/4 年的時間內(nèi)計算出沖突，而 FPGA 和 ASIC 可以進(jìn)一步加速這一過程。未來，此類攻擊將對越來越多的人開放。因此，實施完整狀態(tài)到期的實際成本可能沒有看起來那么高，因為無論如何我們都必須解決這個非常具有挑戰(zhàn)性的地址問題。

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

執(zhí)行狀態(tài)到期可能會使從一種狀態(tài)樹格式到另一種狀態(tài)樹格式的轉(zhuǎn)換變得更容易，因為不需要轉(zhuǎn)換過程：您可以簡單地開始使用新格式制作新樹，然后稍后進(jìn)行硬分叉以轉(zhuǎn)換舊樹。因此，雖然狀態(tài)到期很復(fù)雜，但它確實有助于簡化路線圖的其他方面。

功能清理

它解決了什么問題？

安全性、可訪問性和可信中立性的關(guān)鍵先決條件之一是簡單性。如果協(xié)議美觀且簡單，則出現(xiàn)錯誤的可能性就會降低。它增加了新開發(fā)人員能夠加入并使用它的任何部分的機(jī)會。它更有可能是公平的，并且更容易抵御特殊利益。不幸的是，協(xié)議與任何社會系統(tǒng)一樣，默認(rèn)情況下會隨著時間的推移變得更加復(fù)雜。如果我們不想讓以太坊陷入日益復(fù)雜的黑洞，我們需要做以下兩件事之一：（i）停止進(jìn)行更改并使協(xié)議僵化，（ii）能夠?qū)嶋H刪除功能并降低復(fù)雜性。中間路線，即對協(xié)議進(jìn)行較少的更改，同時隨著時間的推移至少消除一點復(fù)雜性，也是可能的。本節(jié)將討論如何減少或消除復(fù)雜性。

它是什么？它是如何工作的？

沒有一個大的單一修復(fù)可以降低協(xié)議復(fù)雜性；問題的本質(zhì)是存在許多小修復(fù)。

一個基本已經(jīng)完成的例子，可以作為如何處理其他問題的藍(lán)圖，即刪除 SELFDESTRUCT 操作碼。SELFDESTRUCT 操作碼是唯一可以修改單個塊內(nèi)無限數(shù)量的存儲槽的操作碼，需要客戶端實現(xiàn)更大的復(fù)雜性以避免 DoS 攻擊。該操作碼的最初目的是實現(xiàn)自愿狀態(tài)清除，允許狀態(tài)大小隨著時間的推移而減少。實際上，很少有人最終使用它。該操作碼被削弱，只允許在 Dencun 硬分叉中在同一筆交易中創(chuàng)建的自毀賬戶。這解決了 DoS 問題，并允許顯著簡化客戶端代碼。將來，最終完全刪除該操作碼可能是有意義的。

迄今為止已確定的一些協(xié)議簡化機(jī)會的關(guān)鍵示例包括以下內(nèi)容。首先，一些 EVM 之外的示例；這些示例相對非侵入性，因此更容易達(dá)成共識并在更短的時間內(nèi)實施。

RLP → SSZ 轉(zhuǎn)換：最初，以太坊對象使用一種稱為 RLP 的編碼進(jìn)行序列化。如今，信標(biāo)鏈?zhǔn)褂?SSZ，它在許多方面都明顯更好，包括不僅支持序列化，還支持哈希。最終，我們希望完全擺脫 RLP，并將所有數(shù)據(jù)類型移至 SSZ 結(jié)構(gòu)，這反過來會使升級變得更加容易。目前為此提出的 EIP 包括 [1] [2] [3]。

刪除舊交易類型：如今的交易類型太多，其中許多類型可能會被刪除。完全刪除的一個更溫和的替代方案是賬戶抽象功能，通過該功能，智能賬戶可以包含處理和驗證舊式交易的代碼（如果它們愿意的話）。

LOG 改革：日志創(chuàng)建bloom過濾器和其他邏輯，增加了協(xié)議的復(fù)雜性，但由于速度太慢，客戶端實際上不會使用它。我們可以刪除這些功能，而是將精力投入到替代方案中，例如使用 SNARK 等現(xiàn)代技術(shù)的協(xié)議外去中心化日志讀取工具。

最終取消信標(biāo)鏈同步委員會機(jī)制：同步委員會機(jī)制最初是為了實現(xiàn)以太坊的輕客戶端驗證而引入的。然而，它增加了協(xié)議的復(fù)雜性。最終，我們將能夠使用 SNARK 直接驗證以太坊共識層，這將消除對專用輕客戶端驗證協(xié)議的需求。通過創(chuàng)建更“原生”的輕客戶端協(xié)議，該協(xié)議涉及驗證來自以太坊共識驗證器隨機(jī)子集的簽名。

數(shù)據(jù)格式協(xié)調(diào)：今天，執(zhí)行狀態(tài)存儲在 Merkle Patricia 樹中，共識狀態(tài)存儲在 SSZ 樹中，并且 blob 以 KZG 承諾的形式提交。在未來，為區(qū)塊數(shù)據(jù)和狀態(tài)創(chuàng)建單一統(tǒng)一格式是有意義的。這些格式將涵蓋所有重要需求：(i) 無狀態(tài)客戶端的簡單證明，(ii) 數(shù)據(jù)的序列化和擦除編碼，(iii) 標(biāo)準(zhǔn)化數(shù)據(jù)結(jié)構(gòu)。

刪除信標(biāo)鏈委員會：最初引入此機(jī)制是為了支持特定版本的執(zhí)行分片。相反，我們最終通過 L2 和 blob 進(jìn)行分片。因此，委員會是不必要的，因此正在努力將其刪除。

刪除混合字節(jié)序：EVM 是大端字節(jié)序，共識層是小端字節(jié)序。重新協(xié)調(diào)并使所有內(nèi)容都為大端字節(jié)序（可能是大端字節(jié)序，因為 EVM 更難更改）可能是有意義的。

現(xiàn)在，EVM 內(nèi)部的一些示例：

簡化 gas 機(jī)制：當(dāng)前的 gas 規(guī)則尚未得到很好的優(yōu)化，無法明確限制驗證區(qū)塊所需的資源數(shù)量。這方面的關(guān)鍵示例包括 (i) 存儲讀/寫成本，旨在限制區(qū)塊中的讀/寫次數(shù)，但目前非常隨意，以及 (ii) 內(nèi)存填充規(guī)則，目前很難估計 EVM 的最大內(nèi)存消耗。建議的修復(fù)包括無狀態(tài) gas 成本更改，將所有與存儲相關(guān)的成本協(xié)調(diào)為一個簡單的公式，以及內(nèi)存定價建議。

刪除預(yù)編譯：以太坊當(dāng)今擁有的許多預(yù)編譯既不必要地復(fù)雜又相對未使用，并且占共識失敗險情的很大比例，但實際上并未被任何應(yīng)用程序使用。處理此問題的兩種方法是 (i) 直接刪除預(yù)編譯，以及 (ii) 用實現(xiàn)相同邏輯的（不可避免地更昂貴的）EVM 代碼替換它。此 EIP 草案建議首先對身份預(yù)編譯執(zhí)行此操作；稍后，RIPEMD160、MODEXP 和 BLAKE 可能會被刪除。

刪除 gas 可觀察性：使 EVM 執(zhí)行不再能夠看到它還剩下多少 gas。這會破壞一些應(yīng)用程序（最明顯的是贊助交易），但將來可以更輕松地進(jìn)行升級（例如，對于更高級的多維 gas 版本）。EOF 規(guī)范已經(jīng)使 gas 不可觀察，但為了有助于協(xié)議簡化，EOF 需要成為強(qiáng)制性的。

靜態(tài)分析的改進(jìn)：今天的 EVM 代碼很難進(jìn)行靜態(tài)分析，特別是因為跳轉(zhuǎn)可以是動態(tài)的。這也使得制作優(yōu)化的 EVM 實現(xiàn)（將 EVM 代碼預(yù)編譯成其他語言）變得更加困難。我們可以通過刪除動態(tài)跳轉(zhuǎn)（或使它們更加昂貴，例如，gas 成本與合約中 JUMPDEST 的總數(shù)成線性關(guān)系）來解決這個問題。EOF 就是這樣做的，但從中獲得協(xié)議簡化收益需要使 EOF 成為強(qiáng)制性的。

現(xiàn)有哪些研究？

Purge 的后續(xù)步驟：https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA

SELFDESTRUCT：https://hackmd.io/@vbuterin/selfdestruct

SSZ-ification EIPS：[1] [2] [3]

無狀態(tài) gas 成本變化：https://eips.ethereum.org/EIPS/eip-4762

線性內(nèi)存定價：https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw

預(yù)編譯刪除：https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg

Bloom 過濾器刪除：https://eips.ethereum.org/EIPS/eip-7668

一種使用增量可驗證計算進(jìn)行鏈下安全日志檢索的方法（閱讀：遞歸 STARK）： https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

還要做什么，又有哪些權(quán)衡？

進(jìn)行這種功能簡化的主要權(quán)衡是 (i) 我們簡化的程度和速度與 (ii) 向后兼容性。以太坊作為一條鏈的價值在于它是一個平臺，您可以在其中部署應(yīng)用程序并確信它在多年后仍能正常工作。與此同時，也有可能將這一理想發(fā)揮得太過，用威廉·詹寧斯·布萊恩的話來說，“將以太坊釘在向后兼容性的十字架上”。如果整個以太坊中只有兩個應(yīng)用程序使用某個功能，其中一個多年來沒有用戶，而另一個幾乎完全沒有使用，并且總共獲得了 57 美元的價值，那么我們應(yīng)該刪除該功能，如果需要，可以自掏腰包向受害者支付 57 美元。

更廣泛的社會問題是創(chuàng)建一個標(biāo)準(zhǔn)化的管道，用于進(jìn)行非緊急的向后兼容性破壞性更改。解決此問題的一種方法是檢查和擴(kuò)展現(xiàn)有先例，例如 SELFDESTRUCT 流程。該管道看起來如下所示：

步驟 1：開始討論刪除功能 X。

步驟 2：進(jìn)行分析以確定刪除 X 對應(yīng)用程序的破壞程度，根據(jù)結(jié)果，選擇 (i) 放棄這個想法，(ii) 按計劃進(jìn)行，或 (iii) 確定一種經(jīng)過修改的“破壞性最小”的刪除 X 的方法并繼續(xù)進(jìn)行。

步驟 3：制定正式的 EIP 以棄用 X。確保流行的高級基礎(chǔ)設(shè)施（例如編程語言、錢包）尊重這一點并停止使用該功能。

步驟 4：最后，實際刪除 X。

在第 1 步和第 4 步之間應(yīng)該有一個長達(dá)數(shù)年的流程，并明確說明哪些項目處于哪個步驟。此時，需要在功能移除流程的力度和速度與更為保守和將更多資源投入?yún)f(xié)議開發(fā)的其他領(lǐng)域之間進(jìn)行權(quán)衡，但我們距離 Pareto 前沿還很遠(yuǎn)。

EOF

針對 EVM 提出的一組主要更改是 EVM 對象格式 (EOF)。EOF 引入了大量更改，例如禁止 gas 可觀察性、代碼可觀察性（即無 CODECOPY）、僅允許靜態(tài)跳轉(zhuǎn)。目標(biāo)是允許 EVM 進(jìn)行更多升級，以具有更強(qiáng)大的屬性，同時保持向后兼容性（因為 EOF 之前的 EVM 仍然存在）。

這樣做的好處是，它為添加新的 EVM 功能和鼓勵遷移到具有更強(qiáng)保證的更嚴(yán)格 EVM 創(chuàng)造了一條自然途徑。它的缺點是，它顯著增加了協(xié)議的復(fù)雜性，除非我們能找到最終棄用和刪除舊 EVM 的方法。一個主要問題是：EOF 在 EVM 簡化提案中扮演什么角色，尤其是如果目標(biāo)是降低整個 EVM 的復(fù)雜性？

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

路線圖其余部分中的許多“改進(jìn)”提案也是簡化舊功能的機(jī)會。重復(fù)上面的一些例子：

切換到單槽終結(jié)性使我們有機(jī)會取消委員會、重新制定經(jīng)濟(jì)學(xué)并進(jìn)行其他與權(quán)益證明相關(guān)的簡化。

完全實現(xiàn)賬戶抽象讓我們可以刪除許多現(xiàn)有的交易處理邏輯，方法是將其移入一段“默認(rèn)賬戶 EVM 代碼”，所有 EOA 都可以用它替換。

如果我們將以太坊狀態(tài)移動到二進(jìn)制哈希樹，這可以與新版本的 SSZ 協(xié)調(diào)一致，以便所有以太坊數(shù)據(jù)結(jié)構(gòu)都可以以相同的方式進(jìn)行哈希處理。

更激進(jìn)的方法：將協(xié)議的大部分內(nèi)容轉(zhuǎn)化為合約代碼

更激進(jìn)的以太坊簡化策略是保持協(xié)議原樣，但將協(xié)議的大部分內(nèi)容從協(xié)議功能轉(zhuǎn)變?yōu)楹霞s代碼。

最極端的版本是讓以太坊 L1“技術(shù)上”只是信標(biāo)鏈，并引入一個最小的 VM（例如 RISC-V、Cairo 或?qū)ｉT用于證明系統(tǒng)的更簡單的 VM），允許任何其他人創(chuàng)建自己的匯總。然后，EVM 將成為這些匯總中的第一個。具有諷刺意味的是，這與 2019-20 年的執(zhí)行環(huán)境提案的結(jié)果完全相同，盡管 SNARK 使其實際實施起來更加可行。

更溫和的方法是保持信標(biāo)鏈與當(dāng)前以太坊執(zhí)行環(huán)境之間的關(guān)系不變，但對 EVM 進(jìn)行就地交換。我們可以選擇 RISC-V、Cairo 或其他 VM 作為新的“官方以太坊 VM”，然后將所有 EVM 合約強(qiáng)制轉(zhuǎn)換為解釋原始代碼邏輯的新 VM 代碼（通過編譯或解釋）。從理論上講，甚至可以將“目標(biāo) VM”作為 EOF 版本來完成此操作。

特別感謝 Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden 和 Tomasz Stanczak 的反饋和評論。