原文標題：《Ethereum All Core Developers Execution Call #177 Writeup》

原文作者：Christine Kim

原文編譯：Sharon，BlockBeats

< br>

編按：

以太坊所有核心開發者共識電話（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 上實施時可能不需要任何協議內的變更。有關數據可用性和區塊鏈模組化的更多信息，可以閱讀這份報告。

「原文連結」

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia