本文總結了Paradigm Reth團隊對以太坊的下一個重要升級布拉格硬分叉的觀點。該團隊認為布拉格硬分叉可能會在2024年第三季在以太坊測試網路上實現，並於年底在主網上完成。他們支持某些EIP的優先考慮，例如支持重新質押和消耗信任質押池的EIP-7002。但他們不支持在布拉格硬分叉中加入Verkle Tries，也不支持增加L1執行Gas或合約規模。他們也提到了對EOF和帳戶摘要等EIP的看法。同時，他們願意與其他團隊合作，並提供指導和協助。
原文標題：《以太坊坎昆硬分岔之後會發生什麼事？ 》
譯者：Georgios Konstantopoulos，Paradigm CTO
編譯：路飛，預見新聞
本文的目的是概述Paradigm Reth 團隊對於布拉格硬分叉（坎昆硬分叉後以太坊的下一次重要升級）應包含哪些EIP 的觀點，以及我們2024 年“EL Core Dev”的總體計劃（譯者）註：EL 指執行層，CL 指意見層）。以下觀點仍在不斷變化，僅代表Reth 團隊目前的觀點，不一定代表整個Paradigm 團隊。
我們認為布拉格硬分叉可能會在2024 年第三季在以太坊測試網路上實現，並於年底在主網上完成。它應包括：
· 與質押相關的EIP，例如支持重新質押和消耗信任質押池的EIP-7002。
·單獨的EVM變化。
· 我們願意與任何想要的進一步研究布拉格或其他未來EL 硬分叉的團隊合作，並樂意在修改Reth 程式碼庫的地方提供指導和幫助。
要做什麼：
· 我們認為必須優先考慮以下EIP：7002、6110，2537。
· 我們支援規格中所述的EOF，希望加快最終確定範圍並建立元EIP。
· 我們願意增加EIP-4844 Max Blob Gas。我們對具體的數字沒有看法，但我們邀請數據人員與我們合作研究這個主題。
· 我們願意發布EIP-7547 的版本：它包含一個幫助基礎層抗審查的清單。
不要做什麼：
· 我們不支援布拉格硬分叉中加入Verkle Tries，但支援客戶端團隊在2024年第2季開始為此努力，並承諾將於2025年的大阪升級中發布。
· 我們認為不應該限制增加L1執行Gas或合約規模，但我們邀請資料人員與我們合作調查它對網路的影響。
· 我們願意改變我們的看法，因為過去的測試表明Reth 節點可以毫無問題地處理增加的負載率。
· 我們認為錢包/帳戶抽象化EIP需要進行更廣泛之間的測試對抗，以便更好地了解權衡空間。
· 如果它們不相互相容，那麼我們將願意在未來部署多個與AA 相關的EIP。
· 如果社群同意NSA 後門的謠傳，我們可以越過EIP-7212 (secp256r1) 上的線。
· 其他路線圖主題：我們對CL EIP 或CL/EL 分叉的耦合沒有實際了解，但EIP 7549 和7251 看起來很有希望。我們也希望從EL 方面為PeerDAS 的工作做出貢獻。我們希望避免引入SSZ 根（EIP 6404、6465、6466）。最後，我們發現有機會針對過期的blob、記錄歷史和狀態提供長期資料歸檔解決方案，因為EIP-4844 和EIP-4444 都明確說明了這一點一點，以太坊是否願意提供這樣的解決方案還有待確定。
以下詳細展開。
做的事
抽像地說，我們支持1) 進一步縮小CL 和EL 之間的差距，2) EVM 可以作為單人工作執行，並且可以單獨和任務測試。
EIP-7002
此EIP透過使EL側的智能合約能夠控制CL側的1個或多個驗證器來解鎖消耗信任的重新質押和質押池。在我們看來，它至少承載現有的質押池能夠從實現提該款智能合約中消除了層級中心化。
將有狀態預先編譯引入EVM 是我們需要在EVM 實作中獲得的新抽象，但除此之外，我們認為這是一個可以直接執行的EIP。
EIP-6110
此EIP引入了EL狀態中的，簡化了需要在CL完成上的狀態管理。在實施方面，這類似於追蹤CL提款，因此總的來說，我們認為這也是一個簡單且獨立的EIP。
EIP-2537
目前BLS12-381 有多種實現，它是許多SNARK、BLS 簽章演算法和EIP-4844 中經常使用的曲線。我們認為它實現的複雜度很簡單，因為它只是透過預編譯介面公開曲線的驗證演算法。可能還需要BLS12-381曲線預編譯的雜湊值。
EOF
譯者註：EOF全稱為EVM物件格式，譯為以太物件格式，包含一系列EIP，承諾使以太坊執行更有效率、更一致且更可升級。早期計劃在上海昇級中實施，後來刪除。
EOF 將同時支援Solidity 和Vyper。沒有疑問，程式碼格式和驗證調整使我們的字節碼分析變得更加簡單，我們建議仔細考慮下面除此之外的事情。在推薦了一些EIP，我們但願意進一步調整。
好的方面：
· 僅限EVM的更改，可以使用以太坊/測試網進行測試並由單人實施。
· Vyper 和Solidity 想要的EVM 變更有助於提高效能和增加大規模規模限制。
· 消除了EVM在運行時進行字節碼分析的需求。
· 在不涉及伺服器的情況下，分析的時間可能高達50%，並且隨著大小的增加而增加。
· 啟用部分程式碼加載，有助於執行大型智能合約。
· Devex：將允許透過dupN/swapN 和其他工具改進來修復「堆疊太深」的問題。
· 面向未來：可以安全地跨越L2 引入新功能，並且工具會知道什麼是相容的。
不好的方面：
· 範圍和動態目標。
· 沒有支持者大力推動其納入產品。
· 在EVM鏈之間存在暫時關閉之前，在採用、以太坊主網等方面仍然需要支援繼承代碼。
我們認為以下EOF 功能應在2024 年部署。我們建議加快確定範圍並承諾實施。後續部署應該考慮其他任何事情。我們的建議是：
· EIP-3540（EOF – EVM 物件格式v1）：引入程式碼和資料容器，傳送以太坊字節碼新增結構和版本控制。
· EIP-3670（EOF – 代碼驗證）：拒絕部署時不遵循EOF 格式的任何約定。
· 執行更建構的程式碼並取消無效和未定義的指令。
· EIP-663（無限的SWAP和DUP指令）：這解決了solidity中的「堆疊太深」問題，並且透過JUMPDEST分析作為即時值有副作用。 evm語言非常想要的功能。
· EIP-4200（EOF – 靜態相對跳轉）：更好的靜態分析，沒有不確定的跳躍。更好的aot 編譯。相對跳轉更有利於程式碼重複使用。
· 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 數量
我們對此改變持開放態度，這將對應於MAX_BLOB_GAS_PER_BLOCK 和TARGET_BLOB_GAS_PER_BLOCK 的增加。 EIP-4844 中的相關內容為：
選擇TARGET_BLOB_GAS_PER_BLOCK 和MAX_BLOB_GAS_PER_BLOCK 的值以對應每區塊3 個blob (0.375 MB) 的目標（最多6 個blob）。這些小目標限制旨在最大限度地減少該EIP 對網路造成的壓力，並且隨著網路在增量區塊下表現出可靠性，預計區塊數量將在未來的升級中增加。
實際上，這是一個小代碼更改，我們需要調查它在交易池中的實際影響，但我們認為我們可以因此重新使用EIP-4844 壓力測試設施。 CL 可能很難傳播更多的blob，我們尊重CL 隊伍的意見。
不要做的事
韋爾克爾嘗試
TL;DR：我們看不到2024 年底/2025 年初部署Verkle 的嘗試。我們建議團隊在2024 年第二季分配資源，並承諾在2025 年第二季至第三季在大阪硬分叉中部署。
好的方面：
· 透過更小的儲存名稱實現更便宜的輕客戶端。
· 透過在區塊頭中包含讀取預狀態來進行無狀態執行，這也可能由於靜態狀態存取而導致效能提高。
·透過對字節碼進行分塊並啟用部分程式碼載入來提高合約大小限制。
·由於「恢復」狀態的成本較低，狀態變得更容易接受。
不好的地方：
· 變化的影響以及實施和測試的努力。
·Gas計算變化：Verkle嘗試將見證者的大小引入Gas計算功能中。我們擔心倉儲定價的變化尚未被探索（例如，Verkle之後頂級Gas消耗者的成本是多少）？
· 應用程式整合：當Overlay 端點運行時，具有Merkle Patricia Trie 驗證者的應用程式應該做什麼？ eth_getProof 應該如何表現？
雖然我們了解Verkle Tries 的好處，但我們需要考慮更多第三方工具/合約需要如何適應，以及在過渡期間對Layer 2 等產生什麼影響。最初我們對遷移策略有疑問，因為它規定當從預先存在的MPT 讀取狀態時應該更新Verkle trie，但情況似乎不再如此了。因此，我們支援Overlay 方法作為可行的遷移路徑。
Verkle 遷移策略的文檔似乎已經過時，因為大多數資源仍然指出從MPT 讀取狀態時應該更新Verkle trie，。我們希望看到採用最新方法的過渡文檔，例如這篇優秀的文檔。我們也希望看到相關的過渡策略EIP草案。
因此，我們仍然支援其在2025 年推出，而不是布拉格硬分叉中部署。
L1 氣體限制
我們認為，提高L1 Gas 限制在實務上不會產生重大作用。我們也認為大多數客戶我們可以應對平均負載增加，但我們希望對最壞的情況保持警惕，因此目前不建議增加L1 Gas 限制。我們認為增加斑點氣體限制是短期內更多希望的解決方案。
我們邀請其他人與我們合作進行這個方向的研究，通常圍繞著打破EVM中的資源計量進行。 Broken Meter論文是這方面研究的一個很好的起點。
帳戶摘要
我們願意包含1 個或多個EIP，但我們希望看到每個提案之間有更多的使用者體驗和開發者體驗的比較，以便更好地了解工具整合的權衡空間和工作量。我們正在關注以下為EIP/ERC，但請隨時向我們提出建議：
· EIP-3074：AUTH 和AUTHCALL 操作碼
· ERC-4337：使用Alt Mempool進行帳戶抽象
· EIP-5806：委託交易
· EIP-5920：PAY操作碼
· EIP-6913：SETCODE 指令
· EIP-7377：遷移交易
· RIP-7560：原始插畫抽象– 核心EIP – 以太坊魔術師聯誼會
這裡我們需要注意的是，「帳戶抽象化」正如「抽象驗證函數，主要目標是實現金鑰輪換，使帳戶簽章成為關鍵，並為我們提供一條自動實現量子抗性的路徑」。
原文連結
資訊來源：0x資訊編譯自網際網路。版權所有，未經許可，不得轉載！