原文標題：《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 結構的變更

· 將穩定容器以太坊改進提案（EIPs）納入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 狀態轉換至關重要的數據與完全無關的數據混合在同一級別、同一消息中。因此，我認為當前的設計是錯誤的，我們正在努力糾正這一錯誤。 issues/3856" target="">GitHub上繼續討論這個提議。

Devnet 2 的引擎API 更新

與上述討論相關，Geth 開發者「Lightclient 」提出了對引擎API 的另一個變更。這個變更旨在使 EL 客戶端更容易進行區塊轉換。 EL 客戶端透過解釋區塊中的空白字段和空白字段來確定區塊版本。然而，由於 Prague 的 EIP 7685，如果沒有分叉時間表，EL 客戶端將無法根據這些欄位區分區塊版本。為了避免引用過去升級的時間表的開銷，Lightclient 提議將所有請求統一為引擎 API 中的單一類型，EL 可以將其傳遞給 CL 進行解釋。

Lightclient 指出，區塊的解釋在 EL 和 CL 之間有所不同，而在這種情況下，CL 更適合表示請求資料。 「當我們處理區塊本身時，區塊沒有概念，『這是Bellatrix 區塊。』，就像在CL 上一樣。我認為你們在區分不同類型的分叉區塊方面做得很好。但在EL 上，我認為這就是幾乎所有客戶端實現的方式，我們有一個區塊代表所有區塊類型，我們使用存在的，例如一個值的空值，來確定那個[分叉] 是否活躍。 /p>

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 devnets 尚未納入許多 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 中發現的問題，並在啟動新的 devnet 之前確保實現的穩定性。 Lodestar 和 EthereumJS 的開發者 Gajinder Singh 表示，根據最近一次 PeerDAS 實現者會議的回饋，社群有意向在下一個 Pectra devnet 中整合 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 協議存在一定的局限性：「當你需要同步一個長分叉的區塊，而不確定哪個分支是主鏈時，按照當前的協議，你只需提交一個插槽範圍，節點便會返回它認為正確的區塊。情況，但如果未來發生類似事件，這將是一個需要解決的問題。可能被納入即將到來的Pectra 升級。儘管這些改進並非迫在眉睫，Stokes 還是鼓勵與會的開發者們仔細審查這一提議，並在 GitHub上分享他們的看法和建議。

「原文連結」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia