以太坊核心开發者最新會議摘要:測試網坎昆升級時間、L2預編譯地址範圍

發表於 2023-12-22 17:00 作者: 區塊鏈情報速遞pro

原文標題:《Ethereum All Core Developers Execution Call #177 Writeup》
原文作者:Christine Kim
原文編譯:Sharon,BlockBeats

編者按:
以太坊所有核心开發者共識電話(ACDE)每兩周舉行一次,主要討論和協調對以太坊執行層(EL)的更改。本次爲 ACDE 第 177 次電話會議,初步確定了 Goerli、Sepolia、Holesky 的分叉時間,分別爲 1 月 17 日、1 月 31 日和 2 月 7 日。

此外,开發者們就 L2 的預編譯地址範圍、Prague/Electra 升級進行了討論,同時決定跳過下周四的 ACD 電話會議,並在 1 月 4 日重新召开 ACDE#178。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄,BlockBeats 將原文編譯如下:


2023 年 12 月 21 日,以太坊开發者通過 Zoom 參加了第 177 次全核心开發執行(ACDE)電話會議。由以太坊基金會的協議支持主管 Tim Beiko 主持,ACDE 電話會議是一系列每兩周一次的會議,开發者在會上討論和協調以太坊執行層(EL)的變更。


本周,开發者確定了在所有三個公共以太坊測試網絡上激活 Cancun/Deneb 升級的暫定日期。測試網絡升級的時間表如下:


Goerli 分叉將於 1 月 17 日進行;

Sepolia 分叉將於 1 月 31 日進行;

Holesky 分叉將於 2 月 7 日進行。


由於开發者在接下來的幾周內需要更新由於意外錯誤和客戶端發布問題,以上日期可能會產生變更。此外,开發者還討論了第二個 Goerli 影子分叉的性能、L2 的預編譯地址範圍以及 Prague/Electra 升級的預期。开發者同意取消下周四(12 月 28 日)的全核心开發者共識(ACDC)電話會議,並計劃在 1 月 4 日星期四重新召开常規 ACD 會議。


Goerli 影子分叉


以太坊基金會的 DevOps 團隊,於 12 月 19 日啓動了 Goerli 測試網絡的第二個影子分叉。這個影子分叉由分布在紐約、法蘭克福、班加羅爾和悉尼的 290 個節點激活,每個節點運行 100 個驗證器。除了 Erigon 客戶端之外,幾乎所有以太坊客戶端都能夠加入影子分叉並成功升級。


基金會的 DevOps 工程師 Parithosh Jayanthi 表示,自分叉啓動以來,網絡參與率在 99% 到 100% 之間波動,表明幾乎所有 Goerli 影子分叉上的驗證器都能正確連接到網絡。


他指出,由於 Cancun/Deneb 升級,網絡上的節點平均帶寬增加了大約 200kbps。盡管如此,在 blob 垃圾郵件和 blob 延遲測試期間,網絡沒有發生任何區塊重組事件或嚴重的區塊傳播延遲。然而,Jayanthi 也指出,區塊傳播事件在不同的 CL 客戶端中以不同的方式發出。某些 CL 客戶端將在驗證之前爲區塊發出事件日志,而其他客戶端將僅在驗證後發出事件。


要閱讀有關 Goerli 影子分叉(GSF)#1 的更詳細分析,請參閱基金會 DevOps 團隊編寫的文章。


Jayanthi 表示,DevOps 團隊計劃在 12 月 21 日星期四結束時棄用 GSF#1。Lodestar 和 EthereumJS 客戶端的开發人員 Gajinder Singh 指出,他仍在對影子分叉進行額外測試。Jayanthi 同意與 Singh 核實,確保他能在關閉 GSF#1 之前在 Devnet#12 上復制這些測試。


下一步


基於 GSF#1 的結果,开發者討論了測試 Cancun/Deneb 升級的下一步。Beiko 詢問 Prysm 客戶端團隊是否愿意在 1 月份爲 Goerli 測試網絡設定一個暫定的分叉日期。Prysm 客戶端的开發人員 James He 表示,該團隊仍在解決其客戶端中的一些錯誤,並計劃在 1 月 8 日前查看修復版本的暫定發布日期。


其他客戶端團隊也傾向於在 1 月中旬而不是 1 月底設定 Goerli 分叉日期,开發者們暫時同意在 1 月 17 日激活 Cancun/Deneb 升級。


Beiko 表示,客戶端團隊需要在 1 月 8 日或 9 日之前共享其軟件的更新版本,以便 Goerli 節點運營商有時間升級他們的設備,如果他們決定在 1 月 17 日進行分叉。Beiko 還將在 1 月 8 日那周發布一篇博客文章,在以太坊基金會博客上宣布 Goerli 分叉日期,以便 Goerli 用戶了解全網升級。


Ansgar Dietrichs 詢問开發者,是否還應爲將在以太坊主網之前升級的另外兩個以太坊公共測試網絡制定目標日期。經過一番討論,开發者們同意在 Goerli 後的兩周內,即 1 月 31 日,爲 Sepolia 測試網絡設定目標升級日期;在之後的一周,即 2 月 7 日,爲 Holesky 測試網絡設定升級日期。


开發者計劃爲 Sepolia 和 Holesky 測試網絡升級捆綁一個單一的客戶端發布和公告帖,以便在這兩個 Cancun/Deneb 激活之間有一個更短的一周的周轉時間。在 Zoom 聊天中,Dietrichs 說:「我認爲在過去我們通常只有較少的測試網絡,所以捆綁發布似乎是一個很好、很實用選擇。」


以太坊基金會的 DevOps 工程師 Barnabas Busa 提到,在 Sepolia 測試網絡升級之前升級 Holesky 測試網絡可能更有用,以盡早捕捉與網絡相關的錯誤,因爲 Holesky 托管的驗證器數量比 Sepolia 測試網絡更多。然而,盡管規模較小,Sepolia 托管的用戶比 Holesky 更多。


因此,如果先在 Holesky 之前升級,L2 團隊可能會有更多時間測試其操作。开發者們同意在目前繼續升級 Sepolia 之前升級 Holesky,並在 Goerli 分叉後重新審視此順序。Jayanthi 表示:「我認爲我們將從 Goerli 中學到最多,因爲驗證器集合足夠小。有很多獨特的 [節點] 設置等等。」


預編譯地址範圍


接下來,开發者們討論了 L2 的預編譯地址範圍。


預編譯(precompile)是以太坊上的地址,類似於智能合約,能夠執行通過以太坊虛擬機(EVM)直接執行可能過於昂貴的復雜加密計算。SHA3、RIPEMD160 和 BLAKE2 是以太坊上已支持的預編譯哈希函數的例子。


由於 L2 希望通過添加新的預編譯功能來擴展智能合約執行功能,而這些功能可能在以太坊上尚不存在,有一個問題是 L2 是否應該使用以太坊未來可能使用的預編譯地址。


Dietrichs 在 GitHub 的評論中解釋說:「在未來,許多新的 EVM 預編譯將首先在(某些或全部)L2 上引入…然後可能或可能不會在 L1 上後續引入。現在非常希望能夠提出一種預編譯地址方案,確保對於任何給定的 RIP 預編譯,L1 上都保留了該地址,這意味着該地址上從未引入過其他衝突的預編譯,如果在 L1 上以相同形式引入,則用於該 RIP 預編譯。」


RIP 指的是新創建的「Rollup Improvement Proposal」(Rollup 改進提案)流程。RIP 流程是一種 L2 自愿選擇的標准,旨在鼓勵 EVM 相關變更的標准化和協調。L2 首次尋求以標准方式採用的第一個預編譯是 secp256r1 橢圓曲线籤名驗證的預編譯。有關此提案的更多信息,請閱讀相關的 RIP文檔。


Dietrichs 在電話會議上表示,L2 可以採取兩種方式爲此預編譯分配地址。


首先在 L2 上啓動的 EVM 更改可以分配一個與以太坊相同的預編譯地址範圍內的數字,或者使用一個與以太坊預編譯地址範圍不同的範圍。


