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 Object Format，譯為以太坊對象格式，包含一系列 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 對網路造成的壓力，並且隨著網路在較大區塊下展現出可靠性，預計 blob 數量會在未來的升級中增加。

實際上，這是一個小的代碼更改，我們需要調查它在交易池中的實際影響，但我們認為我們可以為此重新使用 EIP-4844 壓力測試基礎設施。CL 可能很難傳播更多的 blob，我們尊重 CL 隊伍的意見。

不要做的事

Verkle Tries

TL;DR：我們看不到 2024 年底 /2025 年初部署 Verkle 的嘗試。我們建議團隊在 2024 年第第二季為此分配資源，並承諾在 2025 年第第二季至第第三季在大阪硬分叉中部署。

好的方面：

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

· 通過在區塊頭中包含讀取預狀態來進行無狀態執行，這也可能由於靜態狀態訪問而導致性能提高。

·通過對字節碼進行分塊並啟用部分代碼加載來提高合約大小限制。

·由於「恢復」狀態的成本較低，狀態到期變得更容易接受。

不好的地方：

· 變化的影響以及實施和測試的努力。

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

· 應用程序集成：當 Overlay 過渡運行時，具有 Merkle Patricia Trie 驗證者的應用程序應該做什麼？eth_getProof 應該如何表現？

雖然我們了解 Verkle Tries 的好處，但我們認為需要更多地考慮第三方工具 / 合約需要如何適應，以及過渡期間會對 Layer 2 等產生什麼影響。最初我們對遷移策略有疑問，因為它規定當從預先存在的 MPT 讀取狀態時應該更新 Verkle trie，但情況似乎不再如此了。因此，我們支持 Overlay 方法作為可行的遷移路徑。

Verkle 遷移策略的文檔似乎已經過時，因為大多數資源仍然指出從 MPT 讀取狀態時應該更新 Verkle trie，。我們希望看到採用最新方法的過渡文檔，例如這篇優秀的文檔。我們還希望看到有關過渡策略的 EIP 草案。

因此，我們仍然支持其在 2025 年推出，而不是布拉格硬分叉中部署。

L1 Gas 限制

我們認為，提高 L1 Gas 限制在實踐中不會產生太大作用。我們還認為大多數客戶可以應對平均負載增加，但我們希望對最壞的情況保持警惕，因此我們目前不建議增加 L1 Gas 限制。我們認為增加 blob 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 - Fellowship of Ethereum Magicians

上述我們需要注意的是，「帳戶抽象」正如「抽象驗證函數，主要目標是實現密鑰輪換，使多重簽名成為關鍵，並為我們提供一條自動實現量子抗性的路徑」。

原文連結