以太坊所有核心開(kāi)發(fā)者執(zhí)行電話（ACDE）每?jī)芍芘e行一次，主要討論和協(xié)調(diào)對(duì)以太坊執(zhí)行層（EL）的更改。本次為 ACDE 第 189 次電話會(huì)議，本次會(huì)議上，開(kāi)發(fā)者們就 Pectra 升級(jí)中的一些重要議題展開(kāi)了討論，包括包含 EOF 和 EIP 7702 在內(nèi)的改動(dòng)、改進(jìn) Pectra 范圍、以及準(zhǔn)備 Verkle 過(guò)渡等方面。
會(huì)議還討論了如何將 EOF 和其他 Pectra EIPs 打包，以及如何測(cè)試這些代碼變更。此外，還介紹了一些提議，旨在改進(jìn)以太坊網(wǎng)絡(luò)升級(jí)流程，包括對(duì) ACD 電話會(huì)議議題討論頻率的調(diào)整，以及新的 EIP 標(biāo)簽提案。對(duì)于 EIP 4444 和 Portal Network 的集成進(jìn)展也有所提及。?
Galaxy Digital 研究副總裁 Christine Kim 對(duì)本次會(huì)議要點(diǎn)做了詳細(xì)記錄，BlockBeasts 將原文編譯如下：
2024 年 6 月 6 日，以太坊開(kāi)發(fā)人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #189 會(huì)議。ACDE 電話會(huì)議是一個(gè)每?jī)芍芘e行一次的系列會(huì)議，由以太坊基金會(huì)協(xié)議支持主管 Tim Beiko 主持，開(kāi)發(fā)人員在會(huì)上討論和協(xié)調(diào)對(duì)以太坊執(zhí)行層（EL）的更改。本周，開(kāi)發(fā)者們同意將 EOF 和 EIP 7702 包含在 Pectra 升級(jí)中。為了避免由于這些代碼變更而導(dǎo)致的多客戶端測(cè)試升級(jí)延遲，開(kāi)發(fā)者們同意在后期開(kāi)發(fā)網(wǎng)絡(luò)上激活 EOF，并可能在不同于其他 EIP 的激活周期內(nèi)激活，就像開(kāi)發(fā)者計(jì)劃測(cè)試 PeerDAS 一樣。他們還討論了在 Osaka 升級(jí)中如何停用 EIP 158 以準(zhǔn)備 Verkle，并通過(guò)與 Portal Network 的集成來(lái)實(shí)施 EIP 4444 的下一步。最后，Beiko 和 EF 開(kāi)發(fā)者運(yùn)營(yíng)（DevOps）團(tuán)隊(duì)分享了治理流程和規(guī)劃以太坊升級(jí)的溝通渠道的最新更新。
Pectra 的范圍?
在本周的 ACD 會(huì)議之前，各個(gè) EL 客戶端團(tuán)隊(duì)和 EF DevOps 團(tuán)隊(duì)分享了他們對(duì) Pectra 范圍的看法。
- Besu 觀點(diǎn)
- EthJS 觀點(diǎn)
- Nethermind 觀點(diǎn)
- Reth 觀點(diǎn)
- EthPandaOps 觀點(diǎn)
根據(jù)會(huì)前分享的觀點(diǎn)，顯然大多數(shù)客戶端團(tuán)隊(duì)都支持在 Pectra 中包含 EOF。唯一強(qiáng)烈反對(duì) EOF 的客戶端團(tuán)隊(duì)是 Geth。Geth 開(kāi)發(fā)者 Guillaume Ballet 說(shuō)：「我擔(dān)心我們等得越久，Verkle 轉(zhuǎn)換所需的時(shí)間就會(huì)越長(zhǎng)。EOF 真的那么緊急嗎？我不這么認(rèn)為。我讀了幾篇關(guān)于在 Prague 發(fā)布 EOF 的論點(diǎn)。讀得越多，我越意識(shí)到，沒(méi)有什么真正能證明 EOF 是必要的?！箤?duì)此，幾位開(kāi)發(fā)者提出了反對(duì)意見(jiàn)。
一位名叫「Kamil Sliwak」的開(kāi)發(fā)者表示，從與以太坊智能合約編程語(yǔ)言 Solidity 的編譯器交互的用戶角度來(lái)看，EOF 將是「一項(xiàng)巨大的改進(jìn)」。Reth 開(kāi)發(fā)者 Dragan Rakita 補(bǔ)充說(shuō)，認(rèn)為 EOF 會(huì)顯著延遲 Verkle 轉(zhuǎn)換是不誠(chéng)實(shí)的?！肝覀冋?wù)摰氖?10% 到 20% 的轉(zhuǎn)換時(shí)間延長(zhǎng)。EOF 不會(huì)增加狀態(tài)，額外的三個(gè)月來(lái)發(fā)布額外的部分分叉，不會(huì)顯著延遲 Verkle」Rakita 說(shuō)。關(guān)于 EOF 是什么以及它將如何改進(jìn)以太坊虛擬機(jī)（EVM）的更多信息，請(qǐng)收聽(tīng)《無(wú)限叢林》播客的這一集。
Beiko 詢問(wèn)開(kāi)發(fā)者是否更愿意將 EOF 與其他 Pectra 的 EIP 捆綁在一起，還是將 Pectra 的 EIP 分成兩個(gè)硬分叉。Erigon 開(kāi)發(fā)者 Andrew Ashikhmin 表示，他認(rèn)為開(kāi)發(fā)者應(yīng)該嘗試將所有 Pectra 的 EIP 一起發(fā)布，或者推遲 EOF 直到 Verkle 轉(zhuǎn)換之后。「我最不希望的是，在 Pectra 和 Verkle 之間進(jìn)行一次分叉以發(fā)布 EOF。因?yàn)槲彝?Guillaume 的觀點(diǎn)，即狀態(tài)正在增長(zhǎng)，我認(rèn)為 Verkle 比 EOF 更重要。所以在我看來(lái)，這是最糟糕的結(jié)果，」Ashikhmin 說(shuō)。Beiko 建議將所有 Pectra 的 EIP，包括 EOF，在一個(gè)客戶端版本中發(fā)布。然而，為了測(cè)試的目的，他表示開(kāi)發(fā)者應(yīng)該考慮使用開(kāi)發(fā)網(wǎng)絡(luò)來(lái)分階段實(shí)施這些代碼更改。「使用開(kāi)發(fā)網(wǎng)絡(luò)作為我們?cè)诙嗫蛻舳藴y(cè)試方面優(yōu)先考慮的方式，然后如果我們看到 EOF 會(huì)長(zhǎng)時(shí)間延遲事情，我們可以決定將其分開(kāi)，」Beiko 說(shuō)。
在這些關(guān)于如何將 EOF 納入 Pectra 的討論中，Geth 開(kāi)發(fā)者在 Zoom 聊天和整個(gè)會(huì)議中繼續(xù)表達(dá)了對(duì)是否應(yīng)該將 EOF 包含在升級(jí)中的質(zhì)疑。為了應(yīng)對(duì) Geth 團(tuán)隊(duì)對(duì) EOF 的持續(xù)爭(zhēng)論，Reth 開(kāi)發(fā)者 George Konstantinopoulos 說(shuō)：「讓我們直接做吧。對(duì)話的走向有點(diǎn)令人困惑。我們不介意將 Verkle 轉(zhuǎn)換延長(zhǎng)幾天。數(shù)據(jù)顯示狀態(tài)正在下降，所以這是一個(gè)令人困惑的論點(diǎn)，而且你有一堆應(yīng)用程序告訴你這是一個(gè)好功能。既然大多數(shù)人都表示支持，我們?yōu)槭裁催€要考慮不做呢，這很令人困惑。」
Beiko 同意這一觀點(diǎn)，并重申 EOF 應(yīng)該包含在 Pectra 中，但要在開(kāi)發(fā)網(wǎng)絡(luò)上分階段測(cè)試，這意味著客戶端團(tuán)隊(duì)?wèi)?yīng)在 Devnet 1 上測(cè)試已經(jīng)在 Devnet 0 上實(shí)現(xiàn)的 EIP。然后，在未來(lái)的開(kāi)發(fā)網(wǎng)絡(luò)上，再添加 EOF 進(jìn)行測(cè)試。這一策略將確保客戶端團(tuán)隊(duì)在相同的時(shí)間線上專(zhuān)注于發(fā)布一部分 Pectra 的 EIP，并能夠在多客戶端開(kāi)發(fā)網(wǎng)絡(luò)上繼續(xù)取得進(jìn)展。以太坊基金會(huì)（EF）DevOps 工程師 Mario Vega 表示，他預(yù)計(jì)在兩個(gè)月內(nèi)準(zhǔn)備好 EOF 的執(zhí)行層（EL）規(guī)范測(cè)試。EF DevOps 工程師 Parithosh Jayanthi 表示，EOF 可以與 Pectra 中的其他執(zhí)行層（EL）EIP 分開(kāi)測(cè)試。然而，他擔(dān)心 Pectra 中的共識(shí)層（CL）EIP 之間的相互依賴性以及測(cè)試這些代碼更改的復(fù)雜性。
Vyper 編譯器開(kāi)發(fā)者 Charles Cooper 表示，在他看來(lái)，EOF 并不像他提議的代碼更改那樣緊急，這些更改旨在使防止重入攻擊的保護(hù)變得廉價(jià)和普遍。Beiko 提醒 Cooper，雖然對(duì) EOF 的廣泛共識(shí)是明確的，但不清楚客戶端團(tuán)隊(duì)是否有足夠的精力添加更多的代碼更改，例如與重入攻擊相關(guān)的更改?！肝艺J(rèn)為很清楚的是，如果我們推進(jìn) EOF，就幾乎沒(méi)有精力去做其他事情了。這已經(jīng)將是迄今為止最大的分叉，」Beiko 說(shuō)。
除了包含 EOF，開(kāi)發(fā)者們還同意將 EIP 7702 作為 EIP 3074 的替代方案。開(kāi)發(fā)者們?nèi)栽趩为?dú)的小組會(huì)議中討論 EIP 7702 的規(guī)范。Beiko 建議對(duì) EIP 7702 采用與 EOF 類(lèi)似的方法?！肝視?huì)將它包含在分叉中，但如果我們對(duì)規(guī)范不太滿意，就不將它作為 Devnet 1 或 2 的一部分，然后花下一個(gè)月的時(shí)間真正理清規(guī)范，這樣我們就有了一個(gè)比現(xiàn)在提議的更好的撤銷(xiāo)機(jī)制。稍后在過(guò)程中添加一個(gè)不算太大的 EIP，」Beiko 說(shuō)。Geth 開(kāi)發(fā)者「Lightclient」表示，如果客戶端團(tuán)隊(duì)準(zhǔn)備好了，他們應(yīng)該盡快實(shí)施 EIP 7702。沒(méi)有人反對(duì)在下一個(gè)緊急的 Pectra 開(kāi)發(fā)網(wǎng)絡(luò) Devnet 1 中包含 EIP 7702。
Pectra 規(guī)范
隨后，Teku 開(kāi)發(fā)者 Mikhail Kalinin 分享了一些現(xiàn)有 Pectra EIP 規(guī)范的更新。第一個(gè)是建議通過(guò)側(cè)車(chē)機(jī)制處理觸發(fā)共識(shí)層（CL）請(qǐng)求，而不是直接在執(zhí)行層（EL）塊中處理。Prysm 開(kāi)發(fā)者「Potuz」指出，這一策略會(huì)破壞未來(lái)代碼更改所需的邏輯，即明確的提議者構(gòu)建者分離（ePBS）。「信標(biāo)塊不應(yīng)該依賴于有效負(fù)載已經(jīng)存在。所以，無(wú)論是提款還是存款，你都不希望信標(biāo)塊依賴于有效負(fù)載中的內(nèi)容，因?yàn)檫@會(huì)破壞 ePBS 的流程，」Potuz 說(shuō)。由于這個(gè)問(wèn)題，Kalinin 同意撤回他的建議并關(guān)閉 GitHub 上的拉取請(qǐng)求。
Kalinin 分享了幾項(xiàng)關(guān)于 Pectra 的 EL 和引擎 API 規(guī)范的其他變更，其中之一是啟用 EIP 7251 下的 EL 觸發(fā)合并，增加 MAX_EFFECTIVE_Balance。Beiko 建議開(kāi)發(fā)者在下一次 ACD 電話會(huì)議之前審查這些變更，以便它們可以在 Devnet 1 中進(jìn)行測(cè)試前完成和準(zhǔn)備好。
Verkle 準(zhǔn)備
根據(jù)他為 Verkle 過(guò)渡所做的工作，Ballet 表示，EIP 158 將導(dǎo)致與已棄用的操作碼 SELFDESTRUCT 類(lèi)似的問(wèn)題。為了在過(guò)渡后避免網(wǎng)絡(luò)上的復(fù)雜情況，Ballet 建議在 Pectra 升級(jí)中停用 EIP 158。然而，他指出，如果在 Pectra 中對(duì) EIP 7702 的實(shí)施進(jìn)行了微調(diào)，那么停用 EIP 158 可能會(huì)被推遲，并與 Verkle 過(guò)渡同時(shí)發(fā)生。Beiko 建議 Guillaume 開(kāi)始起草他的停用 EIP 158 的提案。
歷史到期
除了 Pectra 和 Verkle，以太坊協(xié)議開(kāi)發(fā)者還致力于 EIP 4444，歷史到期。正如 EIP 4444 計(jì)劃和摘要文件所述，進(jìn)行這種代碼更改的原因是「區(qū)塊歷史占據(jù)了節(jié)點(diǎn)大量的空間，而一旦該區(qū)塊已經(jīng)完成，它只需要用于有限的非共識(shí)關(guān)鍵用例?！刮募^續(xù)說(shuō)明，「區(qū)塊歷史將不再由全節(jié)點(diǎn)永久存儲(chǔ)。一段時(shí)間后，它將從節(jié)點(diǎn)中刪除，并且需要它的實(shí)體將需要從其他地方查詢?！筆ortal Network 是一個(gè)替代的、分散的網(wǎng)絡(luò)，用于節(jié)點(diǎn)查詢以太坊歷史數(shù)據(jù)。
Merriam 重申他的團(tuán)隊(duì)愿意為 EL 客戶團(tuán)隊(duì)提供與 Portal Network 的集成支持。他說(shuō)，如果沒(méi)有任何支持，集成大約需要 6 個(gè)月的時(shí)間來(lái)開(kāi)發(fā)完畢。然而，通過(guò)指導(dǎo)和密切合作，他樂(lè)觀地認(rèn)為在接下來(lái)的兩個(gè)月內(nèi)可以在 EIP 4444 上取得有意義的進(jìn)展。Jayanthi 詢問(wèn)是否對(duì) Portal Network 規(guī)范進(jìn)行了安全審計(jì)。Merriam 表示沒(méi)有。以太坊基金會(huì)研究員 Ansgar Dietrichs 問(wèn)客戶團(tuán)隊(duì)是否可以自行決定如何與網(wǎng)絡(luò)進(jìn)行接口，包括將集成與現(xiàn)有客戶端捆綁、構(gòu)建新客戶端，或者干脆不進(jìn)行任何集成。Merriam 確認(rèn)這一決定由客戶團(tuán)隊(duì)自行決定。
Merriam 詢問(wèn)電話會(huì)議中的 EL 客戶團(tuán)隊(duì)有關(guān)他們?cè)?EIP 4444 上的進(jìn)展和意圖。Nethermind 開(kāi)發(fā)者?ukasz Rozmej 表示：「總體而言，這是一個(gè)優(yōu)先事項(xiàng)。我們甚至昨天與 Portal 團(tuán)隊(duì)開(kāi)了一個(gè)會(huì)議。問(wèn)題是有太多的優(yōu)先事項(xiàng)。有時(shí)候很難正確地平衡所有事情。因此，與例如硬分叉相比，它是不那么緊急的優(yōu)先事項(xiàng)，但 Nethermind 將會(huì)著手處理，并且我們將予以優(yōu)先考慮?！笲esu 開(kāi)發(fā)者 Matt Nelson 表示他的看法是一樣的。Geth 開(kāi)發(fā)者 Guillaume Ballet 表示他的團(tuán)隊(duì)還沒(méi)有討論過(guò) Portal Network 的集成。
ACD 流程改進(jìn)
ACD 流程改進(jìn) 接著，Beiko 分享了幾項(xiàng)改進(jìn)以太坊網(wǎng)絡(luò)升級(jí)流程的建議。他首先建議減少 ACD 電話會(huì)議上討論客戶團(tuán)隊(duì)尚未詳細(xì)審查的話題的頻率。Beiko 建議，在允許開(kāi)發(fā)者進(jìn)行專(zhuān)業(yè)討論之前，先在 ACD 電話會(huì)議上標(biāo)記這些話題進(jìn)行審查，然后根據(jù)需要在隨后的 ACD 電話會(huì)議上更詳細(xì)地討論這些話題。
Beiko 提出的第二個(gè)建議涉及通常附加在考慮納入硬分叉的以太坊改進(jìn)提案（EIP）上的「考慮納入」（CFI）狀態(tài)。這個(gè)狀態(tài)在歷史上并沒(méi)有有效地指示哪些 EIP 更有可能被納入硬分叉中。Beiko 建議創(chuàng)建另一個(gè)標(biāo)簽「擬納入」（PFI），以便開(kāi)發(fā)者能夠更好地區(qū)分哪些 EIP 更有可能被納入硬分叉，而哪些不會(huì)。
以太坊基金會(huì)研究員 Ansgar Dietrichs 在 Zoom 聊天中寫(xiě)道，為 EIP 創(chuàng)建新標(biāo)簽是「錯(cuò)誤的方向」，只會(huì)導(dǎo)致 CFI 標(biāo)簽變得「完全無(wú)用」。Beiko 表示，開(kāi)發(fā)者可以繼續(xù)在 GitHub 和 EthMagicians 上討論改進(jìn)網(wǎng)絡(luò)升級(jí)流程的問(wèn)題。
此外，以太坊基金會(huì)的 DevOps 工程師 Mario Vega 表示，他希望為與測(cè)試相關(guān)的更新創(chuàng)建一個(gè)新的 Discord 子頻道。維加表示，目前在以太坊研發(fā) Discord 中，測(cè)試發(fā)布信息分散在多個(gè)頻道中。然而，他希望這個(gè)新的論壇能夠成為客戶團(tuán)隊(duì)從以太坊基金會(huì) DevOps 團(tuán)隊(duì)獲取測(cè)試更新的「一站式」參考。他要求客戶團(tuán)隊(duì)就此提出反饋意見(jiàn)。
最后，Beiko 提醒開(kāi)發(fā)者，接下來(lái)幾天安排了兩次小組會(huì)議，一次是關(guān)于 ePBS 的，將于 6 月 7 日舉行，另一次是關(guān)于 PeerDAS 的，將于 6 月 11 日舉行。