以太坊基金會的研究員 Danny Ryan 支持 L2 使用不同範圍的地址,因爲 RIP 流程仍然存在很多不確定性。他說:「我支持爲 L2 添加一個範圍,如果在 L1 採用 EIP 之前對其進行了重大採用,可以使用不同的順序並使用從該範圍中選擇的內容爲 L1 使用,因爲目前對 RIP 會發生什么仍然非常不清楚。」


Geth 开發人員 Marius van der Wijden 也支持 L2 在被以太坊採用之前使用不同的預編譯地址範圍。他還補充說,开發者應該根據情況討論是否在 L1 上和 L2 上使用相同的地址:「我並不完全同意只使用 L2 提出的內容。我認爲需要對此進行辯論。」


Ryan 補充說,在 L2 和以太坊主網之間使用不同的預編譯地址,並在 L2 上對預編譯功能進行更改的情況下,創造出使用不同預編譯地址的選擇性,與 RIP 流程的 EIP 過程解耦尤爲重要。然而,以太坊基金會的研究員 Carl Beekhuizen 對在 L2 和以太坊主網之間使用不同的預編譯地址提出了異議,並稱「僅因爲未來可能會發生變化,我們就不必要地默認進入一個最壞情況。」


由於存在爭議,Dietrichs 建議 L2 目前使用與以太坊主網不同的預編譯地址範圍。他補充說,當在未來激活新的在 L2 上已被廣泛採用的 Ethereum 預編譯時,开發者可以隨後決定是否要使用與 L2 上已實施的相同的預編譯地址。關於自定義地址範圍,开發者們同意爲 L2s 保留 0x512 地址範圍,通過 RIP 流程使用。


开發者們還同意創建一個新的信息性 EIP,說明這一點,並在 RIP GitHub 存儲庫中引用其他有關 L2 使用哪些地址進行預編譯的信息。


ACD 電話會議安排


正如在 ACDC#124 上討論的那樣,开發者們將跳過下周四的 ACD 電話會議,改爲在 Discord 上進行非正式的檢查。他們將在 1 月 4 日星期四重新召开 ACDE#178。ACDE#178 將由 Geth 开發人員「lightclient」主持,代替 Beiko,因爲他將不參加該電話會議。


Prague/Electra 提案


作爲討論的最後一個主題,Beiko 在以太坊魔法師社區中呼籲开發者關注 Prague/Electra升級。Beiko 強調,客戶端團隊應該審查 Prague/Electra 的提案,並准備討論應該優先考慮哪些代碼更改用於下一次以太坊升級。


關於 Prague/Electra 的範圍,Dietrichs 提到,开發者應該盡量在 Cancun/Deneb 之後,即在 2024 年底之前,實現一次小型升級的激活,而不是試圖捆綁復雜的代碼更改,這可能會延遲對更加時間敏感的 EIP 的激活。


Ryan 補充說,开發者在 Prague/Electra 升級時不必進行「跨層分叉」。EL 和 CL 的代碼更改可以獨立地進行部署。


开發者們預計在 Cancun 升級後不久,EL 上將激活的主要代碼更改是 Verkle Trie 升級。正如在先前的通話中討論的那樣,用更強大的 Verkle 樹替換當前對數據組織使用的 Merkle Patricia 樹的升級在過去一年中取得了顯著進展,並且可能在 2024 年准備好實施。


然而,由於升級的復雜性和風險,Geth 开發者 Guillaume Ballet 表示,Verkle 升級不應與其他復雜的代碼更改或 EIP 捆綁在一起。开發者們同意在新的一年重新討論「僅 Verkle 升級」的問題。他們還同意安排一個專門的 ACDE 電話會議,深入討論 Verkle 升級的細節。


此外,Dietrichs 提到,數據可用性抽樣是一項旨在降低以太坊數據可用性成本的升級,正在取得「良好的進展」,並且在准備在 CL 上實施時可能不需要任何協議內的更改。有關數據可用性和區塊鏈模塊化的更多信息,可以閱讀這份報告。


「原文鏈接」


OKEX下載,歐易下載,OKX下載

okex交易平台app下載

標題:以太坊核心开發者最新會議摘要:測試網坎昆升級時間、L2預編譯地址範圍

地址:https://www.coinsdeep.com/article/77764.html

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

你可能還喜歡
熱門資訊