原文標(biāo)題：Ethereum All Core Developers Consensus Call #138 Writeup作者：Christine Kim編譯：Ladyfinger，BlockBeats編者按：以太坊所有核心開(kāi)發(fā)者共識(shí)電話（ACDC）每?jī)芍芘e行一次，主要討論和協(xié)調(diào)對(duì)以太坊共識(shí)層（CL）的更改。本次為 ACDC 第 138 次電話會(huì)議，本次會(huì)議涵蓋了 Pectra Devnet 1 的啟動(dòng)、信標(biāo)區(qū)塊體和引擎 API 結(jié)構(gòu)的變更、將穩(wěn)定容器以太坊改進(jìn)提案（EIPs）納入 Pectra，即 EIP 7688 和 EIP 7495 以及 PeerDAS 的更新等多個(gè)議題。會(huì)議期間，開(kāi)發(fā)者們審議了 Pectra 升級(jí)的準(zhǔn)備情況，并探討了關(guān)于 PeerDAS 實(shí)現(xiàn)的一些未解問(wèn)題和提案。此外，Nimbus 開(kāi)發(fā)者 Etan Kissling 還分享了 EIP 7688 和 EIP 7495 的實(shí)施工作進(jìn)展，強(qiáng)調(diào)了這些提案對(duì)以太坊數(shù)據(jù)序列化方法升級(jí)的重要性。Galaxy Digital 研究副總裁 Christine Kim 對(duì)本次會(huì)議要點(diǎn)做了詳細(xì)記錄，BlockBeats 將原文編譯如下：

2024 年 7 月 25 日，以太坊開(kāi)發(fā)者通過(guò) Zoom 舉行了第 138 次全核心開(kāi)發(fā)者共識(shí)（ ACDC ）會(huì)議。 ACDC 會(huì)議是每?jī)芍芘e行一次的會(huì)議系列，開(kāi)發(fā)者們?cè)谶@些會(huì)議上討論并協(xié)調(diào)對(duì)以太坊共識(shí)層（ CL ），也稱(chēng)為信標(biāo)鏈的變更。本周的會(huì)議由以太坊基金會(huì)（ EF ）研究員 Alex Stokes 主持。開(kāi)發(fā)者們討論了以下內(nèi)容：

· Pectra Devnet 1 的啟動(dòng)

· 信標(biāo)區(qū)塊體和引擎 API 結(jié)構(gòu)的變更

· 將穩(wěn)定容器以太坊改進(jìn)提案（ EIP s ）納入 Pectra ，即 EIP 7688 和 EIP 7495

· PeerDAS 的更新及其在主網(wǎng)上的實(shí)施時(shí)間表

Pectra Devnet 1 Pectra

Devnet 1 于 7 月 23 日星期二上線。然而，網(wǎng)絡(luò)并不穩(wěn)定。以太坊基金會(huì)開(kāi)發(fā)運(yùn)維工程師 Parithosh Jayanthi 表示， Erigon 客戶端在 devnet 啟動(dòng)后不久遇到了問(wèn)題。接著，一個(gè)在 devnet 上廣播的 EIP 7702 交易導(dǎo)致網(wǎng)絡(luò)分裂成三個(gè)狀態(tài)。開(kāi)發(fā)者們正在調(diào)試客戶端并解決鏈分裂問(wèn)題。

引入 ExecutionPayloadEnvelope

Prysm 開(kāi)發(fā)者 Potuz 提出了對(duì)信標(biāo)鏈區(qū)塊執(zhí)行負(fù)載結(jié)構(gòu)的重大改進(jìn)，以及對(duì)引擎 API 的相應(yīng)調(diào)整。這一提議旨在簡(jiǎn)化共識(shí)層（ CL ）客戶端存儲(chǔ)和處理狀態(tài)轉(zhuǎn)換數(shù)據(jù)的過(guò)程。隨著 Pectra 升級(jí)的實(shí)施， CL 客戶端需要訪問(wèn)執(zhí)行負(fù)載的特定部分來(lái)正確執(zhí)行狀態(tài)轉(zhuǎn)換。然而，現(xiàn)有設(shè)計(jì)導(dǎo)致這些客戶端忽略了執(zhí)行負(fù)載中的一些非必要信息。

