以太坊要分道揚鑣？詳細解說「Prague 硬分叉」，會帶來哪些改變？

金融 2024.01.19

本文討論了以太坊坎昆硬分叉後的未來展望，包括 Reth 團隊提出的硬分叉計劃和新的EVM物件格式EOF。

這篇文章的目的是概述 Paradigm Reth 團隊對哪些 EIP 應該包含在 Prague、坎昆升級之後的下一個 EL 硬分叉以及關於 2024 年「EL Core Dev」總體計劃的看法。以下觀點是不斷變化的，僅代表 Reth 團隊當前的觀點，不一定代表更廣泛的 Paradigm 團隊。

我們認為 Prague 硬分叉有可能在 2024 年第三季在以太坊測試網路上進行，並於年底在主網上進行。它應該包括：

任何與質押相關的 EIP，如 EIP-7002，它可以實現重新質押和無信任質押池；
孤立的 EVM 變更。

我們願意與任何希望進一步研究 Prague 或其他未來 EL 硬分叉問題的團隊合作，並歡迎指導或提供有關修改 Reth 程式碼庫的指導。

支援：

我們認為必須優先考慮以下 EIP：7002、6110、2537。
我們支援規範中所述的 EOF，但希望儘快確定其範圍，並建立一個該範圍的元 EIP。
我們對增加 EIP-4844 Max Blob Gas 持開放態度。我們對合適的數字還沒有定論，但我們邀請數據人員與我們一起研究這個問題。
我們願意提供 EIP-7547 版本：納入列表，以協助抵制基礎層審查。

不支援：

我們不支持在 Prague 中的 Verkle Trees，但支援客戶團隊在 2024 年第 2 季開始努力，並承諾在 2025 年中、末在 Osaka 中交付。
我們認為不應增加 Layer1 執行 Gas 限額或合約規模，但我們邀請資料人員與我們合作，共同調查對網路的影響。由於過去的測試表明 Reth 節點可以順利處理增加的負載，因此我們願意修改我們的觀點。
我們認為，錢包、帳戶抽象 EIP 需要進行更多的對戰測試，以更好地了解它們之間的權衡空間。如果它們並不互相排斥，那麼我們願意在未來部署多個與 AA 相關的 EIP。
如果社群對傳言中的 NSA 後門沒有意見，我們可能會在 EIP-7212 (secp256r1) 中取得突破。
其他路線圖主題：我們對 CL EIP 或 CL/EL 分叉的耦合沒有實際看法，但 EIP-7549 和 7251 似乎很有前途。我們也希望在可能的情況下，從 EL 方面為 PeerDAS 的工作做出貢獻。目前，我們希望避免引入 SSZ 根（EIP-6404、6465、6466）。最後，我們注意到，EIP-4844 和 EIP-4444 均未指定過期 blob、歷史和狀態的長期資料存檔解決方案，而以太坊是否願意提供這樣的解決方案尚待確定。

支援

抽象地說，我們支援以下兩點：

進一步縮小 CL 和 EL 之間的差距；
EVM 修改可作為單人工作執行，並可進行隔離和平行測試。

EIP-7002

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

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

EIP-6110

這將在 EL 狀態中引入存款，簡化了需要在 CL 上完成的狀態管理。從實施角度來看，這與追蹤 CL 提款類似，因此總體而言，我們認為這也是一個易於實施且獨立的 EIP。

EIP-2537

目前已有多種 BLS12-381 實現，它是許多 SNARK、BLS 簽章演算法和 EIP-4844 中經常使用的曲線。我們認為實現的複雜度很低，因為它只是透過預編譯介面公開了曲線的驗證演算法。我們可能還需要 BLS12-381 曲線預編譯的雜湊演算法。

EOF

簡而言之：支援 Solidity 和 Vyper 將採用的範圍明確的版本。程式碼格式和驗證調整可使分析更容易，這一點毋庸置疑。我們建議仔細考慮除此之外的任何內容。我們在下面推薦了一些 EIP，但我們願意進一步調整。

優勢：

僅對 EVM 進行更改，可透過以太坊/測試進行測試，並由一人實施。
Vyper 和 Solidity 想要的 EVM 變更！
有助於提高效能和增加合約大小限制。
消除了 EVM 在運行時進行位元組碼分析的需要，在不涉及快取的情況下，這可能需要多達 50% 的時間，並隨著合約大小的增加而增加。
啟用部分程式碼加載，有助於執行大型智能合約。
Devex：將允許使用 dupN/swapN 修復 Solidity 中的「堆疊過深」問題，並改進其他工具。
面向未來：可以安全地在 Layer2 中引入新功能，並且工具會知道什麼是相容的。

