未向財經radigm CTO：解讀以太坊坎昆升級後的布拉格硬分叉

我們認為布拉格硬分叉可能會在2024 年第三季在以太坊測試網路上實現，並於年底在主網上完成。

撰文：Georgios Konstantopoulos，Paradigm CTO

編譯：Luffy，Foresight News

本文的目的是概述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 年推出，而不是布拉格硬分叉中部署。