Pectra 升級(jí)將要求 CL 客戶端要么從執(zhí)行層（ EL ）請(qǐng)求必要的狀態(tài)轉(zhuǎn)換數(shù)據(jù)，要么在本地存儲(chǔ)區(qū)塊的關(guān)鍵部分。為了提高 Pectra 升級(jí)后 CL 客戶端的效率， Potuz 建議引入名為「 binded _ execution _ payload _ envelope 」的新結(jié)構(gòu)，集中存儲(chǔ)執(zhí)行狀態(tài)轉(zhuǎn)換所需的關(guān)鍵信息。這樣的改進(jìn)將顯著提升 CL 客戶端在計(jì)算狀態(tài)轉(zhuǎn)換時(shí)的速度和效率。他還強(qiáng)調(diào)，這些調(diào)整將確保與未來(lái)的網(wǎng)絡(luò)升級(jí)，如簡(jiǎn)單序列化（ SSZ ）格式的兼容性。

Lighthouse 項(xiàng)目的開(kāi)發(fā)者 Mark Mackey 提出警告，如果不實(shí)施這些變更， CL 客戶端在 Pectra 測(cè)試網(wǎng)的性能可能會(huì)受到影響。 Teku 項(xiàng)目的開(kāi)發(fā)者 Mikhail Kalinin 對(duì)此表示謹(jǐn)慎，他質(zhì)疑是否真有必要通過(guò)改變協(xié)議來(lái)解決 Pectra 中 EIPs 實(shí)現(xiàn)的復(fù)雜性。 Potuz 則堅(jiān)持認(rèn)為，現(xiàn)有的協(xié)議設(shè)計(jì)存在根本性問(wèn)題，需要修正。他指出：「目前的設(shè)計(jì)在理念上就存在缺陷，它將對(duì) CL 狀態(tài)轉(zhuǎn)換至關(guān)重要的數(shù)據(jù)與完全無(wú)關(guān)的數(shù)據(jù)混合在同一級(jí)別、同一消息中。因此，我認(rèn)為當(dāng)前的設(shè)計(jì)是錯(cuò)誤的，我們正在努力糾正這一錯(cuò)誤?！?/p>

Stokes 鼓勵(lì)開(kāi)發(fā)者在GitHub上繼續(xù)討論這個(gè)提議。

Devnet 2 的引擎 API 更新

與上述討論相關(guān)， Geth 開(kāi)發(fā)者「 Lightclient 」提出了對(duì)引擎 API 的另一個(gè)變更。這個(gè)變更旨在使 EL 客戶端更容易進(jìn)行區(qū)塊轉(zhuǎn)換。 EL 客戶端通過(guò)解釋區(qū)塊中的空字段和空字段來(lái)確定區(qū)塊版本。然而，由于 Prague 的 EIP 7685，如果沒(méi)有分叉時(shí)間表， EL 客戶端將無(wú)法根據(jù)這些字段區(qū)分區(qū)塊版本。為了避免引用過(guò)去升級(jí)的時(shí)間表的開(kāi)銷(xiāo)， Lightclient 提議將所有請(qǐng)求統(tǒng)一為引擎 API 中的單一類(lèi)型， EL 可以將其傳遞給 CL 進(jìn)行解釋。

Lightclient 指出，區(qū)塊的解釋在 EL 和 CL 之間有所不同，而在這種情況下， CL 更適合表示請(qǐng)求數(shù)據(jù)?！府?dāng)我們處理區(qū)塊本身時(shí)，區(qū)塊沒(méi)有概念，『這是 Bellatrix 區(qū)塊?！唬拖裨?CL 上一樣。我認(rèn)為你們?cè)趨^(qū)分不同類(lèi)型的分叉區(qū)塊方面做得很好。但在 EL 上，我認(rèn)為這就是幾乎所有客戶端實(shí)現(xiàn)的方式，我們有一個(gè)區(qū)塊代表所有區(qū)塊類(lèi)型，我們使用存在的，比如一個(gè)值的空值，來(lái)確定那個(gè) [分叉] 是否活躍?！?/p>

Nimbus 開(kāi)發(fā)者「 Dustin 」反對(duì)這個(gè)提議，說(shuō) Lightclient 的提議并沒(méi)有充分解決 EL 和 CL 上區(qū)塊解釋的復(fù)雜性。「這只是將復(fù)雜性和混亂從 EL 轉(zhuǎn)移到 CL ，而且兩個(gè)地方都是可行的。將其移到 CL 并沒(méi)有解決問(wèn)題。……它只是移動(dòng)了問(wèn)題，」 Dustin 說(shuō)。

Stokes 斷言，CL 更適合處理請(qǐng)求的解釋?zhuān)⒔ㄗh開(kāi)發(fā)者更仔細(xì)地查看 Potuz 和 Lightclient 在GitHub上提出的引擎 API 變更。

Pectra 中的 EIP 7688 和 7495

Nimbus 開(kāi)發(fā)者 Etan Kissling 一直在推動(dòng)以太坊序列化方法更新為 SSZ 。為了 Pectra 的目的，他確定了兩個(gè)中間 EIPs ，7688 和 7495，以引入智能合約開(kāi)發(fā)者可以依賴(lài)的數(shù)據(jù)結(jié)構(gòu)，以與未來(lái)的 SSZ 相關(guān)變更兼容。 Kissling 指出，他已經(jīng)得到了像 Rocketpool 這樣的流動(dòng)質(zhì)押池的支持，以及 Teku 和 Lodestar 等其他客戶端團(tuán)隊(duì)的支持。

Stokes 警告 CL 客戶端團(tuán)隊(duì)不要在 Pectra 中添加新的 EIPs ?！?Pectra 已經(jīng)非常大了，特別是如果我們最終在分叉中有了 PeerDAS 。在某個(gè)時(shí)候，我們需要非?，F(xiàn)實(shí)地看待分叉的大小以及它所帶來(lái)的風(fēng)險(xiǎn)。再說(shuō)一次，我同意 Etan 給出的這個(gè)功能在真空中是有價(jià)值的理由，但我認(rèn)為這是我們做過(guò)的最大的硬分叉之一，或者就是最大的，這不應(yīng)該被輕視，」他說(shuō)。

開(kāi)發(fā)者們對(duì)這些 EIP 何時(shí)可以實(shí)際添加到 Pectra devnet 提出了一些擔(dān)憂，因?yàn)?Pectra devnet s 尚未納入許多 EIP ，如 PeerDAS 和 EOF 。對(duì)此， Jayanthi 建議首先明確決定開(kāi)發(fā)者是否應(yīng)該在升級(jí)中包括這些 EIP 。 Jayanthi 還警告說(shuō)，在測(cè)試 CL 和 EL EIP 一起在一個(gè) devnet 上時(shí)存在瓶頸。他在 Zoom 聊天中寫(xiě)道：「10 個(gè)直接的 EIP 一起發(fā)貨，會(huì)使得分叉在組合中測(cè)試變得非常復(fù)雜。而我們不僅有直接的 EIP ?！?/p>

Mackey 分享說(shuō)，像 EigenLayer 團(tuán)隊(duì)這樣的應(yīng)用開(kāi)發(fā)者正在試圖弄清楚 Pectra 中計(jì)劃激活的內(nèi)容，以及這些兩個(gè) EIP 的持續(xù)缺乏清晰度是他們工作的障礙。 Lighthouse 開(kāi)發(fā)者 Sean Anderson 建議從以太坊上的應(yīng)用開(kāi)發(fā)者那里獲取更多關(guān)于這些 EIP 的意見(jiàn)，以確定它們對(duì)應(yīng)用程序有多關(guān)鍵。

Stokes 建議稍后再重訪這個(gè)討論，以便開(kāi)發(fā)者集中精力解決 Pectra Devnet 1 的問(wèn)題。

PeerDAS 更新

開(kāi)發(fā)者們就 PeerDAS 的最新進(jìn)展進(jìn)行了深入討論。 Anderson 報(bào)告稱(chēng)，共識(shí)層（ CL ）客戶端團(tuán)隊(duì)正在積極修復(fù)在上一輪 PeerDAS 的 devne 中發(fā)現(xiàn)的問(wèn)題，并在啟動(dòng)新的 devne t 之前確保實(shí)現(xiàn)的穩(wěn)定性。 Lodestar 和 EthereumJS 的開(kāi)發(fā)者 Gajinder Singh 表示，根據(jù)最近一次 PeerDAS 實(shí)現(xiàn)者會(huì)議的反饋，社區(qū)有意向在下一個(gè) Pectra devne t 中集成 PeerDAS 。

