Summary of the latest meeting of Ethereum core developers: Pectra upgrade launch, PeerDAS implementation progress discussion

Original title: "Ethereum All Core Developers Consensus Call #138 Writeup"
Author: Christine Kim
Compiled by: Ladyfinger, BlockBeats

Editor’s note:
Ether The All Core Developers Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 138th ACDC conference call. This conference covers the launch of Pectra Devnet 1, changes to the beacon block body and engine API structure, and the inclusion of stable container Ethereum Improvement Proposals (EIPs) into Pectra, namely EIP 7688 and EIP 7495 and PeerDAS updates and other topics. During the meeting, developers reviewed the readiness for Pectra upgrades and discussed some open questions and proposals regarding PeerDAS implementation. In addition, Nimbus developer Etan Kissling also shared the progress of the implementation work of EIP 7688 and EIP 7495, emphasizing the importance of these proposals to upgrade the Ethereum data serialization method. Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail, and BlockBeats compiled the original text as follows:

On July 25, 2024, Ethereum developers held the 138th All-Core Developer Consensus (ACDC) via Zoom )Meeting. The ACDC conference is a biweekly series of meetings where developers discuss and coordinate changes to the Ethereum Consensus Layer (CL), also known as the Beacon Chain. This week’s session was hosted by Ethereum Foundation (EF) researcher Alex Stokes. Developers discussed the following:

·Launch of Pectra Devnet 1

·Changes to the beacon block body and engine API structure

·Incorporation of Stable Container Ethereum Improvement Proposals (EIPs) into Pectra, known as EIP 7688 and EIP 7495

· Updates to PeerDAS and its implementation schedule on mainnet

Pectra Devnet 1 Pectra

Devnet 1 went live on Tuesday, July 23rd. However, the network is not stable. Parithosh Jayanthi, a DevOps engineer at the Ethereum Foundation, said the Erigon client encountered issues shortly after the devnet was launched. Then, an EIP 7702 transaction broadcast on the devnet caused the network to split into three states. Developers are debugging the client and resolving chain split issues.

Introducing ExecutionPayloadEnvelope

Prysm developer Potuz proposed major improvements to the beacon chain block execution load structure, as well as corresponding adjustments to the engine API. This proposal aims to simplify the process of storing and processing state transition data by Consensus Layer (CL) clients. With the implementation of the Pectra upgrade, CL clients need access to specific parts of the execution load to correctly perform state transitions. However, the existing design causes these clients to ignore some non-essential information in the execution load.

Pectra upgrades will require CL clients to either request necessary state transition data from the Execution Layer (EL) or store critical portions of blocks locally. In order to improve the efficiency of the CL client after Pectra's upgrade, Potuz suggested introducing a new structure called "bind_execution_payload_envelope" to centrally store key information required for execution state transitions. Such improvements will significantly increase the speed and efficiency of CL clients in calculating state transitions. He also emphasized that these adjustments will ensure compatibility with future network upgrades such as the Simple Serialization (SSZ) format.

Lighthouse 專案的開發者 Mark Mackey 提出警告，如果不實施這些變更， CL 用戶端在 Pectra 測試網的效能可能會受到影響。 Teku 專案的開發者 Mikhail Kalinin 對此表示謹慎，他質疑是否真有必要透過改變協議來解決 Pectra 中 EIPs 實現的複雜性。 Potuz 則堅持認為，現有的協議設計存在根本性問題，需要修正。他指出：「目前的設計在理念上就存在缺陷，它將對CL 狀態轉換至關重要的數據與完全無關的數據混合在同一級別、同一消息中。因此，我認為當前的設計是錯誤的，我們正在努力糾正這一錯誤。

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 協議存在一定的局限性：「當你需要同步一個長分叉的區塊，而不確定哪個分支是主鏈時，按照當前的協議，你只需提交一個插槽範圍，節點便會返回它認為正確的區塊。情況，但如果未來發生類似事件，這將是一個需要解決的問題。儘管這些改進並非迫在眉睫，Stokes 還是鼓勵與會的開發者仔細審查這項提議，並在GitHub上分享他們的看法和建議。

The above is the detailed content of Summary of the latest meeting of Ethereum core developers: Pectra upgrade launch, PeerDAS implementation progress discussion. For more information, please follow other related articles on the PHP Chinese website!