原文標(biāo)題：《 Ethereum All Core Developers Consensus Call #139 Writeup
作者： Christine Kim
編譯： Ladyfinger ， BlockBeats
編者按：
以太坊所有核心開發(fā)者共識(shí)電話（ ACDC ）是每?jī)芍芘e行一次的系列會(huì)議，專注于討論和協(xié)調(diào)以太坊共識(shí)層（ CL ），也就是信標(biāo)鏈的變更。第 139 次 ACDC 電話會(huì)議由以太坊基金會(huì)（ EF ）研究員 Alex Stokes 主持，會(huì)議內(nèi)容涵蓋了 Pectra Devnet 2 的修復(fù)、 Devnet 3 的準(zhǔn)備、 PeerDAS 實(shí)施進(jìn)展以及以太坊節(jié)點(diǎn)分布的新數(shù)據(jù)。
在會(huì)議期間，開發(fā)者們審議了 Pectra Devnet 2 的穩(wěn)定性和存在的問題，討論了即將到來(lái)的 Devnet 3 的準(zhǔn)備工作，并就 PeerDAS 的實(shí)施進(jìn)展進(jìn)行了深入探討。此外， EIP 7688 的提案也引起了與會(huì)者的廣泛討論，這一提案旨在引入一種向前兼容的數(shù)據(jù)結(jié)構(gòu)，以支持以太坊數(shù)據(jù)序列化方法的潛在變更。 Galaxy Digital 研究副總裁 Christine Kim 對(duì)本次會(huì)議進(jìn)行了詳細(xì)記錄， BlockBeats 將原文編譯如下：
2024 年 8 月 8 日，以太坊開發(fā)者們通過 Zoom 舉行了第 139 次核心開發(fā)者共識(shí)電話會(huì)議（ ACDC ）。 ACDC 電話會(huì)議是每?jī)芍芘e行一次的系列會(huì)議，開發(fā)者們?cè)诖擞懻摬f(xié)調(diào)對(duì)以太坊共識(shí)層（ CL ），也稱為信標(biāo)鏈的變更。本周的電話會(huì)議由以太坊基金會(huì)（ EF ）研究員 Alex Stokes 主持。開發(fā)者們討論了 Pectra Devnet 2 的修復(fù)、 Devnet 3 的準(zhǔn)備、 PeerDAS 實(shí)施進(jìn)展以及以太坊節(jié)點(diǎn)分布的新數(shù)據(jù)。
Pectra 更新
Stokes 宣布， EF 的研究員 Hsiao Wei Wang 即將推出 Pectra 共識(shí)層（ CL ）規(guī)范的官方更新版本 alpha .4，該版本包含了對(duì)前一版的多項(xiàng)改進(jìn)，并計(jì)劃在近期發(fā)布。
關(guān)于 Pectra Devnet 2 的話題， EF 開發(fā)者運(yùn)營(yíng)工程師 Barnabas Busa 表示，網(wǎng)絡(luò)穩(wěn)定，并已達(dá)到 85% 的網(wǎng)絡(luò)參與度。在執(zhí)行層（ EL ）客戶端中還有一些需要解決的小問題，主要是 EthereumJS 和 Erigon 。大多數(shù) CL 客戶端在 Devnet 2 上是穩(wěn)定的。然而， Busa 提到了 Prysm 客戶端需要進(jìn)一步調(diào)查的小問題。 EF DevOps 工程師 Parithosh Jayanthi 補(bǔ)充說，還需要客戶端團(tuán)隊(duì)調(diào)查 Lighthouse 、 Teku 和 Besu 節(jié)點(diǎn)之間的問題。
隨后，開發(fā)者們討論了如何改善 devnet 啟動(dòng)的通訊流程。 Prysm 的開發(fā)者 Kasey Kirkham 在 Zoom 聊天中指出了自己對(duì) Devnet 2 啟動(dòng)時(shí)間的不知曉。為確保 Devnet 3 的啟動(dòng)信息能準(zhǔn)確傳達(dá)給所有客戶端團(tuán)隊(duì)，開發(fā)者們決定設(shè)立一個(gè)定期的周會(huì)議，用于更新 Pectra 的測(cè)試進(jìn)展。盡管具體時(shí)間尚未確定，但這些會(huì)議預(yù)計(jì)將在每周一舉行，類似于 Dencun 升級(jí)前的測(cè)試電話會(huì)議。 Jayanthi 提出，這些會(huì)議將簡(jiǎn)短高效，時(shí)長(zhǎng)控制在 15 至 30 分鐘之間，專注于討論 Pectra 相關(guān)的 devnet 測(cè)試更新，涵蓋 PeerDAS 和 EOF devnet s 等議題。
在討論 Pectra Devnet 3 的議題時(shí)，開發(fā)者們重申了它將沿用與 Devnet 2 一致的 EIP 配置。此外， Devnet 3 將首次集成最新設(shè)計(jì)的 EIP 7702，團(tuán)隊(duì)將對(duì)其進(jìn)行細(xì)致的測(cè)試，以確保其與 Pectra 核心 EIP s 的兼容性。 Lodestar 團(tuán)隊(duì)的 Gajinder Singh 提到，在 Devnet 2 中發(fā)現(xiàn)的 EIP 7251，即 MaxEB 提案中的問題，盡管已經(jīng)進(jìn)行了調(diào)試，但仍需在接下來(lái)的 Pectra devnet 上進(jìn)行更深入的測(cè)試以驗(yàn)證解決方案。
正如在 ACDE #193 上討論的，有一個(gè)新的 Engine API 規(guī)范，它允許 CL 客戶端從 EL blob 交易內(nèi)存池中獲取 blob s。該方法稱為「 getBlobsV1 」。為了避免濫用， Teku 開發(fā)者 Enrico del Fante 提出了一些對(duì) CL 規(guī)范的澄清。 Stokes 建議開發(fā)者們審查這些澄清，并計(jì)劃在 Pectra Devnet 3 上測(cè)試這種方法的使用。
開發(fā)者們就 mplex 協(xié)議的棄用進(jìn)行了討論。 Mplex 曾是 CL 客戶端用于單一通信鏈接多數(shù)據(jù)流傳輸?shù)膮f(xié)議，但目前已遭其維護(hù)者廢棄。客戶端團(tuán)隊(duì)正計(jì)劃轉(zhuǎn)向如 yamux 這樣的新型數(shù)據(jù)流復(fù)用技術(shù)。 Lodestar 的 Phil Ngo 宣布，他們已完成 yamux 的集成和測(cè)試工作，并傾向于直接過渡到新協(xié)議，而非長(zhǎng)期維護(hù)兩個(gè)協(xié)議，因?yàn)檫@將增加客戶端的運(yùn)營(yíng)成本。 Nimbus 的 Etan Kissling 也透露，他們團(tuán)隊(duì)正在對(duì) yamux 進(jìn)行測(cè)試。開發(fā)者們達(dá)成共識(shí)，將繼續(xù)關(guān)注其他 CL 客戶端團(tuán)隊(duì)在協(xié)議過渡方面的進(jìn)展，并計(jì)劃在未來(lái)幾個(gè)月內(nèi)再次評(píng)估從 mplex 到新復(fù)用器的遷移策略。
Etan Kissling 在 Pectra 議題上提出了關(guān)于 EIP 7688 的討論，該提案旨在引入一種向前兼容的數(shù)據(jù)結(jié)構(gòu)，以便智能合約開發(fā)者能夠在以太坊執(zhí)行層（ EL ）的數(shù)據(jù)序列化方法從 RLP 過渡到 SSZ 時(shí)繼續(xù)使用。盡管 Pectra 升級(jí)本身不會(huì)完全實(shí)現(xiàn) SSZ ，但 EIP 7688 的提出是為了確保 Pectra EIP s 在數(shù)據(jù)變更方面的前向兼容性。
Alex Stokes 對(duì)于在 Pectra 升級(jí)中加入 EIP 7688 持謹(jǐn)慎態(tài)度，認(rèn)為升級(jí)規(guī)模已經(jīng)相當(dāng)龐大。 Parithosh Jayanthi 在會(huì)議中提到， EIP 7688 最早可能在 Devnet 5 中進(jìn)行測(cè)試。 Lodestar 、 Prysm 、 Teku 和 Lighthouse 等團(tuán)隊(duì)的代表對(duì)此提案表示支持。 Stokes 和 Beiko 建議，在所有現(xiàn)有 Pectra EIP s 達(dá)到穩(wěn)定狀態(tài)之前，應(yīng)避免向 Pectra 添加新的 EIP s。 Kissling 接受了這一建議，并詢問了何時(shí)重新討論此議題的最佳時(shí)機(jī)。盡管沒有得到具體答復(fù)，但團(tuán)隊(duì)普遍認(rèn)為應(yīng)在 Pectra Devnet 5 啟動(dòng)前對(duì) EIP 7688 進(jìn)行再次評(píng)估。
PeerDAS 更新
Prysm 客戶端團(tuán)隊(duì)的代表在會(huì)議上匯報(bào)了他們關(guān)于 PeerDAS 實(shí)施的最新進(jìn)展，并引發(fā)了對(duì)「 blob sidecar 」 Engine API 請(qǐng)求必要性的討論。 Alex Stokes 建議在下一次 PeerDAS 小組會(huì)議中深入討論 PeerDAS 對(duì) Engine API 所需進(jìn)行的調(diào)整。他同時(shí)指出，一位 EF 研究員已經(jīng)草擬了正式規(guī)范，提議從 PeerDAS 中移除抽樣機(jī)制，目的是降低升級(jí)過程的復(fù)雜度。然而，在最近一次的 PeerDAS 小組會(huì)議上，與會(huì)者擔(dān)心此舉可能會(huì)增加未來(lái)通過硬分叉重新引入抽樣的難度。此外，抽樣機(jī)制的移除對(duì) Pectra 中 blob gas limit 安全增加的影響尚不明確。一項(xiàng)提議將執(zhí)行層（ EL ）和共識(shí)層（ CL ）中的 blob gas limit 解耦的提案， EIP 7742，在本周的電話會(huì)議上再次被提出。 Stokes 表示他將更新該 EIP ，并計(jì)劃在下一次的 CL 電話會(huì)議上討論其納入的可能性，以及與 Pectra 中 blob gas limit 調(diào)整相關(guān)的議題。
研究更新
在本周的電話會(huì)議中，開發(fā)者們集中討論了三項(xiàng)研究議題。首先，他們探討了 EIP 7251 下，驗(yàn)證者在合并質(zhì)押 ETH 余額時(shí)可能遇到的邊緣情況。 Etan Kissling 提出，驗(yàn)證者余額在合并期間可能長(zhǎng)時(shí)間未更新，這可能導(dǎo)致協(xié)議錯(cuò)誤地分配同步委員會(huì)職責(zé)。對(duì)此， Alex Stokes 回應(yīng)稱，這一問題與協(xié)議處理驗(yàn)證者退出的情況相似，并建議在共識(shí)層（ CL ）規(guī)范中記錄這一邊緣情況，而不改變現(xiàn)有合并設(shè)計(jì)。
然后，開發(fā)者們討論了以太坊網(wǎng)絡(luò)層的變更，特別是引入了「 quic ENR entry 」。 Quic 代表快速 UDP 互聯(lián)網(wǎng)連接，它幫助節(jié)點(diǎn)發(fā)送和接收數(shù)據(jù)。 Stokes 建議在 GitHub 上創(chuàng)建一個(gè)拉取請(qǐng)求（ PR ），以進(jìn)一步詳細(xì)說明 quic ENR entry 的具體變更。
最后， ProbeLab 分享了他們對(duì)以太坊網(wǎng)絡(luò)的節(jié)點(diǎn)運(yùn)行情況的持續(xù)分析。報(bào)告顯示，目前有 8335 個(gè)節(jié)點(diǎn)在以太坊網(wǎng)絡(luò)上運(yùn)行，其中 42% 使用的是 Lighthouse 客戶端。在美國(guó)運(yùn)營(yíng)的節(jié)點(diǎn)占總數(shù)的 36%，且約一半的節(jié)點(diǎn)部署在數(shù)據(jù)中心。 Prysm 的開發(fā)者「 Potuz 」對(duì)于數(shù)據(jù)中心托管的 Lighthouse 節(jié)點(diǎn)數(shù)量超過自托管節(jié)點(diǎn)的現(xiàn)象表示好奇。 Stokes 推測(cè)，這可能是因?yàn)?Lighthouse 客戶端的主要用戶群體包括機(jī)構(gòu)和專業(yè)的節(jié)點(diǎn)運(yùn)營(yíng)商。
在會(huì)議的尾聲， Potuz 敦促團(tuán)隊(duì)審查他所提交的關(guān)于調(diào)整執(zhí)行有效載荷結(jié)構(gòu)的 PR 。該提案在上一屆 ACDC 電話會(huì)議中首次被提出。 Potuz 強(qiáng)調(diào)了迅速?zèng)Q策的重要性，指出盡管這些變更在概念上簡(jiǎn)單易懂，但要將它們整合進(jìn)共識(shí)層（ Consensus Layer , CL ）規(guī)范卻頗具挑戰(zhàn)。他建議開發(fā)者們盡早著手這一工作。
以上就是以太坊核心開發(fā)者最新會(huì)議摘要：Pectra 修復(fù)與籌備、PeerDAS 進(jìn)展的詳細(xì)內(nèi)容，更多請(qǐng)關(guān)注本站其它相關(guān)文章！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
