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