Paradigm：以太坊坎昆升級後的下一步是什麼？

由於誘發需求，提高L1 gas限制實際上並不會有太大效果。

撰文：Georgios Konstantopoulos

編譯：深潮TechFlow

導讀

這篇文章的目的是概述 Paradigm Reth 團隊對布拉格會議（坎昆會議之後的下一個 EL 硬分叉）應包含哪些 EIP （以太坊改進提案），以及2024年“EL核心開發”計劃的看法。文中的觀點僅代表Reth團隊當前的觀點，並不一定代表整個Paradigm團隊的立場。

摘要

我們認為，布拉格硬分叉（Prague hard fork）可能在2024年第三季度在以太坊測試網上實施，並在年底前在主網上實施。它應該包括：

• 任何與質押相關的 EIP，例如 EIP-7002，它支持再質押和無需信任的質押池。

• 獨立的EVM更改。

• 我們願意與任何團隊合作，進一步調查布拉格或其他未來EL硬分叉的難題，樂意提供指導或協助調整Reth代碼庫。

應做的事情：

• 我們認為以下EIP必須優先考慮：7002、6110、2537。

• 我們支持EOF（EVM對象格式）的規範描述，但希望儘快確定其範圍，並創建一個致力於該範圍的元 EIP（meta-EIP）。

• 我們願意增加EIP-4844的最大Blob Gas。我們對正確的數位沒有具體看法，但我們邀請數據人員與我們合作調查這個主題。

• 我們願意推出EIP-7547的版本：包含列表，以幫助基層抵抗審查。

不應做的事情：

• 我們不支持在布拉格中引入Verkle Tries，但支持客戶端團隊從2024年第二季度開始努力實現它，並承諾在2025年中/晚期的大阪硬分叉中發佈它。

• 我們認為不應該增加L1執行Gas上限或合約大小，但我們邀請數據人員與我們合作調查對網路的影響。我們願意根據以往的測試結果（顯示Reth節點可以承受增加的負載）來重新考慮我們的立場。

• 我們認為錢包/賬戶抽象化EIP需要更多的實戰測試，以更好地理解它們之間的權衡。如果它們不是互斥的，那麼我們將來願意部署多個與AA相關的EIP。

• 如果社區對傳言中的NSA後門（NAS backdoor）表示接受，我們可能會在EIP-7212（secp256r1）上做出決定。

• 其他路線圖主題：我們對CL EIP或CL/EL分叉的耦合沒有直接看法，但EIP 7549和7251看起來很有前途。我們也願意盡可能從EL方面為PeerDAS的工作做出貢獻。我們目前希望避免引入SSZ根（EIP 6404、6465、6466）。最後，我們注意到有機會為過期的 blob、歷史記錄和狀態提供長期數據歸檔解決方案，因為 EIP-4844 和 EIP-4444 都沒有指定這一點，而且以太坊是否願意提供這樣的解決方案還有待確定。

下面是全文詳細的介紹。

應做的事情：

簡單來說，我們支持

• 進一步縮小CL和EL之間的差距

• 可作為單人工作執行的 EVM 修改，可進行獨立和並行測試。

EIP-7002

該 EIP 可讓 EL 端的智慧合約控制 CL 端的 1 個或多個驗證器，從而解鎖了無需信任的再質押和質押池。從我們的角度來看，這是一個不費吹灰之力的 EIP，因為它至少能讓現有的質押池從實現提款的智慧合約中移除一層中心化。

將有狀態預編譯引入 EVM 是我們需要在 EVM 實現中捕獲的新抽象，但除此之外，我們認為這是一個可以直接執行的 EIP。

EIP-6110

這個EIP在EL狀態中引入存款，建恩化了在CL上需要進行的狀態管理。實際上，這類似於跟蹤CL提款，所以總體上我們認為這也是一個容易且獨立實施的EIP。

EIP-2537

目前已經有多種BLS12-381的實施方式，並且它是許多SNARKs、BLS簽名算法和EIP-4844中頻繁使用的曲線。我們認為實施的複雜性很低，因為它只是通過預編譯接口公開曲線的驗證算法。我們可能還需要一個 BLS12-381 曲線預編譯的哈希接口。

