2023 年首次以太坊核心開發者會議：延後 EOF，暫定於 3 月份進行上海升級

撰文：Christine Kim （galaxy）

編譯：DeFi 之道

圖片來源：由 Maze AI 生成

1 月 5 日，以太坊開發者們在休息兩周后召開了 2023 年首次全核心開發者 (ACD) 電話會議。從 2023 年開始，ACD 電話會議將更名為 ACD 執行 (ACDE) 電話會議，以反映開發者們對以太坊執行層變化的關注。 他們還將在@EthereumProtocol YouTube 頻道進行直播，而不是在@EthereumFoundation YouTube頻道。 ACDE 電話會議由以太坊基金會的 Tim Beiko 主持，它是以太坊開發者討論和協調以太坊協議變更的兩個會議系列之一， 而另一個系列會議，開發人員已將其重命名為 ACD 共識(ACDC)電話會議，重點討論與以太坊共識層開發相關的主題。

在第 152 次全核心開發者執行 (ACDE) 電話會議上，開發人員同意從上海升級中刪除與 EOF 實施相關的代碼更改。 有關 EOF 的更多信息，請在此處閱讀之前的電話會議記錄。 他們還同意拒絕將新 EIP 添加到上海升級，這主要是為了確保質押 ETH 提款的時間表不會延遲。 作為上海升級唯一的主要代碼更改，質押 ETH 提款功能目前正在一個開發者測試網絡上進行測試。據悉，開發者們的目標是在下個月推出上海/Capella 升級的公共測試網，並暫定於 2023 年 3 月的某個時間啟動主網升級。隨後，開發者們簡要討論了以太坊執行層和共識層之間不同序列化方法的問題，以及引入 Poseidon 哈希函數作為 EVM 的預編譯的新 EIP 。

上海升級計劃

以太坊基金會的 DevOps 工程師 Barnabus Busa 更新了質押 ETH 提款測試的狀態。 他表示，在聖誕節前推出的上海開發者測試網絡，當前已進展到 4,000 個區塊。 目前，所有 EL 和 CL 客戶端組合都在該測試網上運行，其中 Teku-Erigon 和 Lighthouse-Erigon 等一些客戶端組合遇到了問題。 Busa 提到，開發者們正努力在客戶端團隊的幫助下儘快啟動一個新的開發者測試網。

然後，以太坊基金會 Geth (EL) 客戶端的軟件開發者 Marius van der Wijden 向上海升級較小的 EIP之一（ EIP 3860 ‌）提交了一個小的設計更改。提議的更改糾正了該 EIP 中令人困惑的失敗模式，其中違反 initcode 限制導致零地址錯誤而不是 OOG 錯誤。根據以太坊基金會 Ipsilon 團隊開發者Pawel Bylica 的說法，這樣做的最初動機是為了促進用戶友好性。然而，開發者們一致認為，將失敗模式更改為 OOG 錯誤，會減少客戶端實現中的混亂與漏洞。

延後 EOF，將其排除在上海升級之外

接下來，一名以太坊基金會 Geth (EL)客戶端軟件開發者(化名為“lightclient”)介紹了 EOF 實現的最新進展。

作為背景，EOF 代表 EVM 對象格式，其對以太坊的代碼執行環境進行了一些更改。在其他變化中，與 EOF 實現相關的 EIP 將改進以太坊的交易格式，以更明確地區分智能合約代碼和數據，並幫助 EVM 在未來更容易升級。lightclient 表示，在假期期間，致力於 EOF 實現的開發者們舉行了兩次會議，並討論了相關 EIP 規範。在這些會議期間，開發者們同意刪除其中一個 EIP（EIP 6206‌，因為它的複雜性），並使這些 EIP 中的數據部分成為強制性的，而不是可選的，以略微提高數據解析的簡單性。據 lightclient 表示，EOF EIP 的測試也在取得進展。EOF EIP 的參考測試尚未正式發布，但以太坊基金會的安全負責人 Martin Holst Swende 已經開始對 EOF 的不同客戶端實現進行差異測試（也稱為差分模糊測試）。

“為 EOF 創建一個效果最好的 [測試] 案例並不容易，問題是有很多陷阱。 例如，如果你希望某些東西以某種方式失敗，在 EOF 中，你必須非常具體，並且必須確保在達到你真正想要測試的內容之前，測試不會在其他地方失敗。 所以，我認為如果我們以某種方式集中錯誤，這將是非常有價值的，”以太坊基金會測試團隊的 Mario Vega 表示。

基於 EOF 實現以及測試的現狀，Tim Beiko 提出了一個問題，即開發者們在下一次（上海）以太坊升級中包含這些 EIP 是否仍然可行的問題。在這個話題上，以太坊聯合創始人 Vitalik Buterin 表達了他對倉促實施 EOF 的擔憂，因為目前沒有明確的路線圖來確保未來對 EVM 的升級不會更加繁瑣，也不會增加以太坊的技術債。Vitalik 表示：

“在 EVM 中，刪除一些東西比刪除其他功能要困難得多，你有用 EVM 代碼編寫的應用程序，如果 EVM 發生了變化，那麼這些應用就無法更改 …我最大的擔憂之一是對 EVM 的改進，特別是因為它很難棄用和實際刪除一些東西，EVM 開發的哲學允許基本上大量的持續改進，而不是很快地致力於真正接近於不會更改的東西，這會讓我們冒着創建一個 [EVM] V2，然後創建一個 V3，然後創建一個 V4 的風險，但仍然需要 V1、V2 和 V3 作為共識代碼的一部分，因為我們沒有移除它們的好方法。”