劣勢：

範圍和移動目標。
沒有支持者大力推動將其納入。
遺留程式碼仍需支援。
在採用之前，以太坊主網和其他 EVM 鏈之間存在暫時分歧。

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

EIP-3540：EOF - EVM 物件格式 v1：引入程式碼和資料容器，並為以太坊位元組碼添加結構和版本控制。
EIP-3670：EOF - 程式碼驗證：部署時拒絕任何不遵循 EOF 格式的合約。強化程式碼結構，停用無效和未定義的指令。
EIP-663：無限制 SWAP 和 DUP 指令：這解決了 Solidity 中的「堆疊過深」問題，並透過 JUMPDEST 分析，因為即時值可能會產生副作用。EVM langs 非常需要。
EIP-4200：EOF - 靜態相對跳變：更好的靜態分析，沒有不確定的跳轉。相對跳轉更有利於程式碼重複使用。
EIP-4750：EOF - 函數：需要解決可使用動態跳轉但不能使用靜態跳轉的子程式問題。它還允許部分程式碼加載，這與 Verkle 和增加合約大小限制很好地配合。
EIP-5450：EOF - 堆疊驗證：驗證程式碼和堆疊要求。除 CALLF 指令外，刪除所有指令的執行時間堆疊下溢和溢位檢查（EIP-4750）。
EIP-7480：EOF - 資料部分存取指令：允許存取位元組碼的資料部分。
EIP-7069：改造後的 CALL 指令：可移除 CALL 中的 Gas 可觀察性，從而在未來更容易進行 Gas 重新定價。雖然與 EOF 無關，但我們認為這是引入 EOF 的好機會。

我們對 EIP-6206 不太確定： EOF - JUMPF 和非返回函數。雖然它允許對 EOF 函數中的尾部呼叫進行最佳化，但我們仍需要看到語言對其有用性的分析。如果沒有，我們認為可以將其從範圍中刪除，並納入後續的 EOF 更新中。

我們將上述工作預算為 1-2 個月，由 1 位全職人員完成。如果能保持勢頭，我們願意進一步縮減上述範圍。

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

雖然我們可以禁止新的遺留/非 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 Tree

我們認為 Verkle Trees 無法在 2024 年底或 2025 年初部署。我們建議團隊在 2024 年第二季為此分配資源，並承諾在 2025 年第二季至第三季的 Osaka 硬分叉中進行部署。

優勢：

透過更小的儲存證明，使輕量級客戶端更便宜。
透過在程式碼區塊的頭中包含讀取預狀態來實現無狀態執行，這也可能透過靜態狀態存取來提高效能。
透過分塊位元組碼和啟用部分程式碼加載，提高合約大小限制。
由於「恢復」狀態的成本較低，狀態過期變得更容易接受。

劣勢：

變化的影響以及實施和測試的整合工作。
Gas 核算變更： Verkle 嘗試將證人的大小引入 Gas 計算功能。我們擔心尚未對儲存定價的變化進行探討（例如，Verkle 推出後，頂級 Gas 消耗者的成本會是多少）？
應用整合：在疊加過渡運行期間，使用 Merkle Patricia Trie 校驗器的應用程式應該做些什麼？eth_getProof 應該如何運作？

雖然我們理解 Verkle Tries 的好處，但我們認為需要更多考慮第三方工具、合約需要如何調整，以及過渡對 Layer2 等的影響。起初，我們對遷移策略存有疑慮，因為該策略規定，當從先前存在的 MPT 中讀取狀態時，Verkle Trie 應進行更新，但現在似乎不再是這樣了。因此，我們支援將覆蓋樹方法作為一種可行的遷移路徑。

一般來說，Verkle 遷移策略的文檔似乎已經過時，因為大多數資源仍然指出，當從 MPT 中讀取狀態時，Verkle 三元組應該更新，儘管事實並非如此。我們希望看到用最新方法更新關鍵轉換文件，例如這份出色的文件。我們也希望看到關於過渡策略的 EIP 草案。

因此，我們仍然支援在 2025 年推出，但看不到在 Prague 部署的路徑。