Stokes 提出，根據(jù)與以太坊基金會(huì)（ EF ）研究團(tuán)隊(duì)及其他開(kāi)發(fā)者的討論，初步在主網(wǎng)上激活 PeerDAS 時(shí)可能需要省略抽樣功能，以降低實(shí)現(xiàn)的復(fù)雜性。他闡釋說(shuō)， PeerDAS 的完整實(shí)現(xiàn)涉及分發(fā)、抽樣和重建三個(gè)關(guān)鍵功能?！改壳?， PeerDAS 在 Pectra 中的規(guī)范涵蓋了這三個(gè)任務(wù)。我的直覺(jué)告訴我，抽樣功能可能是實(shí)現(xiàn)過(guò)程中最大的復(fù)雜點(diǎn)。如果抽樣確實(shí)帶來(lái)了難以克服的挑戰(zhàn)，我們可以考慮在 Pectra 中增加 blob 的數(shù)量，同時(shí)減少或調(diào)整 PeerDAS 的范圍，」 Stokes 解釋道。

Stokes 承諾，他將就此想法制定一個(gè)正式的提議，并與開(kāi)發(fā)者社區(qū)進(jìn)一步探討。 Singh 對(duì)此表示支持。 Stokes 還建議在 Pectra 升級(jí)中正式納入 PeerDAS 。對(duì)此， Jayanthi 詢問(wèn)這是否意味著要在 Pectra 規(guī)范的基礎(chǔ)上重新定義 PeerDAS 規(guī)范，并指出合并 PeerDAS 和 Pectra devnets 可能會(huì)因兩者都不穩(wěn)定而使調(diào)試工作復(fù)雜化。他建議在規(guī)范穩(wěn)定之前，應(yīng)保持兩個(gè)工作流程的獨(dú)立性。 Teku 的開(kāi)發(fā)者 Enrico Del Fante 也贊同 Jayanthi 的看法。

Stokes 注意到，許多專(zhuān)注于 PeerDAS 實(shí)現(xiàn)的開(kāi)發(fā)者未能參加此次會(huì)議。他提議在下一次 PeerDAS 實(shí)現(xiàn)者會(huì)議上繼續(xù)探討 PeerDAS 的未來(lái)步驟。

添加 BeaconBlocksByRange V3

Lighthouse 項(xiàng)目的開(kāi)發(fā)者「 Dapplion 」提出了一項(xiàng)改進(jìn)方案，旨在幫助客戶端在發(fā)生長(zhǎng)時(shí)間鏈分裂的情況下，能夠更有效地同步至主鏈。他指出，現(xiàn)有的 [ BeaconBlocksByRange V2 ] RPC 協(xié)議存在一定的局限性：「當(dāng)你需要同步一個(gè)長(zhǎng)分叉的區(qū)塊，而不確定哪個(gè)分支是主鏈時(shí)，按照當(dāng)前的協(xié)議，你只需提交一個(gè)插槽范圍，節(jié)點(diǎn)便會(huì)返回它認(rèn)為正確的區(qū)塊。盡管你可以通過(guò)狀態(tài)消息查詢這些信息，但這一過(guò)程存在異步性，可能會(huì)引發(fā)一些問(wèn)題。雖然目前主網(wǎng)上尚未出現(xiàn)嚴(yán)重的分叉情況，但如果未來(lái)發(fā)生類(lèi)似事件，這將是一個(gè)需要解決的問(wèn)題?！?/p>

Dapplion 進(jìn)一步說(shuō)明，他提出的解決方案相對(duì)簡(jiǎn)單，甚至有可能被納入即將到來(lái)的 Pectra 升級(jí)中。盡管這些改進(jìn)并非迫在眉睫，Stokes 還是鼓勵(lì)與會(huì)的開(kāi)發(fā)者們仔細(xì)審查這一提議，并在GitHub上分享他們的看法和建議。