原文來源：galaxy
編譯：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 上實施時可能不需要任何協議內的更改。有關數據可用性和區塊鏈模組化的更多信息，可以閱讀這份報告。
（以上內容獲合作夥伴 MarsBit 授權節錄及轉載，原文連結 | 出處：蜂巢財經）
聲明：文章僅代表作者個人觀點意見，不代表區塊客觀點和立場，所有內容及觀點僅供參考，不構成投資建議。投資者應自行決策與交易，對投資者交易形成的直接間接損失作者及區塊客將不承擔任何責任。
免責聲明：本文只為提供市場訊息，所有內容及觀點僅供參考，不構成投資建議，不代表區塊客觀點和立場。投資者應自行決策與交易，對投資者交易形成的直接或間接損失，作者及區塊客將不承擔任何責任。
