以太坊協議的可能未來，第5部分：清除
以太坊面臨的一個挑戰是，默認情況下，任何區塊鏈協議的膨脹和複雜性都會隨著時間的推移而增長。這發生在兩個地方：
- 歷史數據：在歷史的任何時候進行的任何交易和創建的任何帳戶都需要由所有客戶永久存儲，並由任何新客戶下載，從而完全同步到網路。這會導致用戶端負載和同步時間隨著時間的推移而不斷增加，即使鏈的容量保持不變也是如此。
- 協議功能：添加新功能比刪除舊功能更容易，導致代碼複雜性隨時間增加。
為了使乙太坊長期維持下去，我們需要對這兩種趨勢進行強大的反制壓力，隨著時間的推移降低複雜性和膨脹。但與此同時，我們需要保留使區塊鏈變得偉大的關鍵屬性之一：它們的持久性。你可以把一個NFT，一個情書放在交易調用數據中，或者一個包含一百萬美元的智能合約，進入一個洞穴十年，出來發現它仍然在那裡等著你閱讀和互動。為了讓 dapp 能夠放心地完全去中心化並刪除他們的升級密鑰，他們需要確信他們的依賴項不會以破壞它們的方式升級——尤其是 L1 本身。
《大屠殺》2023年路線圖。
在满足这两种需求之间取得平衡，并最小化或逆转膨胀、复杂性和衰变，同时保持连续性，如果我们下定决心是完全可能的。生物体可以做到：虽然大多数生物会随着时间的推移而老化，一些幸運的人不.即使社會系統也能擁有極長的壽命在某些情況下，以太坊已經取得了成功：工作量證明已經消失，SELFDESTRUCT操作碼大部分也已經消失，信標鏈節點已經存儲舊數據，最多只有六個月。找到以更一般化的方式為以太坊開拓這條道路，並朝著長期穩定的最終結果邁進，是以太坊長期可擴展性、技術可持續性甚至安全性的最終挑戰。
清除：主要目標
- 通過減少或刪除每個節點永久存儲所有歷史的需求，甚至可能最終狀態，從而減少客戶端存儲要求
- 通過消除不必要的功能來減少協議的複雜性
在這一章
歷史到期
它解决了什么问题？
截至撰寫本文時，一個完全同步的以太坊節點需要大约1.1TB的磁盤空間執行客戶端另外還有幾百GB用於共識客戶端。其中絕大部分是歷史數據：有關歷史區塊、交易和收據的數據，其中大部分數據已有多年。這意味著節點的大小每年都會增加數百GB，即使gas限制保持不變。
它是什麼，它是如何運作的？
歷史存儲問題的一個關鍵簡化特徵是，因為每個區塊通過哈希鏈指向前一個區塊（和其他結構), 對於現在的共識足以對歷史達成共識。只要網絡對最新的區塊有共識，任何歷史區塊、交易或狀態（賬戶餘額、nonce、代碼、存儲）都可以由任何單個參與者提供，並且證明允許任何其他人驗證其正確性。雖然共識是一個 N/2-of-N 的信任模型，但歷史是一個 1-of-N 信任模型.
這為我們如何存儲歷史記錄開闢了許多選擇。一個自然的選擇是網路，其中每個節點只存儲一小部分數據。這就是洪流網路幾十年來的工作方式：雖然網路總共存儲和分發了數百萬個檔，但每個參與者只存儲和分發其中的幾個檔。也許與直覺相反，這種方法甚至不一定會降低數據的魯棒性。如果通過使節點運行更實惠，我們可以進入一個擁有 100,000 個節點的網路，其中每個節點存儲隨機 10% 的歷史記錄，那麼每條數據將被複製 10,000 次 - 與每個節點存儲所有內容的 10,000 節點網路完全相同的複製因數。
今天，以太坊已經開始遠離所有節點永遠存儲所有歷史的模式。共識區塊（即與權益證明共識相關的部分）僅存儲約6個月。 Blob僅存儲約18天。EIP-4444旨在引入歷史區塊和收據的一年存儲期。長期目標是在每個節點負責存儲所有內容的和諧期間(可能為約18天)，然後通過以太坊節點組成的點對點網絡以分佈方式存儲舊數據。
消除碼可以用來增加健壯性，同時保持複製因子不變。事實上，blob 已經採用了消除碼，以支持數據可用性抽樣。最簡單的解決方案可能是重複使用這種消除碼，並將執行和共識區塊數據也放入blob中。
有哪些現有研究的連結？
- EIP-4444: https://eips.以太坊.org/EIPS/eip-4444
- Torrents 和 EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
- 閘道網絡：https://ethereum.org/en/developers/docs/networking-layer/portal-network/
- 門戶網絡和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
- 如何提高燃氣上限（範式）：https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2
還有什麼要做，以及有什麼取捨？
主要剩下的工作包括建立和整合一個具體的分佈式解決方案，用於存儲歷史記錄 - 至少執行歷史記錄，但最終也包括共識和區塊。這方面最簡單的解決方案是（i）簡單地引入一個現有的種子庫，和（ii）一個名為以太坊原生解決方案的。門戶網絡. 一旦其中任何一個被引入，我們可以打開EIP-4444。 EIP-4444本身不需要硬分叉，但它需要一個新的網絡協議版本。 因此，同時為所有客戶端啟用它有價值，否則存在與其他節點連接時出現故障的風險，這些節點期望下載完整的歷史記錄，但實際上並未獲得。
主要的取捨涉及我們試圖使“古老”的歷史數據可用的程度。最簡單的解決方案是明天就停止存儲古代歷史，依賴現有的存檔節點和各種中心化提供者進行複製。這很容易，但會削弱以太坊作為永久記錄之地的地位。更難，但更安全的路徑是首先建立和整合 torrent 網絡，以分佈式方式存儲歷史。在這裡，“我們試圖”的程度有兩個維度：
- 我們會盡最大的努力確保最大的節點集合真的存儲了所有數據嗎？
- 我們將歷史存儲與協議深度整合到哪個程度？
對於（1），最大程度的偏執方法會涉及保管证明: 實際上，每個權益證明驗證器都需要存儲一定比例的歷史記錄，並定期進行密碼學檢查以確保他們這樣做。一個更溫和的方法是為每個客戶端存儲歷史記錄的百分比設定一個自願標準。
對於（2），基本實現只涉及採取今天已經完成的工作：Portal已經存儲包含整個以太坊歷史的ERA文件。更徹底的實現將涉及實際將其連接到同步過程，這樣，如果有人想要同步完整歷史存儲節點或存檔節點，即使沒有其他存檔節點在線，他們也可以從Portal網絡直接同步。
它如何與路線圖的其他部分互動？
如果我們想要使運行或啟動節點變得非常容易，那麼減少歷史存儲要求可能比無狀態更重要：節點需要擁有的 1.1 TB 中，約 300 GB 是狀態，其餘約 800 GB 是歷史。只有當無狀態和以太坊協議實施時，以太坊節點運行在智能手錶上並且只需幾分鐘設置的願景才是可以實現的。
限制歷史存儲也使得對於較新的以太坊節點實現僅支持最近版本的協議更具可行性，這使得它們變得更加簡單。例如，現在可以安全地刪除許多行代碼，因為在2016年DoS攻擊期間創建的空存儲槽已經全部被已刪除現在切換到權益證明已經成為過去，客戶可以安全地刪除所有與工作量證明相關的代碼。
狀態到期
它解决了什麼問題？
即使我們消除了用戶端存儲歷史記錄的需要，由於帳戶餘額和隨機數、合約代碼和合約存儲的持續增長，客戶的存儲需求將繼續增長，每年增長約 50 GB。用戶可以支付一次性費用，永遠給現在和未來的乙太坊客戶帶來負擔。
狀態比歷史"過期"要困難得多，因為EVM基本上是根據一個假設設計的，即一旦創建了狀態對象，它將永遠存在，並且可以被任何交易隨時讀取。如果我們引入無狀態性，可以說也許這個問題並不那麼糟糕：只有一個特殊類別的區塊生成器才需要實際存儲狀態，而所有其他節點（甚至包含清單 production!)可以無狀態運行。然而，有一種觀點認為我們不希望過分依賴無狀態，最終我們可能希望過期狀態以保持以太坊的去中心化。
這是什麼，它是如何運作的？
今天，當您創建一個新的狀態對象時（可能以三種方式之一發生：（i）將ETH發送到新帳戶，（ii）創建帶有代碼的新帳戶，（iii）設置以前未觸及的存儲槽），該狀態對象將永遠處於該狀態。相反，我們希望對象能隨著時間自動過期。關鍵挑戰是以實現三個目標的方式來完成此目標:
- 效率：不需要大量額外計算來運行到期處理過程
- 用戶友好性：如果有人進入洞穴五年後回來，他們不應該失去對他們的ETH，ERC20，NFT，CDP倉位的訪問權。
- 開發者友好：開發者不應該被迫轉換到完全陌生的思維模式。此外，今天僵化且不更新的應用程序應該繼續正常運行。
在不滿足這些目標的情況下解決問題很容易。例如，您可以讓每個狀態物件還存儲其到期日期的計數器（可以通過刻錄 ETH 來延長，這可能在讀取或寫入時自動發生），並有一個迴圈遍歷狀態以刪除過期狀態對象的進程。但是，這引入了額外的計算（甚至存儲要求），並且絕對不能滿足使用者友好性要求。開發人員也很難對涉及存儲值的邊緣情況進行推理，有時重置為零。如果你在合同範圍內設置到期計時器，這在技術上使開發人員的生活更輕鬆，但它使經濟性更加困難：開發人員將不得不考慮如何將存儲的持續成本“轉嫁”給他們的使用者。
這些是以太坊核心開發社區多年來努力解決的問題，包括像「protocol區塊鏈租金「和」regenesis最終，我們將提案的最佳部分結合起來，並收斂到兩個“已知最不壞的解決方案”類別上。
- 部分狀態過期解決方案
- 基於地址期限的狀態到期提案。
部分狀態到期
部分狀態到期提案都遵循相同的原則。我們將狀態拆分為多個塊。每個人都永久存儲「頂級地圖」，其中塊為空或非空。僅當最近訪問了每個塊中的數據時，才會存儲該數據。有一種「復活」機制，如果不再存儲塊，任何人都可以通過提供數據是什麼的證明來恢復該數據。
這些提案之間的主要區別在於：(i)我們如何定義“最近”，以及(ii)我們如何定義“區塊”？一個具體的提案是 EIP-7736，該設計建立在“莖葉圖”設計基礎之上 用於Verkle樹的介紹（儘管兼容任何形式的無狀態性，例如二進制樹）。在此設計中，相鄰的標題、代碼和存儲槽存儲在同一個“幹”下。在一個幹下存儲的數據最多可以是256 * 31 = 7,936字節。在許多情況下，一個帳戶的整個標題和代碼以及許多關鍵的存儲槽都存儲在同一個幹下。如果在一個給定的幹下的數據在6個月內沒有被讀取或寫入，則不再存儲該數據，而只存儲數據的32字節承諾（“存根”）。訪問該數據的未來交易將需要“喚醒”該數據，並提供對存根的證明，以進行驗證。
還有其他方法可以實現類似的想法。例如，如果帳戶級別的粒度還不夠，我們可以制定一個方案，其中樹的每個 1/232 部分由類似的莖葉機制控制。
這更加棘手，因為存在激勵措施：攻擊者可以通過將大量數據放入單個子樹並每年發送一筆交易來“更新樹”，從而強迫客戶永久存儲大量狀態。如果將更新成本與樹大小成比例（或者更新持續時間與樹大小成反比），那麼某人可以通過將大量數據放入與其相同的子樹中來損害另一用戶。可以嘗試通過根據子樹大小使粒度動態化來限制這兩個問題：例如，每連續的216=65536個狀態對象可以被視為一個“組”。然而，這些想法更加復雜；基於莖的方法是簡單的，並且它調整了激勵措施，因為通常莖下的所有數據都與同一應用程序或用戶有關。
基於地址期限的狀態到期提議
如果我們想避免任何永久性的狀態增長，即使是 32 位元組的存根，該怎麼辦？這是一個難題，因為@vbuterin/state_size_management#Resurrection-conflicts">resurrection conflicts: 如果一個狀態對象被刪除，後來的以太坊虛擬機執行將在完全相同的位置放置另一個狀態對象，但之後關心原始狀態對象的人回來並嘗試恢復它，會發生什麼？部分狀態過期時，“存根”會阻止新數據的創建。完全狀態過期時，我們甚至無法存儲存根。
基於位址週期的設計是解決此問題的最著名思想。我們不是讓一個狀態樹存儲整個狀態，而是有一個不斷增長的狀態樹清單，任何被讀取或寫入的狀態都會保存在最新的狀態樹中。每個週期都會添加一次新的空狀態樹（想想：1 年）。較老的州樹是凍結的固體。完整節點應僅存儲最近的兩棵樹。如果狀態物件在兩個時期內沒有被觸及，因此落入過期的樹中，它仍然可以被讀取或寫入，但事務需要證明它的 Merkle 證明 - 一旦這樣做，副本將再次保存在最新的樹中。
使這一切對用戶和開發者都友好的一個關鍵概念是地址期。地址期是地址的一部分的數字。一個關鍵規則是，具有地址期N的地址只能在期N期間或之後讀取或寫入（即當狀態樹列表達到長度N時）。如果您要保存新的狀態對象（例如新合同或新的ERC20餘額），請確保將狀態對象放入地址期為N或N-1的合同中，則可以立即保存它，而無需提供證明之前沒有任何東西。另一方面，在較舊的地址期中對狀態進行添加或編輯確實需要證明。
這種設計保留了乙太坊當前的大部分屬性，對額外計算非常輕，允許應用程式幾乎像今天一樣編寫（ERC20 需要重寫，以確保位址週期為 N 的地址餘額存儲在本身具有位址週期 N 的子合約中），並解決了“使用者進入洞穴五年”的問題。但是，它有一個大問題：位址需要擴展到 20 位元組以上以適應位址週期。
地址空間擴展
一個提議是引入一種新的32位元位址格式，其中包括版本號、位址週期號和擴展哈希。
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
紅色是版本號。這裡橘色的四個零被當作未來可以容納分片號的空白。綠色是地址期數號碼。藍色是 26 字節哈希。
這裡的關鍵挑戰是向後相容性。現有合約圍繞 20 位元組地址設計，並且通常使用嚴格的位元組打包技術，明確假定位址正好是 20 位元組長。@ipsilon/address-space-extension-exploration">解决此问题的一个想法涉及翻译映射，其中与新样式地址交互的旧样式合同将看到新样式地址的20字节哈希。然而，涉及使此过程安全的重大复杂性。
位址空間收縮
另一種方法則相反：我們立即禁止一些 2128 大小的位址子範圍（例如，所有以 0xffffffff 開頭的位址），然後使用該範圍引入具有位址週期和 14 位元組哈希的位址。
0xfffffff000169125d5dFcb7B8C2659029395bdF
這種方法做出的關鍵犧牲是，它對於反事實地址存在安全風險：持有資產或許可權，但其代碼尚未發佈到鏈的位址。風險涉及某人創建一個位址，該位址聲稱具有一段（尚未發佈的）代碼，但也有另一段有效代碼散列到同一位址。計算這樣的碰撞需要 280今天的哈希數; 地址空間收縮將使這個數字減少到非常可接近的256雜湊。
關鍵風險區域，即非由單一所有者持有的對應地址，目前相對較少見，但隨著進入多層次的世界，可能變得更加普遍。唯一的解決方案是接受這種風險，但要識別所有可能成為問題的常見用例，並提出有效的解決方案。
有哪些現有研究的鏈接？
- 早期提議
- 以太坊狀態大小管理理論：@vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
- 一些可能的去中心化和状态到期的路径:@vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
- 部分狀態到期提案
- EIP-7736: https://eips.以太坊.org/EIPS/eip-7736
- 地址空間擴展文件
- 原始提案：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
- Ipsilon評論：@ipsilon/地址空間擴展探索"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
- 部落格文章評論：@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">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帐户）。无状态验证器可以将这些证明组合成整个包含列表的证明。 - 我們進行部分狀態過期，並接受永久狀態大小增長速率大幅下降但仍為非零。這種結果可能與涉及點對點網絡的歷史過期提案相似，每個客戶都必須存儲歷史數據的低但固定百分比，同時接受永久歷史存儲增長速率大幅下降但仍為非零。
- 我們確實會設置到期時間，並擴展地址空間。這將涉及一個多年的過程，確保地址格式轉換方法有效且安全，包括現有應用程式。
- 我們確實會設定到期日，並縮小地址空間。這將涉及一個長達多年的過程，確保處理所有與地址碰撞相關的安全風險，包括跨鏈情況。
一個重要的觀點是，無論是否實施依賴於地址格式更改的狀態到期方案，都必須最終解決地址空間擴展和收縮的問題。如今，大約需要280要生成地址碰撞的哈希散列，對於非常充足的參與者來說，這種計算負載已經是可行的：一個 GPU 可以處理大約 227哈希，因此運行一年可以計算 252，所以全部全球约有2^30个GPU可以在大約1/4年的時間內計算出碰撞，而FPGAs和ASICs可以進一步加速這一過程。將來，這樣的攻擊將對越來越多的人開放。因此，實施完整的狀態過期的實際成本可能並不像看起來那麼高，因為我們必須解決這個非常具有挑戰性的地址問題。
它如何與路線圖的其他部分互動？
進行狀態過期有可能讓從一個狀態樹格式轉換到另一個更容易，因為不需要轉換程序：您可以直接開始使用新格式創建新樹，然後稍後通過硬分叉轉換舊樹。因此，儘管狀態過期復雜，但在簡化路線圖的其他方面確實有好處。
功能整理
它解决了什么问题？
安全、可存取性和 可信的中立性是簡單性。如果一個協議是美麗和簡單的，它減少了出現錯誤的可能性。它增加了新開發人員能夠進來並與任何部分一起工作的機會。它更有可能公平，更容易抵禦特殊利益。不幸的是，協議，像任何社會系統一樣，默默地變得越來越複雜。如果我們不希望以太坊陷入越來越複雜的黑洞，我們需要做以下兩件事之一：（i）停止進行更改並固定協議，（ii）能夠實際刪除功能並減少複雜性。還有一種中間路線，即在協議上進行較少的更改，同時隨著時間的推移，至少減少一點複雜性，也是可能的。本節將討論如何減少或刪除複雜性。
這是什麼，它是如何工作的？
沒有一個大的單一修復可以減少協議的複雜性；問題的固有性質是有很多小的修復。
一個已經大致完成並可以作為處理其他問題的藍圖的例子是，@vbuterin/selfdestruct">刪除SELFDESTRUCT操作碼。SELFDESTRUCT操作碼是唯一能夠在單個區塊內修改無限數量的存儲槽的操作碼，要求客戶端實現更多的複雜性以避免DoS攻擊。操作碼的原始目的是允許自願狀態清除，允許狀態大小隨時間減小。事實上，很少有人使用它。opcode被削弱了僅允許在 Dencun 硬分叉中的同一交易中創建的自毀帳戶。這解決了 DoS 問題，並允許顯著簡化客戶端代碼。將來，最終完全刪除操作碼可能是有意義的。
到目前為止已經確定的一些協議簡化機會的一些關鍵示例包括以下。首先，一些在以太坊虛擬機之外的示例；這些相對不具侵入性，因此更容易獲得共識並在較短的時間內實施。
- RLP→SSZ轉換：最初，以太坊對象是使用一種叫做編碼的方式進行序列化的。RLP. RLP是無類型的，並且過於複雜。今天，信標鏈使用SSZ，這在許多方面都明顯更好，包括不僅支援序列化，還支援哈希。最終，我們希望完全擺脫RLP，並將所有數據類型移動到SSZ結構中，這反過來又會使可升級性變得更加容易。目前對此的 EIP 包括[1] [2] [3].
- 移除舊交易類型：現在有太多的交易類型，其中許多可能被移除。一種更溫和的替代方案是帳戶抽象功能，智能帳戶可以包含處理和驗證舊式交易的代碼，如果他們選擇這樣做。
- 日誌改革：日誌創建布隆過濾器和其他增加協議複雜性的邏輯，但實際上客戶端不使用它，因為它太慢了。我們可以移除這些功能，而是努力尋找替代方案，比如使用像SNARKs這樣的現代技術的協議外去中心化日誌閱讀工具。
- 最終移除信標鏈同步委員會機制：同步委員會機制最初引入以便对以太坊进行轻客户端验证。然而，它给协议增加了很大的复杂性。最终，我们将能够使用SNARKs直接驗證Ethereum共識層，這將消除對專用輕客戶端驗證協定的需求。潛在地，對共識的改變可以讓我們更早地刪除同步委員會，通過創建一個更“原生”的輕用戶端協定，涉及驗證來自乙太坊共識驗證器隨機子集的簽名。
- 數據格式的協調：今天，執行狀態存儲在一個Merkle Patricia樹中，共識狀態存儲在一個SSZ樹，並且blob是承諾與之。@vbuterin/proto_danksharding_faq#blob數據的格式是什麼，它是如何提交的">KZG承諾。將來，對於塊數據和狀態，制定一個統一的格式是有意義的。這些格式將涵蓋所有重要的需求：(i) 無狀態客戶的易於證明，(ii) 數據的序列化和擦除編碼，(iii) 標準化的數據結構。
- 移除信標鏈委員會：這個機制最初是為了支援執行分片的特定版本。然而，我們最終還是進行了分片。通過 L2s 和 blobs因此，委員會是不必要的，所以有一個正在進行移除它們的過程.
- 移除混合字节顺序：EVM 是大端字节序，共识层是小端字节序。重新协调并使一切都是大端或小端可能是有道理的（可能是大端，因为更改 EVM 较为困难）
現在，一些在EVM內的範例：
- 簡化瓦斯機制：目前的瓦斯規則並不完全優化，無法清晰界定驗證區塊所需的資源數量。其中的關鍵問題包括（i）存儲讀寫成本，旨在限制區塊中的讀寫次數，但目前相當混亂；以及（ii）填充記憶體規則，目前很難估計EVM的最大記憶體消耗。建議的修復方法包括 無狀態性燃氣成本變化，將所有與存儲相關的成本統一到一個簡單的公式中，並這個有關記憶定價的提案.
- 移除預編譯：當前以太坊的許多預編譯過於複雜，並且相對很少被使用，佔據了共識失敗接近失敗的大部分，實際上卻沒有被任何應用程序使用。處理此問題的兩種方法是 (i) 刪除預編譯，以及 (ii) 用實現相同邏輯的 EVM 代碼替換它（必然更昂貴）。該草案EIP提議作為第一步，對於身份編譯進行此操作；之後，RIPEMD160、MODEXP和BLAKE可能成為移除的候選項。
- 刪除瓦斯可觀察性：使EVM執行無法再看到剩餘的瓦斯數量。這將破壞一些應用程式（尤其是贊助交易），但將使未來升級更加容易（例如，用於更高級版本的協議）多維氣體). EOF規範已經使氣體不可觀察，但為了協議簡化的實用性，EOF需要成為強制性的。
- 靜態分析的改進: 目前 EVM 代碼很難靜態分析，特別是因為跳轉可以是動態的。這也使得更難以將優化的 EVM 實現編譯成其他語言的 EVM 代碼。我們可以通過...來潛在地解決這個問題。移除動態跳轉（或使它們變得更加昂貴，例如，燃氣成本與合約中的JUMPDEST總數呈線性關係）。 EOF 可以實現這一點，但要實現協議簡化的收益，需要將 EOF 視為強制性的。
一些現有研究的連結是什麼？
- 清除中的後續步驟：https://notes.以太坊.org/I_AIhySJTTCYau_adoy2TA
- SELFDESTRUCT: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
- SSZ-化的EIPS: [1][2] [3]
- 狀態無關性的燃氣成本變化：https://eips.ethereum.org/EIPS/eip-4762
- 線性記憶體定價:https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
- 預編譯移除：https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
- 布隆過濾器移除：https://eips.以太坊.org/EIPS/eip-7668
- 使用增量可驗證計算（即：遞歸STARKs）來進行鏈下安全日誌檢索的方法：https://notes.以太坊.org/XZuqy8ZnT3KeG1PkZpeFXw
還有什麼事要做，以及有什麼取捨？
進行這類功能簡化的主要折衷是(i)我們簡化的程度和速度 vs (ii)向後兼容性。 以太坊作為一個平台的價值在於你可以部署應用程序並且有信心它多年後仍然能正常運作。 同時，將這個理想推向極致也是可能的，改述威廉·詹宁斯·布莱恩，“將乙太坊釘在向後相容性的十字架上”。如果整個乙太坊中只有兩個應用程式使用給定的功能，並且一個使用者多年來為零，另一個幾乎完全未使用並且總共獲得了 57 美元的價值，那麼我們應該刪除該功能，如果需要，請自掏腰包向受害者支付 57 美元。
在創建標準化管道以進行非緊急向後兼容性破壞性更改方面存在著更廣泛的社會問題。解決這個問題的一種方法是檢視和擴展現有的先例，比如SELFDESTRUCT過程。該管道大致如下：
- 步驟1：開始討論移除功能X
- 第2步：進行分析以確定去除X會對應用程序造成多大的破壞，根據結果，要么（i）放棄這個想法，（ii）按計劃繼續，或（iii）找出一種修改的“最不具破壞性”的方式來去除X並繼續進行
- 步驟3：提出正式的以太坊改進提案（EIP），使X過時。確保受歡迎的高級基礎設施（例如，編程語言、錢包）尊重這一點並停止使用該功能。
- 第四步：最後，實際上移除X
步驟1和步驟4之間應該有一條多年的管道，清楚地知道哪些項目在哪個步驟。此時，存在著如何積極迅速地進行特徵刪除管道與更加保守地投入更多資源進行協議開發其他領域之間的權衡，但我們仍遠離Pareto前沿。
EOF
EVM 提出了一系列重大變更EVM Object Format (EOF). EOF引入了很多改變，例如禁止氣體可觀察性，代碼可觀察性（即沒有CODECOPY），只允許靜態跳躍。目標是允許更多地升級EVM，以一種具有較強屬性的方式，同時保留向後兼容性（因為先前的EOF EVM仍然存在）。
這樣做的優點是可以為新增的EVM功能創建一個自然的途徑，並鼓勵遷移到具有更強保證的更嚴格的EVM。這樣做的缺點是會顯著增加協議的複雜性，除非我們能找到一種方法來最終淘汰並刪除舊的EVM。一個主要問題是：在EVM簡化提案中，EOF在其中扮演什麼角色，特別是如果目標是減少整個EVM的複雜性？
它如何與路線圖的其他部分交互？
在路線圖的其餘部分中，許多“改進”提案也是對舊功能進行簡化的機會。從上面重複一些例子：
- 切換到單個插槽最終性給了我們一個機會，可以去除委員會，重塑經濟，並進行其他與權益證明相關的簡化。
- 完全實現帳戶抽象化讓我們能夠移除許多現有的交易處理邏輯，將其轉移到一塊“默認帳戶EVM代碼”中，所有EOA都可以被替換。
- 如果我們將以太坊狀態轉移到二進制哈希樹中，這將可以與新版本的SSZ協議協調一致，這樣所有以太坊數據結構都可以以相同的方式進行哈希。
更激進的方法：將協議的大部分轉換為合約代碼
一种更激进的以太坊简化策略是保持协议不变，但将其大部分功能从协议功能转移到合约代碼。
這種極端版本的做法是讓以太坊L1“技術上”僅僅是信標鏈，並引入一個最小的VM（例如。RISC-V, 開羅，或者甚至更專注於證明系統的最小化專用系統），這允許任何其他人創建自己的Rollup。然後，EVM將成為這些Rollup中的第一個。這具有諷刺意味，正是與“”完全相同的結果。2019-20年的執行環境提案然而，SNARKs使得實際實施變得更加可行。
一種更溫和的方法是保持信標鏈與當前以太坊執行環境之間的關係不變，但對EVM進行就地交換。我們可以選擇RISC-V、Cairo或另一個虛擬機作為新的“官方以太坊虛擬機”，然後強制將所有EVM合約轉換為解釋原始代碼邏輯的新VM代碼（通過編譯或解釋）。從理論上講，這甚至可以使用“目標VM”作為EOF的一個版本來完成。
免責聲明：
- 本文轉載自 [Vitalik Buterin], 所有版權歸原作者所有 [Vitalik Buterin]. 如果對此轉載有異議，請聯繫Gate 學習團隊會立即處理。
- 責任聲明：本文所表達的觀點和意見僅為作者個人觀點，並不構成任何投資建議。
- 文章的翻譯工作由gate Learn團隊完成。除非另有說明，禁止複製、分發或抄襲翻譯後的文章。
相關文章
如何質押 ETH？
什幺是包裝以太幣（WETH）？
以太坊協議的可能未來，第5部分：清除
以太坊面臨的一個挑戰是，默認情況下，任何區塊鏈協議的膨脹和複雜性都會隨著時間的推移而增長。這發生在兩個地方：
- 歷史數據：在歷史的任何時候進行的任何交易和創建的任何帳戶都需要由所有客戶永久存儲，並由任何新客戶下載，從而完全同步到網路。這會導致用戶端負載和同步時間隨著時間的推移而不斷增加，即使鏈的容量保持不變也是如此。
- 協議功能：添加新功能比刪除舊功能更容易，導致代碼複雜性隨時間增加。
為了使乙太坊長期維持下去，我們需要對這兩種趨勢進行強大的反制壓力，隨著時間的推移降低複雜性和膨脹。但與此同時，我們需要保留使區塊鏈變得偉大的關鍵屬性之一：它們的持久性。你可以把一個NFT，一個情書放在交易調用數據中，或者一個包含一百萬美元的智能合約，進入一個洞穴十年，出來發現它仍然在那裡等著你閱讀和互動。為了讓 dapp 能夠放心地完全去中心化並刪除他們的升級密鑰，他們需要確信他們的依賴項不會以破壞它們的方式升級——尤其是 L1 本身。
《大屠殺》2023年路線圖。
在满足这两种需求之间取得平衡，并最小化或逆转膨胀、复杂性和衰变，同时保持连续性，如果我们下定决心是完全可能的。生物体可以做到：虽然大多数生物会随着时间的推移而老化，一些幸運的人不.即使社會系統也能擁有極長的壽命在某些情況下，以太坊已經取得了成功：工作量證明已經消失，SELFDESTRUCT操作碼大部分也已經消失，信標鏈節點已經存儲舊數據，最多只有六個月。找到以更一般化的方式為以太坊開拓這條道路，並朝著長期穩定的最終結果邁進，是以太坊長期可擴展性、技術可持續性甚至安全性的最終挑戰。
清除：主要目標
- 通過減少或刪除每個節點永久存儲所有歷史的需求，甚至可能最終狀態，從而減少客戶端存儲要求
- 通過消除不必要的功能來減少協議的複雜性
在這一章
歷史到期
它解决了什么问题？
截至撰寫本文時，一個完全同步的以太坊節點需要大约1.1TB的磁盤空間執行客戶端另外還有幾百GB用於共識客戶端。其中絕大部分是歷史數據：有關歷史區塊、交易和收據的數據，其中大部分數據已有多年。這意味著節點的大小每年都會增加數百GB，即使gas限制保持不變。
它是什麼，它是如何運作的？
歷史存儲問題的一個關鍵簡化特徵是，因為每個區塊通過哈希鏈指向前一個區塊（和其他結構), 對於現在的共識足以對歷史達成共識。只要網絡對最新的區塊有共識，任何歷史區塊、交易或狀態（賬戶餘額、nonce、代碼、存儲）都可以由任何單個參與者提供，並且證明允許任何其他人驗證其正確性。雖然共識是一個 N/2-of-N 的信任模型，但歷史是一個 1-of-N 信任模型.
這為我們如何存儲歷史記錄開闢了許多選擇。一個自然的選擇是網路，其中每個節點只存儲一小部分數據。這就是洪流網路幾十年來的工作方式：雖然網路總共存儲和分發了數百萬個檔，但每個參與者只存儲和分發其中的幾個檔。也許與直覺相反，這種方法甚至不一定會降低數據的魯棒性。如果通過使節點運行更實惠，我們可以進入一個擁有 100,000 個節點的網路，其中每個節點存儲隨機 10% 的歷史記錄，那麼每條數據將被複製 10,000 次 - 與每個節點存儲所有內容的 10,000 節點網路完全相同的複製因數。
今天，以太坊已經開始遠離所有節點永遠存儲所有歷史的模式。共識區塊（即與權益證明共識相關的部分）僅存儲約6個月。 Blob僅存儲約18天。EIP-4444旨在引入歷史區塊和收據的一年存儲期。長期目標是在每個節點負責存儲所有內容的和諧期間(可能為約18天)，然後通過以太坊節點組成的點對點網絡以分佈方式存儲舊數據。
消除碼可以用來增加健壯性，同時保持複製因子不變。事實上，blob 已經採用了消除碼，以支持數據可用性抽樣。最簡單的解決方案可能是重複使用這種消除碼，並將執行和共識區塊數據也放入blob中。
有哪些現有研究的連結？
- EIP-4444: https://eips.以太坊.org/EIPS/eip-4444
- Torrents 和 EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
- 閘道網絡：https://ethereum.org/en/developers/docs/networking-layer/portal-network/
- 門戶網絡和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
- 如何提高燃氣上限（範式）：https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2
還有什麼要做，以及有什麼取捨？
主要剩下的工作包括建立和整合一個具體的分佈式解決方案，用於存儲歷史記錄 - 至少執行歷史記錄，但最終也包括共識和區塊。這方面最簡單的解決方案是（i）簡單地引入一個現有的種子庫，和（ii）一個名為以太坊原生解決方案的。門戶網絡. 一旦其中任何一個被引入，我們可以打開EIP-4444。 EIP-4444本身不需要硬分叉，但它需要一個新的網絡協議版本。 因此，同時為所有客戶端啟用它有價值，否則存在與其他節點連接時出現故障的風險，這些節點期望下載完整的歷史記錄，但實際上並未獲得。
主要的取捨涉及我們試圖使“古老”的歷史數據可用的程度。最簡單的解決方案是明天就停止存儲古代歷史，依賴現有的存檔節點和各種中心化提供者進行複製。這很容易，但會削弱以太坊作為永久記錄之地的地位。更難，但更安全的路徑是首先建立和整合 torrent 網絡，以分佈式方式存儲歷史。在這裡，“我們試圖”的程度有兩個維度：
- 我們會盡最大的努力確保最大的節點集合真的存儲了所有數據嗎？
- 我們將歷史存儲與協議深度整合到哪個程度？
對於（1），最大程度的偏執方法會涉及保管证明: 實際上，每個權益證明驗證器都需要存儲一定比例的歷史記錄，並定期進行密碼學檢查以確保他們這樣做。一個更溫和的方法是為每個客戶端存儲歷史記錄的百分比設定一個自願標準。
對於（2），基本實現只涉及採取今天已經完成的工作：Portal已經存儲包含整個以太坊歷史的ERA文件。更徹底的實現將涉及實際將其連接到同步過程，這樣，如果有人想要同步完整歷史存儲節點或存檔節點，即使沒有其他存檔節點在線，他們也可以從Portal網絡直接同步。
它如何與路線圖的其他部分互動？
如果我們想要使運行或啟動節點變得非常容易，那麼減少歷史存儲要求可能比無狀態更重要：節點需要擁有的 1.1 TB 中，約 300 GB 是狀態，其餘約 800 GB 是歷史。只有當無狀態和以太坊協議實施時，以太坊節點運行在智能手錶上並且只需幾分鐘設置的願景才是可以實現的。
限制歷史存儲也使得對於較新的以太坊節點實現僅支持最近版本的協議更具可行性，這使得它們變得更加簡單。例如，現在可以安全地刪除許多行代碼，因為在2016年DoS攻擊期間創建的空存儲槽已經全部被已刪除現在切換到權益證明已經成為過去，客戶可以安全地刪除所有與工作量證明相關的代碼。
狀態到期
它解决了什麼問題？
即使我們消除了用戶端存儲歷史記錄的需要，由於帳戶餘額和隨機數、合約代碼和合約存儲的持續增長，客戶的存儲需求將繼續增長，每年增長約 50 GB。用戶可以支付一次性費用，永遠給現在和未來的乙太坊客戶帶來負擔。
狀態比歷史"過期"要困難得多，因為EVM基本上是根據一個假設設計的，即一旦創建了狀態對象，它將永遠存在，並且可以被任何交易隨時讀取。如果我們引入無狀態性，可以說也許這個問題並不那麼糟糕：只有一個特殊類別的區塊生成器才需要實際存儲狀態，而所有其他節點（甚至包含清單 production!)可以無狀態運行。然而，有一種觀點認為我們不希望過分依賴無狀態，最終我們可能希望過期狀態以保持以太坊的去中心化。
這是什麼，它是如何運作的？
今天，當您創建一個新的狀態對象時（可能以三種方式之一發生：（i）將ETH發送到新帳戶，（ii）創建帶有代碼的新帳戶，（iii）設置以前未觸及的存儲槽），該狀態對象將永遠處於該狀態。相反，我們希望對象能隨著時間自動過期。關鍵挑戰是以實現三個目標的方式來完成此目標:
- 效率：不需要大量額外計算來運行到期處理過程
- 用戶友好性：如果有人進入洞穴五年後回來，他們不應該失去對他們的ETH，ERC20，NFT，CDP倉位的訪問權。
- 開發者友好：開發者不應該被迫轉換到完全陌生的思維模式。此外，今天僵化且不更新的應用程序應該繼續正常運行。
在不滿足這些目標的情況下解決問題很容易。例如，您可以讓每個狀態物件還存儲其到期日期的計數器（可以通過刻錄 ETH 來延長，這可能在讀取或寫入時自動發生），並有一個迴圈遍歷狀態以刪除過期狀態對象的進程。但是，這引入了額外的計算（甚至存儲要求），並且絕對不能滿足使用者友好性要求。開發人員也很難對涉及存儲值的邊緣情況進行推理，有時重置為零。如果你在合同範圍內設置到期計時器，這在技術上使開發人員的生活更輕鬆，但它使經濟性更加困難：開發人員將不得不考慮如何將存儲的持續成本“轉嫁”給他們的使用者。
這些是以太坊核心開發社區多年來努力解決的問題，包括像「protocol區塊鏈租金「和」regenesis最終，我們將提案的最佳部分結合起來，並收斂到兩個“已知最不壞的解決方案”類別上。
- 部分狀態過期解決方案
- 基於地址期限的狀態到期提案。
部分狀態到期
部分狀態到期提案都遵循相同的原則。我們將狀態拆分為多個塊。每個人都永久存儲「頂級地圖」，其中塊為空或非空。僅當最近訪問了每個塊中的數據時，才會存儲該數據。有一種「復活」機制，如果不再存儲塊，任何人都可以通過提供數據是什麼的證明來恢復該數據。
這些提案之間的主要區別在於：(i)我們如何定義“最近”，以及(ii)我們如何定義“區塊”？一個具體的提案是 EIP-7736，該設計建立在“莖葉圖”設計基礎之上 用於Verkle樹的介紹（儘管兼容任何形式的無狀態性，例如二進制樹）。在此設計中，相鄰的標題、代碼和存儲槽存儲在同一個“幹”下。在一個幹下存儲的數據最多可以是256 * 31 = 7,936字節。在許多情況下，一個帳戶的整個標題和代碼以及許多關鍵的存儲槽都存儲在同一個幹下。如果在一個給定的幹下的數據在6個月內沒有被讀取或寫入，則不再存儲該數據，而只存儲數據的32字節承諾（“存根”）。訪問該數據的未來交易將需要“喚醒”該數據，並提供對存根的證明，以進行驗證。
還有其他方法可以實現類似的想法。例如，如果帳戶級別的粒度還不夠，我們可以制定一個方案，其中樹的每個 1/232 部分由類似的莖葉機制控制。
這更加棘手，因為存在激勵措施：攻擊者可以通過將大量數據放入單個子樹並每年發送一筆交易來“更新樹”，從而強迫客戶永久存儲大量狀態。如果將更新成本與樹大小成比例（或者更新持續時間與樹大小成反比），那麼某人可以通過將大量數據放入與其相同的子樹中來損害另一用戶。可以嘗試通過根據子樹大小使粒度動態化來限制這兩個問題：例如，每連續的216=65536個狀態對象可以被視為一個“組”。然而，這些想法更加復雜；基於莖的方法是簡單的，並且它調整了激勵措施，因為通常莖下的所有數據都與同一應用程序或用戶有關。
基於地址期限的狀態到期提議
如果我們想避免任何永久性的狀態增長，即使是 32 位元組的存根，該怎麼辦？這是一個難題，因為@vbuterin/state_size_management#Resurrection-conflicts">resurrection conflicts: 如果一個狀態對象被刪除，後來的以太坊虛擬機執行將在完全相同的位置放置另一個狀態對象，但之後關心原始狀態對象的人回來並嘗試恢復它，會發生什麼？部分狀態過期時，“存根”會阻止新數據的創建。完全狀態過期時，我們甚至無法存儲存根。
基於位址週期的設計是解決此問題的最著名思想。我們不是讓一個狀態樹存儲整個狀態，而是有一個不斷增長的狀態樹清單，任何被讀取或寫入的狀態都會保存在最新的狀態樹中。每個週期都會添加一次新的空狀態樹（想想：1 年）。較老的州樹是凍結的固體。完整節點應僅存儲最近的兩棵樹。如果狀態物件在兩個時期內沒有被觸及，因此落入過期的樹中，它仍然可以被讀取或寫入，但事務需要證明它的 Merkle 證明 - 一旦這樣做，副本將再次保存在最新的樹中。
使這一切對用戶和開發者都友好的一個關鍵概念是地址期。地址期是地址的一部分的數字。一個關鍵規則是，具有地址期N的地址只能在期N期間或之後讀取或寫入（即當狀態樹列表達到長度N時）。如果您要保存新的狀態對象（例如新合同或新的ERC20餘額），請確保將狀態對象放入地址期為N或N-1的合同中，則可以立即保存它，而無需提供證明之前沒有任何東西。另一方面，在較舊的地址期中對狀態進行添加或編輯確實需要證明。
這種設計保留了乙太坊當前的大部分屬性，對額外計算非常輕，允許應用程式幾乎像今天一樣編寫（ERC20 需要重寫，以確保位址週期為 N 的地址餘額存儲在本身具有位址週期 N 的子合約中），並解決了“使用者進入洞穴五年”的問題。但是，它有一個大問題：位址需要擴展到 20 位元組以上以適應位址週期。
地址空間擴展
一個提議是引入一種新的32位元位址格式，其中包括版本號、位址週期號和擴展哈希。
0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF
紅色是版本號。這裡橘色的四個零被當作未來可以容納分片號的空白。綠色是地址期數號碼。藍色是 26 字節哈希。
這裡的關鍵挑戰是向後相容性。現有合約圍繞 20 位元組地址設計，並且通常使用嚴格的位元組打包技術，明確假定位址正好是 20 位元組長。@ipsilon/address-space-extension-exploration">解决此问题的一个想法涉及翻译映射，其中与新样式地址交互的旧样式合同将看到新样式地址的20字节哈希。然而，涉及使此过程安全的重大复杂性。
位址空間收縮
另一種方法則相反：我們立即禁止一些 2128 大小的位址子範圍（例如，所有以 0xffffffff 開頭的位址），然後使用該範圍引入具有位址週期和 14 位元組哈希的位址。
0xfffffff000169125d5dFcb7B8C2659029395bdF
這種方法做出的關鍵犧牲是，它對於反事實地址存在安全風險：持有資產或許可權，但其代碼尚未發佈到鏈的位址。風險涉及某人創建一個位址，該位址聲稱具有一段（尚未發佈的）代碼，但也有另一段有效代碼散列到同一位址。計算這樣的碰撞需要 280今天的哈希數; 地址空間收縮將使這個數字減少到非常可接近的256雜湊。
關鍵風險區域，即非由單一所有者持有的對應地址，目前相對較少見，但隨著進入多層次的世界，可能變得更加普遍。唯一的解決方案是接受這種風險，但要識別所有可能成為問題的常見用例，並提出有效的解決方案。
有哪些現有研究的鏈接？
- 早期提議
- 以太坊狀態大小管理理論：@vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
- 一些可能的去中心化和状态到期的路径:@vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
- 部分狀態到期提案
- EIP-7736: https://eips.以太坊.org/EIPS/eip-7736
- 地址空間擴展文件
- 原始提案：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
- Ipsilon評論：@ipsilon/地址空間擴展探索"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
- 部落格文章評論：@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">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帐户）。无状态验证器可以将这些证明组合成整个包含列表的证明。 - 我們進行部分狀態過期，並接受永久狀態大小增長速率大幅下降但仍為非零。這種結果可能與涉及點對點網絡的歷史過期提案相似，每個客戶都必須存儲歷史數據的低但固定百分比，同時接受永久歷史存儲增長速率大幅下降但仍為非零。
- 我們確實會設置到期時間，並擴展地址空間。這將涉及一個多年的過程，確保地址格式轉換方法有效且安全，包括現有應用程式。
- 我們確實會設定到期日，並縮小地址空間。這將涉及一個長達多年的過程，確保處理所有與地址碰撞相關的安全風險，包括跨鏈情況。
一個重要的觀點是，無論是否實施依賴於地址格式更改的狀態到期方案，都必須最終解決地址空間擴展和收縮的問題。如今，大約需要280要生成地址碰撞的哈希散列，對於非常充足的參與者來說，這種計算負載已經是可行的：一個 GPU 可以處理大約 227哈希，因此運行一年可以計算 252，所以全部全球约有2^30个GPU可以在大約1/4年的時間內計算出碰撞，而FPGAs和ASICs可以進一步加速這一過程。將來，這樣的攻擊將對越來越多的人開放。因此，實施完整的狀態過期的實際成本可能並不像看起來那麼高，因為我們必須解決這個非常具有挑戰性的地址問題。
它如何與路線圖的其他部分互動？
進行狀態過期有可能讓從一個狀態樹格式轉換到另一個更容易，因為不需要轉換程序：您可以直接開始使用新格式創建新樹，然後稍後通過硬分叉轉換舊樹。因此，儘管狀態過期復雜，但在簡化路線圖的其他方面確實有好處。
功能整理
它解决了什么问题？
安全、可存取性和 可信的中立性是簡單性。如果一個協議是美麗和簡單的，它減少了出現錯誤的可能性。它增加了新開發人員能夠進來並與任何部分一起工作的機會。它更有可能公平，更容易抵禦特殊利益。不幸的是，協議，像任何社會系統一樣，默默地變得越來越複雜。如果我們不希望以太坊陷入越來越複雜的黑洞，我們需要做以下兩件事之一：（i）停止進行更改並固定協議，（ii）能夠實際刪除功能並減少複雜性。還有一種中間路線，即在協議上進行較少的更改，同時隨著時間的推移，至少減少一點複雜性，也是可能的。本節將討論如何減少或刪除複雜性。
這是什麼，它是如何工作的？
沒有一個大的單一修復可以減少協議的複雜性；問題的固有性質是有很多小的修復。
一個已經大致完成並可以作為處理其他問題的藍圖的例子是，@vbuterin/selfdestruct">刪除SELFDESTRUCT操作碼。SELFDESTRUCT操作碼是唯一能夠在單個區塊內修改無限數量的存儲槽的操作碼，要求客戶端實現更多的複雜性以避免DoS攻擊。操作碼的原始目的是允許自願狀態清除，允許狀態大小隨時間減小。事實上，很少有人使用它。opcode被削弱了僅允許在 Dencun 硬分叉中的同一交易中創建的自毀帳戶。這解決了 DoS 問題，並允許顯著簡化客戶端代碼。將來，最終完全刪除操作碼可能是有意義的。
到目前為止已經確定的一些協議簡化機會的一些關鍵示例包括以下。首先，一些在以太坊虛擬機之外的示例；這些相對不具侵入性，因此更容易獲得共識並在較短的時間內實施。
- RLP→SSZ轉換：最初，以太坊對象是使用一種叫做編碼的方式進行序列化的。RLP. RLP是無類型的，並且過於複雜。今天，信標鏈使用SSZ，這在許多方面都明顯更好，包括不僅支援序列化，還支援哈希。最終，我們希望完全擺脫RLP，並將所有數據類型移動到SSZ結構中，這反過來又會使可升級性變得更加容易。目前對此的 EIP 包括[1] [2] [3].
- 移除舊交易類型：現在有太多的交易類型，其中許多可能被移除。一種更溫和的替代方案是帳戶抽象功能，智能帳戶可以包含處理和驗證舊式交易的代碼，如果他們選擇這樣做。
- 日誌改革：日誌創建布隆過濾器和其他增加協議複雜性的邏輯，但實際上客戶端不使用它，因為它太慢了。我們可以移除這些功能，而是努力尋找替代方案，比如使用像SNARKs這樣的現代技術的協議外去中心化日誌閱讀工具。
- 最終移除信標鏈同步委員會機制：同步委員會機制最初引入以便对以太坊进行轻客户端验证。然而，它给协议增加了很大的复杂性。最终，我们将能够使用SNARKs直接驗證Ethereum共識層，這將消除對專用輕客戶端驗證協定的需求。潛在地，對共識的改變可以讓我們更早地刪除同步委員會，通過創建一個更“原生”的輕用戶端協定，涉及驗證來自乙太坊共識驗證器隨機子集的簽名。
- 數據格式的協調：今天，執行狀態存儲在一個Merkle Patricia樹中，共識狀態存儲在一個SSZ樹，並且blob是承諾與之。@vbuterin/proto_danksharding_faq#blob數據的格式是什麼，它是如何提交的">KZG承諾。將來，對於塊數據和狀態，制定一個統一的格式是有意義的。這些格式將涵蓋所有重要的需求：(i) 無狀態客戶的易於證明，(ii) 數據的序列化和擦除編碼，(iii) 標準化的數據結構。
- 移除信標鏈委員會：這個機制最初是為了支援執行分片的特定版本。然而，我們最終還是進行了分片。通過 L2s 和 blobs因此，委員會是不必要的，所以有一個正在進行移除它們的過程.
- 移除混合字节顺序：EVM 是大端字节序，共识层是小端字节序。重新协调并使一切都是大端或小端可能是有道理的（可能是大端，因为更改 EVM 较为困难）
現在，一些在EVM內的範例：
- 簡化瓦斯機制：目前的瓦斯規則並不完全優化，無法清晰界定驗證區塊所需的資源數量。其中的關鍵問題包括（i）存儲讀寫成本，旨在限制區塊中的讀寫次數，但目前相當混亂；以及（ii）填充記憶體規則，目前很難估計EVM的最大記憶體消耗。建議的修復方法包括 無狀態性燃氣成本變化，將所有與存儲相關的成本統一到一個簡單的公式中，並這個有關記憶定價的提案.
- 移除預編譯：當前以太坊的許多預編譯過於複雜，並且相對很少被使用，佔據了共識失敗接近失敗的大部分，實際上卻沒有被任何應用程序使用。處理此問題的兩種方法是 (i) 刪除預編譯，以及 (ii) 用實現相同邏輯的 EVM 代碼替換它（必然更昂貴）。該草案EIP提議作為第一步，對於身份編譯進行此操作；之後，RIPEMD160、MODEXP和BLAKE可能成為移除的候選項。
- 刪除瓦斯可觀察性：使EVM執行無法再看到剩餘的瓦斯數量。這將破壞一些應用程式（尤其是贊助交易），但將使未來升級更加容易（例如，用於更高級版本的協議）多維氣體). EOF規範已經使氣體不可觀察，但為了協議簡化的實用性，EOF需要成為強制性的。
- 靜態分析的改進: 目前 EVM 代碼很難靜態分析，特別是因為跳轉可以是動態的。這也使得更難以將優化的 EVM 實現編譯成其他語言的 EVM 代碼。我們可以通過...來潛在地解決這個問題。移除動態跳轉（或使它們變得更加昂貴，例如，燃氣成本與合約中的JUMPDEST總數呈線性關係）。 EOF 可以實現這一點，但要實現協議簡化的收益，需要將 EOF 視為強制性的。
一些現有研究的連結是什麼？
- 清除中的後續步驟：https://notes.以太坊.org/I_AIhySJTTCYau_adoy2TA
- SELFDESTRUCT: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
- SSZ-化的EIPS: [1][2] [3]
- 狀態無關性的燃氣成本變化：https://eips.ethereum.org/EIPS/eip-4762
- 線性記憶體定價:https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
- 預編譯移除：https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
- 布隆過濾器移除：https://eips.以太坊.org/EIPS/eip-7668
- 使用增量可驗證計算（即：遞歸STARKs）來進行鏈下安全日誌檢索的方法：https://notes.以太坊.org/XZuqy8ZnT3KeG1PkZpeFXw
還有什麼事要做，以及有什麼取捨？
進行這類功能簡化的主要折衷是(i)我們簡化的程度和速度 vs (ii)向後兼容性。 以太坊作為一個平台的價值在於你可以部署應用程序並且有信心它多年後仍然能正常運作。 同時，將這個理想推向極致也是可能的，改述威廉·詹宁斯·布莱恩，“將乙太坊釘在向後相容性的十字架上”。如果整個乙太坊中只有兩個應用程式使用給定的功能，並且一個使用者多年來為零，另一個幾乎完全未使用並且總共獲得了 57 美元的價值，那麼我們應該刪除該功能，如果需要，請自掏腰包向受害者支付 57 美元。
在創建標準化管道以進行非緊急向後兼容性破壞性更改方面存在著更廣泛的社會問題。解決這個問題的一種方法是檢視和擴展現有的先例，比如SELFDESTRUCT過程。該管道大致如下：
- 步驟1：開始討論移除功能X
- 第2步：進行分析以確定去除X會對應用程序造成多大的破壞，根據結果，要么（i）放棄這個想法，（ii）按計劃繼續，或（iii）找出一種修改的“最不具破壞性”的方式來去除X並繼續進行
- 步驟3：提出正式的以太坊改進提案（EIP），使X過時。確保受歡迎的高級基礎設施（例如，編程語言、錢包）尊重這一點並停止使用該功能。
- 第四步：最後，實際上移除X
步驟1和步驟4之間應該有一條多年的管道，清楚地知道哪些項目在哪個步驟。此時，存在著如何積極迅速地進行特徵刪除管道與更加保守地投入更多資源進行協議開發其他領域之間的權衡，但我們仍遠離Pareto前沿。
EOF
EVM 提出了一系列重大變更EVM Object Format (EOF). EOF引入了很多改變，例如禁止氣體可觀察性，代碼可觀察性（即沒有CODECOPY），只允許靜態跳躍。目標是允許更多地升級EVM，以一種具有較強屬性的方式，同時保留向後兼容性（因為先前的EOF EVM仍然存在）。
這樣做的優點是可以為新增的EVM功能創建一個自然的途徑，並鼓勵遷移到具有更強保證的更嚴格的EVM。這樣做的缺點是會顯著增加協議的複雜性，除非我們能找到一種方法來最終淘汰並刪除舊的EVM。一個主要問題是：在EVM簡化提案中，EOF在其中扮演什麼角色，特別是如果目標是減少整個EVM的複雜性？
它如何與路線圖的其他部分交互？
在路線圖的其餘部分中，許多“改進”提案也是對舊功能進行簡化的機會。從上面重複一些例子：
- 切換到單個插槽最終性給了我們一個機會，可以去除委員會，重塑經濟，並進行其他與權益證明相關的簡化。
- 完全實現帳戶抽象化讓我們能夠移除許多現有的交易處理邏輯，將其轉移到一塊“默認帳戶EVM代碼”中，所有EOA都可以被替換。
- 如果我們將以太坊狀態轉移到二進制哈希樹中，這將可以與新版本的SSZ協議協調一致，這樣所有以太坊數據結構都可以以相同的方式進行哈希。
更激進的方法：將協議的大部分轉換為合約代碼
一种更激进的以太坊简化策略是保持协议不变，但将其大部分功能从协议功能转移到合约代碼。
這種極端版本的做法是讓以太坊L1“技術上”僅僅是信標鏈，並引入一個最小的VM（例如。RISC-V, 開羅，或者甚至更專注於證明系統的最小化專用系統），這允許任何其他人創建自己的Rollup。然後，EVM將成為這些Rollup中的第一個。這具有諷刺意味，正是與“”完全相同的結果。2019-20年的執行環境提案然而，SNARKs使得實際實施變得更加可行。
一種更溫和的方法是保持信標鏈與當前以太坊執行環境之間的關係不變，但對EVM進行就地交換。我們可以選擇RISC-V、Cairo或另一個虛擬機作為新的“官方以太坊虛擬機”，然後強制將所有EVM合約轉換為解釋原始代碼邏輯的新VM代碼（通過編譯或解釋）。從理論上講，這甚至可以使用“目標VM”作為EOF的一個版本來完成。
免責聲明：
- 本文轉載自 [Vitalik Buterin], 所有版權歸原作者所有 [Vitalik Buterin]. 如果對此轉載有異議，請聯繫Gate 學習團隊會立即處理。
- 責任聲明：本文所表達的觀點和意見僅為作者個人觀點，並不構成任何投資建議。
- 文章的翻譯工作由gate Learn團隊完成。除非另有說明，禁止複製、分發或抄襲翻譯後的文章。
相關文章
如何質押 ETH？