作者：Ethereum創(chuàng)始人Vitalik；編譯：鄧通，金色財(cái)經(jīng)

按：本文為Ethereum創(chuàng)始人Vitalik近期發(fā)表的“Ethereum協(xié)議的未來發(fā)展”系列文章的第五部分“PossiblefuturesoftheEthereumprotocol,part5:ThePurge”，第四部分見“Vitalik：Ethereum的未來TheVerge”。第三部分見“Vitalik：EthereumTheScourge階段的關(guān)鍵目標(biāo)”，第二部分見“Vitalik：TheSurge階段Ethereum協(xié)議應(yīng)該怎么發(fā)展”，第一部分見“EthereumPoS還有哪些可以改進(jìn)”。以下為第五部分全文：

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

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

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

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

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

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ò)的Ethereum原生解決方案。一旦引入其中任何一個，我們就可以啟用EIP-4444。EIP-4444本身不需要硬分叉，但它確實(shí)需要一個新的網(wǎng)絡(luò)協(xié)議版本。因此，同時(shí)為所有客戶端啟用它是有價(jià)值的，因?yàn)榉駝t客戶端可能會因連接到其他Node而出現(xiàn)故障，這些Node期望下載完整的歷史記錄但實(shí)際上并沒有實(shí)現(xiàn)。

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

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

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

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

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

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

限制歷史存儲也使較新的EthereumNode實(shí)現(xiàn)更可行地僅支持協(xié)議的最新版本，這使它們變得更加簡單。例如，由于2016年DoS攻擊期間創(chuàng)建的空存儲槽已全部被刪除，因此可以安全地刪除許多代碼行。既然切換到權(quán)益證明已成為歷史，客戶端可以安全地刪除所有與工作量證明相關(guān)的代碼。狀態(tài)數(shù)據(jù)過期它解決了什么問題？

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

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

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

效率：不需要大量額外的計(jì)算來運(yùn)行到期流程。

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

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

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

這些都是Ethereum核心開發(fā)社區(qū)多年來一直在努力解決的問題，包括“Blockchain租金”和“再生”等提案。最終，我們結(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è)計(jì)之上（盡管與任何形式的無狀態(tài)樹兼容，例如二叉樹）。在這種設(shè)計(jì)中，彼此相鄰的標(biāo)頭、代碼和存儲槽存儲在同一個“莖”下。存儲在莖下的數(shù)據(jù)最多可以是256*31=7,936字節(jié)。在許多情況下，賬戶的整個標(biāo)題和代碼以及許多密鑰存儲槽都將存儲在同一個主干下。如果給定主干下的數(shù)據(jù)在6個月內(nèi)未被讀取或?qū)懭?，則不再存儲數(shù)據(jù)，而是只存儲對數(shù)據(jù)的32字節(jié)承諾（“存根”）。未來訪問該數(shù)據(jù)的交易將需要“復(fù)活”數(shù)據(jù)，并提供與存根核對的證明。

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

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

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

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

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

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

0xffffffff000169125d5dFcb7B8C2659029395bdF

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

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

早期提案

Blockchain租用費(fèi)：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狀態(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)為未來有四條可行的路徑：

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

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

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

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

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

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

執(zhí)行狀態(tài)到期可能會使從一種狀態(tài)樹格式到另一種狀態(tài)樹格式的轉(zhuǎn)換變得更容易，因?yàn)椴恍枰D(zhuǎn)換過程：您可以簡單地開始使用新格式制作新樹，然后稍后進(jìn)行硬分叉以轉(zhuǎn)換舊樹。因此，雖然狀態(tài)到期很復(fù)雜，但它確實(shí)有助于簡化路線圖的其他方面。功能清理它解決了什么問題？

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

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

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

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

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

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

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

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

數(shù)據(jù)格式協(xié)調(diào)：今天，執(zhí)行狀態(tài)存儲在MerklePatricia樹中，共識狀態(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é)序，因?yàn)镋VM更難更改）可能是有意義的。

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

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

刪除預(yù)編譯：Ethereum當(dāng)今擁有的許多預(yù)編譯既不必要地復(fù)雜又相對未使用，并且占共識失敗險(xiǎn)情的很大比例，但實(shí)際上并未被任何應(yīng)用程序使用。處理此問題的兩種方法是(i)直接刪除預(yù)編譯，以及(ii)用實(shí)現(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)分析，特別是因?yàn)樘D(zhuǎn)可以是動態(tài)的。這也使得制作優(yōu)化的EVM實(shí)現(xiàn)（將EVM代碼預(yù)編譯成其他語言）變得更加困難。我們可以通過刪除動態(tài)跳轉(zhuǎn)（或使它們更加昂貴，例如，gas成本與合約中JUMPDEST的總數(shù)成線性關(guān)系）來解決這個問題。EOF就是這樣做的，但從中獲得協(xié)議簡化收益需要使EOF成為強(qiáng)制性的?，F(xiàn)有哪些研究？

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

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

SSZ-ificationEIPS：[1][2][3]

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

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

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

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

一種使用增量可驗(yàn)證計(jì)算進(jìn)行鏈下安全日志檢索的方法（閱讀：遞歸STARK）：https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw還要做什么，又有哪些權(quán)衡？

進(jìn)行這種功能簡化的主要權(quán)衡是(i)我們簡化的程度和速度與(ii)向后兼容性。Ethereum作為一條鏈的價(jià)值在于它是一個平臺，您可以在其中部署應(yīng)用程序并確信它在多年后仍能正常工作。與此同時(shí)，也有可能將這一理想發(fā)揮得太過，用威廉·詹寧斯·布萊恩的話來說，“將Ethereum釘在向后兼容性的十字架上”。如果整個Ethereum中只有兩個應(yīng)用程序使用某個功能，其中一個多年來沒有用戶，而另一個幾乎完全沒有使用，并且總共獲得了57美元的價(jià)值，那么我們應(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ì)劃進(jìn)行，或(iii)確定一種經(jīng)過修改的“破壞性最小”的刪除X的方法并繼續(xù)進(jìn)行。

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

步驟4：最后，實(shí)際刪除X。

在第1步和第4步之間應(yīng)該有一個長達(dá)數(shù)年的流程，并明確說明哪些項(xiàng)目處于哪個步驟。此時(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)大的屬性，同時(shí)保持向后兼容性（因?yàn)镋OF之前的EVM仍然存在）。

這樣做的好處是，它為添加新的EVM功能和鼓勵遷移到具有更強(qiáng)保證的更嚴(yán)格EVM創(chuàng)造了一條自然途徑。它的缺點(diǎn)是，它顯著增加了協(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)的簡化。

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

如果我們將Ethereum狀態(tài)移動到二進(jìn)制哈希樹，這可以與新版本的SSZ協(xié)調(diào)一致，以便所有Ethereum數(shù)據(jù)結(jié)構(gòu)都可以以相同的方式進(jìn)行哈希處理。更激進(jìn)的方法：將協(xié)議的大部分內(nèi)容轉(zhuǎn)化為合約代碼

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

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

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

特別感謝JustinDrake、TimBeiko、MattGarnett、PiperMerriam、MariusvanderWijden和TomaszStanczak的反饋和評論。