EOF

簡而言之：支持一個定義明確的版本，Solidity和Vyper將會採用。代碼格式和驗證調整可使分析更容易，這一點毋庸置疑，除此之外，我們建議慎重考慮。我們建議採用以下幾個 EIP，但我們對進一步的刪減持開放態度。

好的方面：

• 只涉及EVM的變更，可以通過ethereum/tests測試，並由一個人實施

• Vyper和Solidity想要的EVM的改變

• 有助於提升性能和增加合約大小上限

• 消除了 EVM 在運行時進行位元組碼分析的需要，在不涉及緩存的情況下，分析的時間可能高達 50%，並且隨著合約大小的增加而增加

• 支持部分代碼載入，有助於執行大型智慧合約

• 開發體驗：將允許通過 dupN/swapN 和其他工具改進來修復“堆棧太深”的問題

• 面向未來： 可以安全地在 L2 中引入新功能，而且工具知道哪些是相容的

不好的方面：

• 範圍和移動目標

• 沒有強有力的推動者促成其納入

• 遺留代碼仍然需要支持

• 在採用之前，以太坊主網和其他 EVM 鏈之間存在暫時分歧

我們認為應在 2024 年部署以下 EOF 功能。我們建議儘快確定範圍，並做出承諾。其他內容應考慮後續部署。我們的建議包括：

• EIP-3540：EOF – EVM對象格式v1：引入代碼和數據容器，為以太坊位元組碼添加結構和版本控制。

• EIP-3670：EOF – 代碼驗證：拒絕部署時不遵循 EOF 格式的任何合約。實施更結構化的代碼並禁用無效和未定義的指令。

• EIP-663：無限制的SWAP和DUP指令：這解決了 Solidity 中的“堆棧太深”問題，具有立即價值的JUMPDEST分析可能會產生副作用。這對EVM語言非常有吸引力。

• EIP-4200：EOF – 靜態相對跳轉：更好的靜態分析，沒有不確定的跳轉。相對跳轉更利於代碼的可復用性。

• EIP-4750：EOF – 函數：解決使用靜態跳轉而不是動態跳轉時可能的副程式問題。此外，它還允許部分代碼載入，這與 Verkle 配合良好並增加了合約大小限制。

• EIP-5450：EOF – 棧驗證：驗證代碼和棧要求。除了CALLF (EIP-4750)指令外，移除所有指令的運行時棧下溢和溢出檢查。

• EIP-7480：EOF – 數據部分訪問指令：允許訪問位元組碼的數據部分。

• EIP-7069：改進的CALL指令：允許從CALL中刪除gas可觀察性，從而使將來更容易重新定價 gas。雖然獨立於 EOF，但我們認為這是引入它的好機會。

我們對EIP-6206：EOF – JUMPF和非返回函數的確定性較低。雖然它允許在 EOF 函數中進行尾部調用優化，但我們仍然需要看到語言分析其有用性。如果我們沒有這些，我們認為可以將其從範圍中刪除幷包含在後續 EOF 更新中。

我們將上述工作預算為 1 人全職工作 1-2 個月的世界。如果這意味著保持勢頭，我們願意進一步縮小上述範圍。

關於遺留位元組碼的說明：

• 雖然我們可以禁止新的遺留/非EOF位元組碼，但無法棄用現有的遺留位元組碼，這實際上相當於EOF的“v0”。遺留位元組碼在EOF後仍需要JUMPDEST分析，並且還需要特殊代碼處理，以將其分段到Verkle Tries中。

• 據我們所知，沒有可驗證的方法可以在沒有源代碼的情況下將非EOF位元組碼轉換為EOF，但我們願意探索促進這種轉換的機制。

• 另外，我們也願意探討強制遷移狀態到EOF的到期方法。

增加EIP-4844 Blob數量

我們對這一修改持開放態度，根據 EIP-4844 的上下文，這相當於增加了 MAX_BLOB_GAS_PER_BLOCK 和 TARGET_BLOB_GAS_PER_BLOCK：

• TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的目標值分別為每個區塊 3 個 Blob（0.375 MB）和最多 6 個 Blob（0.75 MB）。這些較小的初始限制旨在最大限度地減少本 EIP 對網路造成的壓力，隨著網路在更大區塊下顯示出可靠性，預計將在未來的升級中增加這些限制。

• 實際上這是一個小的代碼更改，我們需要調查它在 txpool 中的實際影響，但我們認為我們可以重用EIP-4844的壓力測試基礎設施進行此項工作。可能 CL 更難傳播更多的 Blob，我們聽從 CL 團隊的意見。

不應做的事情

Verkle Tries

簡而言之，我們看不到Verkle tries在2024年底/2025年初部署的途徑。我們建議團隊在2024年第二季度分配資源，並承諾在 2025 年第二季度至第三季度在大阪硬分叉中部署。

好的方面：

• 通過更小的存儲證明實現更便宜的輕客戶端。

• 通過在區塊頭中包含讀取預狀態實現無狀態執行，這也可通過靜態狀態訪問提高性能。

• 通過分塊位元組碼和啟用部分代碼載入來提高合約大小限制。

• 狀態過期變得更加可接受，因為恢復狀態的成本更低。

不好的方面：

• 變更的影響以及實施和測試的集成工作。

• Gas 核算變化：Verkle Tries將見證的大小引入Gas計算函數。我們擔心存儲定價的變化尚未被探索（例如，Verkle後頂級Gas消耗者的成本將是多少？）。

• 應用集成：在Overlay轉換運行時，具有Merkle Patricia Trie驗證器的應用應該如何處理？eth_getProof應該如何表現？

雖然我們理解 Verkle Tries 的好處，但我們認為需要更多考慮第三方工具/合約需要如何調整，以及過渡對第 2 層解決方案等的影響。最初，我們對遷移策略持懷疑態度，因為它要求在從現有的MPT（Merkle Patricia Trie）讀取狀態時更新Verkle樹，但現在這種情況似乎已經改變。因此，我們支持覆蓋樹方法作為可行的遷移路徑。

關於Verkle樹的遷移策略的文檔普遍過時，大多數資源仍然聲稱在從MPT讀取狀態時應更新Verkle樹，儘管實際並非如此。我們希望看到關鍵的過渡文檔更新為最新的方法，例如這篇出色的文檔。我們還希望看到關於遷移策略的草案EIP（Ethereum Improvement Proposal）。

因此，我們仍然支持其在2025年的推出，但不認為在布拉格會有部署該系統的可能。

L1 Gas限制

我們認為，由於誘發需求，提高L1 gas限制實際上並不會有太大效果。我們還認為，大多數客戶端可以處理平均負載的增加，但我們想對最壞情況保持警惕，所以我們目前還不能建議增加L1 gas限制。我們認為短期內增加blob gas限制是一個更有希望的解決方案。

我們邀請人們與我們合作進行這方面的研究，通常圍繞打破 EVM 中的資源計量進行。《Broken Metre》論文是這一研究方向的一個很好的起點。

賬戶抽象

我們願意包含一個或多個這些EIP（或納入ERC），但我們理想中希望看到更多關於每個提案的用戶體驗和開發者體驗的比較，以便更好地瞭解工具集成的權衡空間和工作量。我們正在關注以下EIP/ERC，但也歡迎大家向我們推薦更多：

• EIP-3074：AUTH 和 AUTHCALL 操作碼

• ERC-4337：使用 Alt Mempool 進行賬戶抽象

• EIP-5806：委託交易

• EIP-5920：PAY 操作碼

• EIP-6913：SETCODE 指令

• EIP-7377：遷移事務

• RIP-7560：本機帳戶抽象 – 核心 EIP

需要指出的是，在上述內容中，“賬戶抽象”指的是“抽象驗證函數，主要目標是實現密鑰輪換，使多重簽名成為一流的技術，並為我們提供自動的抗量子路徑，僅適用於4337和7560，而其他提案則分為兩類：Gas贊助和批量操作。