以太坊核心開發者最新會議摘要:Pectra 升級啟動、PeerDAS 實現進展探討
原文標題:《Ethereum All Core Developers Consensus Call #138 Writeup》
作者:Christine Kim
編譯:Ladyfinger,BlockBeats
編者按:
以太坊所有核心開發者共識電話(ACDC)每兩週舉行一次,主要討論和協調對以太坊共識層(CL)的更改。本次為 ACDC 第 138 次電話會議,本次會議涵蓋了 Pectra Devnet 1 的啟動、信標區塊體和引擎 API 結構的變更、將穩定容器以太坊改進提案(EIPs)納入 Pectra,即 EIP 7688 和 EIP 7495 以及 PeerDAS 的更新等多個議題。會議期間,開發者們審議了 Pectra 升級的準備情況,並探討了關於 PeerDAS 實現的一些未解問題和提案。此外,Nimbus 開發者 Etan Kissling 還分享了 EIP 7688 和 EIP 7495 的實施工作進展,強調了這些提案對以太坊數據序列化方法升級的重要性。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄,BlockBeats 將原文編譯如下:
2024 年 7 月 25 日,以太坊開發者通過 Zoom 舉行了第 138 次全核心開發者共識( ACDC )會議。 ACDC 會議是每兩週舉行一次的會議系列,開發者們在這些會議上討論並協調對以太坊共識層( CL ),也稱為信標鏈的變更。本週的會議由以太坊基金會( EF )研究員 Alex Stokes 主持。開發者們討論了以下內容:
· Pectra Devnet 1 的啟動
· 信標區塊體和引擎 API 結構的變更
· 將穩定容器以太坊改進提案( EIP s )納入 Pectra ,即 EIP 7688 和 EIP 7495
· PeerDAS 的更新及其在主網上的實施時間表
Pectra Devnet 1 Pectra
Devnet 1 於 7 月 23 日星期二上線。然而,網絡並不穩定。以太坊基金會開發運維工程師 Parithosh Jayanthi 表示, Erigon 客戶端在 devnet 啟動後不久遇到了問題。接著,一個在 devnet 上廣播的 EIP 7702 交易導致網絡分裂成三個狀態。開發者們正在調試客戶端並解決鏈分裂問題。
引入 ExecutionPayloadEnvelope
Prysm 開發者 Potuz 提出了對信標鏈區塊執行負載結構的重大改進,以及對引擎 API 的相應調整。這一提議旨在簡化共識層( CL )客戶端存儲和處理狀態轉換數據的過程。隨著 Pectra 升級的實施, CL 客戶端需要訪問執行負載的特定部分來正確執行狀態轉換。然而,現有設計導致這些客戶端忽略了執行負載中的一些非必要信息。
Pectra 升級將要求 CL 客戶端要麼從執行層( EL )請求必要的狀態轉換數據,要麼在本地存儲區塊的關鍵部分。為了提高 Pectra 升級後 CL 客戶端的效率, Potuz 建議引入名為「 binded _ execution _ payload _ envelope 」的新結構,集中存儲執行狀態轉換所需的關鍵信息。這樣的改進將顯著提升 CL 客戶端在計算狀態轉換時的速度和效率。他還強調,這些調整將確保與未來的網絡升級,如簡單序列化( SSZ )格式的兼容性。
Lighthouse 項目的開發者 Mark Mackey 提出警告,如果不實施這些變更, CL 客戶端在 Pectra 測試網的性能可能會受到影響。 Teku 項目的開發者 Mikhail Kalinin 對此表示謹慎,他質疑是否真有必要通過改變協議來解決 Pectra 中 EIPs 實現的複雜性。 Potuz 則堅持認為,現有的協議設計存在根本性問題,需要修正。他指出:「目前的設計在理念上就存在缺陷,它將對 CL 狀態轉換至關重要的數據與完全無關的數據混合在同一級別、同一消息中。因此,我認為當前的設計是錯誤的,我們正在努力糾正這一錯誤。」
Stokes 鼓勵開發者在GitHub上繼續討論這個提議。
Devnet 2 的引擎 API 更新
與上述討論相關, Geth 開發者「 Lightclient 」提出了對引擎 API 的另一個變更。這個變更旨在使 EL 客戶端更容易進行區塊轉換。 EL 客戶端通過解釋區塊中的空字段和空字段來確定區塊版本。然而,由於 Prague 的 EIP 7685,如果沒有分叉時間表, EL 客戶端將無法根據這些字段區分區塊版本。為了避免引用過去升級的時間表的開銷, Lightclient 提議將所有請求統一為引擎 API 中的單一類型, EL 可以將其傳遞給 CL 進行解釋。
Lightclient 指出,區塊的解釋在 EL 和 CL 之間有所不同,而在這種情況下, CL 更適合表示請求數據。「當我們處理區塊本身時,區塊沒有概念,『這是 Bellatrix 區塊。』,就像在 CL 上一樣。我認為你們在區分不同類型的分叉區塊方面做得很好。但在 EL 上,我認為這就是幾乎所有客戶端實現的方式,我們有一個區塊代表所有區塊類型,我們使用存在的,比如一個值的空值,來確定那個 [分叉] 是否活躍。」
Nimbus 開發者「 Dustin 」反對這個提議,說 Lightclient 的提議並沒有充分解決 EL 和 CL 上區塊解釋的複雜性。「這只是將複雜性和混亂從 EL 轉移到 CL ,而且兩個地方都是可行的。將其移到 CL 並沒有解決問題。……它只是移動了問題,」 Dustin 說。
Stokes 斷言,CL 更適合處理請求的解釋,並建議開發者更仔細地查看 Potuz 和 Lightclient 在GitHub上提出的引擎 API 變更。
Pectra 中的 EIP 7688 和 7495
Nimbus 開發者 Etan Kissling 一直在推動以太坊序列化方法更新為 SSZ 。為了 Pectra 的目的,他確定了兩個中間 EIPs ,7688 和 7495,以引入智能合約開發者可以依賴的數據結構,以與未來的 SSZ 相關變更兼容。 Kissling 指出,他已經得到了像 Rocketpool 這樣的流動質押池的支持,以及 Teku 和 Lodestar 等其他客戶端團隊的支持。
Stokes 警告 CL 客戶端團隊不要在 Pectra 中添加新的 EIPs 。「 Pectra 已經非常大了,特別是如果我們最終在分叉中有了 PeerDAS 。在某個時候,我們需要非常現實地看待分叉的大小以及它所帶來的風險。再說一次,我同意 Etan 給出的這個功能在真空中是有價值的理由,但我認為這是我們做過的最大的硬分叉之一,或者就是最大的,這不應該被輕視,」他說。
開發者們對這些 EIP 何時可以實際添加到 Pectra devnet 提出了一些擔憂,因為 Pectra devnet s 尚未納入許多 EIP ,如 PeerDAS 和 EOF 。對此, Jayanthi 建議首先明確決定開發者是否應該在升級中包括這些 EIP 。 Jayanthi 還警告說,在測試 CL 和 EL EIP 一起在一個 devnet 上時存在瓶頸。他在 Zoom 聊天中寫道:「10 個直接的 EIP 一起發貨,會使得分叉在組合中測試變得非常複雜。而我們不僅有直接的 EIP 。」
Mackey 分享說,像 EigenLayer 團隊這樣的應用開發者正在試圖弄清楚 Pectra 中計劃激活的內容,以及這些兩個 EIP 的持續缺乏清晰度是他們工作的障礙。 Lighthouse 開發者 Sean Anderson 建議從以太坊上的應用開發者那裡獲取更多關於這些 EIP 的意見,以確定它們對應用程序有多關鍵。
Stokes 建議稍後再重訪這個討論,以便開發者集中精力解決 Pectra Devnet 1 的問題。
PeerDAS 更新
開發者們就 PeerDAS 的最新進展進行了深入討論。 Anderson 報告稱,共識層( CL )客戶端團隊正在積極修復在上一輪 PeerDAS 的 devne 中發現的問題,並在啟動新的 devne t 之前確保實現的穩定性。 Lodestar 和 EthereumJS 的開發者 Gajinder Singh 表示,根據最近一次 PeerDAS 實現者會議的反饋,社區有意向在下個 Pectra devne t 中集成 PeerDAS 。
Stokes 提出,根據與以太坊基金會( EF )研究團隊及其他開發者的討論,初步在主網上激活 PeerDAS 時可能需要省略抽樣功能,以降低實現的複雜性。他闡釋說, PeerDAS 的完整實現涉及分發、抽樣和重建三個關鍵功能。「目前, PeerDAS 在 Pectra 中的規範涵蓋了這三個任務。我的直覺告訴我,抽樣功能可能是實現過程中最大的複雜點。如果抽樣確實帶來了難以克服的挑戰,我們可以考慮在 Pectra 中增加 blob 的數量,同時減少或調整 PeerDAS 的範圍,」 Stokes 解釋道。
Stokes 承諾,他將就此想法制定一個正式的提議,並與開發者社區進一步探討。 Singh 對此表示支持。 Stokes 還建議在 Pectra 升級中正式納入 PeerDAS 。對此, Jayanthi 詢問這是否意味著要在 Pectra 規範的基礎上重新定義 PeerDAS 規範,並指出合併 PeerDAS 和 Pectra devnets 可能會因兩者都不穩定而使調試工作複雜化。他建議在規範穩定之前,應保持兩個工作流程的獨立性。 Teku 的開發者 Enrico Del Fante 也贊同 Jayanthi 的看法。
Stokes 注意到,許多專注於 PeerDAS 實現的開發者未能參加此次會議。他提議在下一次 PeerDAS 實現者會議上繼續探討 PeerDAS 的未來步驟。
添加 BeaconBlocksByRange V3
Lighthouse 項目的開發者「 Dapplion 」提出了一項改進方案,旨在幫助客戶端在發生長時間鏈分裂的情況下,能夠更有效地同步至主鏈。他指出,現有的 [ BeaconBlocksByRange V2 ] RPC 協議存在一定的局限性:「當你需要同步一個長分叉的區塊,而不確定哪個分支是主鏈時,按照當前的協議,你只需提交一個插槽範圍,節點便會返回它認為正確的區塊。儘管你可以通過狀態消息查詢這些信息,但這一過程存在異步性,可能會引發一些問題。雖然目前主網上尚未出現嚴重的分叉情況,但如果未來發生類似事件,這將是一個需要解決的問題。」
Dapplion 進一步說明,他提出的解決方案相對簡單,甚至有可能被納入即將到來的 Pectra 升級中。儘管這些改進並非迫在眉睫,Stokes 還是鼓勵與會的開發者們仔細審查這一提議,並在GitHub上分享他們的看法和建議。