對此，來自 Erigon (EL) 客戶端團隊的 Andrew Ashikhmin 表示，他擔心如果開發人員將 EOF 實施推遲到“完美”時，他們也會失去測試實現的動力和機會，從而無法獲得關於提議的代碼更改的真實反饋。Ashikhmin 在電話會議上表示 :

“如果我們試圖讓它變得完美，那麼它就像一個永不結束的超級項目。”

為了應對圍繞 EOF 實施的持續不確定性，以太坊基金會的研究員 Ansgar Dietrichs 提議開發者們將相關 EIP 從上海升級中撤出，並致力於在接下來的幾周內積極解決實施方面的這些問題以及 EVM 升級的前進道路。Van der Wijden 表示，從他的觀點來看，在本周的電話會議上試圖決定 EOF 的實施似乎有些倉促，他說：“我覺得現在要對 EOF 做出決定有點壓力，我不認為這是好事。” 對此，lightclient承認，基於假期期間 EOF 測試的進展，將其納入上海升級，將會推遲整個升級大約一個月的時間。lightclient 在電話會議上提到說:“如果我們試圖在 2 月初進行主網測試網升級，我認為到那時我們無法準備好。”

在開發者們同意將 EOF 實施排除在上海升級之外后，Beiko 提議再等兩周，然後再決定是否應將 EOF 包括在上海之後的 Cancun 升級中。 在之前的電話會議中，開發們同意將 Cancun 升級集中在 EIP 4844‌（proto-danksharding）之上， 而從 Beiko 的角度來看，如果 EOF 再次被拒絕，那麼過早地在 Cancun 包含 EOF 可能會導致混亂。 而 Lightclient 反對這一想法，並爭辯說，如果開發者們不承諾在像 Cancun 這樣的升級中實施 EOF，那麼它將推遲實施工作，並進一步削弱 EOF 的發展勢頭。 Beiko 回應說，在兩周后的下一次 ACDE 電話會議上會重新討論何時包含 EOF 實施的問題，這應該不會對 EOF 的發展勢頭產生重大影響。有關不同核心開發人員關於 EOF 實施以及 EVM 升級的前進道路的建議的更多詳細信息，請參見此處‌和此處‌。

隨着 EOF 被排除在上海升級，Marius van der Wijden 暫時提議將 EIP 1153‌ 納入到上海升級中，而幾位參加電話會議的開發者則強烈反對在上海升級中添加新的 EIP，以降低延遲質押 ETH 提款的風險。隨後，開發者們重申了他們的承諾，即嘗試以 2 月初為目標啟動上海公共測試網。

RLP 還是 SSZ ？

開發者們還討論了 Ethereum Nimbus (CL) 客戶端團隊開發者 Etan Kissling 的提議。Kissling 在之前的 ACDC 電話會議上分享了這個提案，總結如下：簡而言之，在 EL 區塊頭和 CL 執行負載頭之間有兩個使用不同序列化格式編碼的字段。由於這兩個字段的編碼方式不同，因此會為構建錢包和以太坊輕客戶端帶來額外的開銷和複雜性。Kissling 提出的解決方案之一，是向 EL 添加一種在 CL 中使用的新序列化格式（稱為 SSZ）。或者，CL 客戶端可以合併一些方法，以支持 EL 中稱為RLP 的代碼。然而，這並不理想，因為 SSZ 格式是編碼結構化數據的更現代和更新的序列化格式。在任何一種情況下，所涉及的編碼數據字段都與質押 ETH 提款相關，因此，EL 或 CL 端為確保數據格式一致性而進行的任何更改，都需要以太坊客戶團隊進行額外的工作。Andrew Ashikhmin 強調，圍繞這個問題做出的決定是“緊急的”，因為它關係到了上海升級。

為了讓客戶端團隊有更多的時間來考慮 Kissling 提出的解決方案之間的權衡，Beiko 建議開發人員在下周的 ACDC 電話會議上重新討論這一話題，並在 1 月 19 日的下一次 ACDE 電話會議上決定該怎麼做。下周四 （1月12日）ACDC 電話會議的議程可在這裡‌找到。

EIP 5843 和 EIP 5988

最後，開發者們簡要討論了兩個新的 EIP。 EIP 5843‌ 向以太坊虛擬機 (EVM) 引入了高效的模塊化加法、減法和乘法，它是由以太坊基金會軟件開發者 Jared Wasinger 提出的 EIP。然而，Jared 並沒有出席本周的電話會議，這就是為什麼開發者們同意在未來某個日期重新討論該 EIP 的原因。

隨後，StarkWare 的探索主管 Abdelhmaid Bakhta 介紹了 EIP 5988‌，它為以太坊引入了一種新的預編譯，提高了在網絡上運行零知識證明的效率。 “基本上，每次我們想要證明像 Merkle 證明這樣的存儲證明時，在以太坊上都非常昂貴，因為我們沒有任何 ZK 友好的哈希函數，”Bakhta 解釋道。 關於這個 EIP，以太坊基金會研究員 Dankrad Feist 表示，在他看來，將任何類型的算術哈希函數納入協議還為時過早，因為它們當前還處於早期測試性質，並且它們可能會對以太坊的安全性產生未知的影響。