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