以太坊核心開發者最新會議摘要：坎昆升級1月17日在Goerli測試網進行、Prague/Electra代碼更改優先級

2024 年 1 月 4 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #178 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，通常由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本周，電話會議由一個化名為「Lightclient」的 Geth EL 開發人員主持。開發者確認了 Cancun/Deneb（Dencun）升級的下三個公共測試網激活日期，並討論了 Dencun 之後的下一個硬分叉升級 Prague/Electra 的代碼更改優先級，這些更改通常被稱為以太坊改進提案（EIPs）。本次會議是開發者討論和協調對以太坊執行層（EL）的更改的系列會議之一。

Dencun 更新

在假期期間，Dencun 升級並未進行特定的更新。自 12 月 21 日的最後一次 ACD 電話會議以來，客戶端團隊一直在為 Goerli 測試網準備新版本。由於之前因為 Prysm 導致升級測試延遲的原因，Geth 開發人員 Marius van der Wijden 向 Prysm 客戶端團隊請求了關於他們切割新版本進展的更新。Prysm 開發人員 Terence Tsao 確認 Prysm 團隊將在下周為 Goerli 硬分叉準備一個新版本。然而，Goerli 版本將是一個「預發布」，意味著這不是 Prysm 在以太坊主網上推薦使用的版本。在 Goerli 硬分叉之後，Prysm 團隊計劃發布另一個版本，其中包含某些更改和更新，將推薦用戶在主網上運行，並在 Sepolia 和/或 Holesky 測試網上進行測試。客戶端團隊一直在為 Goerli 測試網準備新版本。

儘管 Tsao 表示 Prysm 團隊對於在 ACDE #177 上討論的 1 月 17 日 Goerli 硬分叉激活日期感到滿意，但他建議在 Goerli 硬分叉之後再確定 Sepolia 和 Holesky 硬分叉激活的日期。自 ACDE #177 以來，以太坊基金會協議支持負責人 Tim Beiko 提出了所有三個以太坊公共測試網（Goerli、Sepolia 和 Holesky）的分叉時間。提議的分叉激活時間如下：

· Goerli - 2024 年 1 月 17 日 - 紀元 231680 – 時間戳 1705473120

· Sepolia - 2024 年 1 月 30 日 - 紀元 132608 - 時間戳 1706655072

· Holesky - 2024 年 2 月 7 日 - 紀元 29696 – 時間戳 1707305664

Lightclient 詢問，在 Beiko 提議的 Goerli 硬分叉激活時間上，除了 Prysm 之外的其他客戶端團隊是否感到滿意。電話會議上的所有客戶端團隊，包括 Geth、Lodestar、Lighthouse、Teku 和 Besu，都確認這個時間對他們來說看起來不錯，並且他們將在最遲下周為 Goerli 節點營運商準備好發布。Lighthouse 客戶端團隊指出，與 Prysm 一樣，由於他們仍在測試客戶端上的某些網路功能，他們的發布可能是一個預發布。

Dencun 時間表分歧

接着，Lightclient 就 Sepolia 和 Holesky 測試網提議的激活時間向大家開放了討論。一位化名為「Potuz」的 Prysm 開發人員建議在主網升級之前不要確定最後兩個測試網的日期。「我們應該儘量不要現在確定日期，因為可能 Goerli 的情況不太好，而後退是一個問題。添加一個帶有正確紀元但沒有更改的新版本很容易。刪除一個版本並修復錯誤是一個難題。這要花費多於幾周的時間，」Potuz 說。

Lightclient 強調，客戶端團隊在 Goerli 硬分叉之後一周內不必發布新版本，因此，除非在 1 月 24 日或附近發現了與升級相關的問題，否則可能不必刪除版本。Geth 開發人員 Marius van der Wijden 表示，鑒於開發人員隨時可以更改它們，他認為在 Sepolia 和 Holesky 測試網上設定日期不會有任何問題，即使 Goerli 出現問題。

以太坊基金會 DevOps 工程師 Barnabas Busa 在 Zoom 聊天中寫道，在他看來，確認 Goerli 版本正常運行後，才有意義為 Sepolia 和 Holesky 升級切割新版本。贊同這一觀點的 Lighthouse 開發人員，化名「Sean」，表示開發人員可以為 Sepolia 硬分叉設置一個「暫定」日期，但應在確認 Goerli 版本正常運行後再決定是否繼續 1 月 30 日的計劃。

Potuz 建議在 Goerli 和 Sepolia 硬分叉激活之間增加一周的測試時間，基本上是兩周的分析時間，而不是三周。他說，額外的一周測試時間將為客戶端發布提供時間，讓其在客戶端團隊需要再次為下一個測試網升級切割新版本之前「浸泡」幾天。「兩周太緊張了。這是我指出的問題，」Potuz 說，並補充說，如果 Goerli 客戶端版本經過充分分析和測試，那麼在 Sepolia 和 Holesky 硬分叉激活之間可能不需要三周的周轉時間。

Potuz 的觀點引起了爭議。以太坊基金會的 Ansgar Dietrichs 稱升級的第一個公共測試網激活和主網激活之間的時間通常是開發人員不需要延長的「死時間」。然而，Dietrichs 還指出，在測試網升級之間延長時間的願望是開發人員應該在硬分叉的整體背景下更認真討論的問題，而不僅僅是在 Dencun 升級中。「如果有延長過程的願望，那麼我們可能應該在有時間的時候進行討論，而不是在硬分叉之前，」Dietrichs 說。

Lightclient 同意 Dietrichs 的觀點，表示如果在例如十月早些時候進行討論，開發人員可能會更願意延長 Dencun 測試網的時間。「我認為其中的一部分原因是我們希望在去年秋天發布這個升級，所以現在我們真的在努力實現它，我認為我們制定了一些更為積極的時間表，」Lightclient 說。

堅持積極的時間表

根據開發人員在會議上分享的觀點，以太坊基金會 DevOps 工程師 Parithosh Jayanthi 建議將 Sepolia 硬分叉升級推遲一周左右，並在 1 月 25 日的 ACD 會議上為 Sepolia 硬分叉設定一個日期，該日期在 Goerli 升級後。Marius van der Wijden 反對僅僅依賴 ACD 會議重新討論測試網升級激活日期。「我真的不希望我們必須去另一個 All Core Devs 來確認日期，」他說，並補充說：「我不想再參加另一個 All Core Devs 會議只是為了說，『好的，Sepolia 現在可以進行。』然後我們必須等待兩周才能真正進行 Sepolia。」

試圖安撫各方，Geth 開發者 Guillaume Ballet 建議為 Sepolia 硬分叉創建兩組暫定日期，一組是在 Goerli 硬分叉的結果積極的情況下開發者堅持使用的，另一組是在 Goerli 硬分叉的結果為負的情況下開發者回退使用的。然而，Lightclient 和 Dietrichs 都反對這個想法，因為在開發人員實際上可以為 Sepolia 硬分叉設置新的時間表之前，必須首先評估 Goerli 上的錯誤和問題的性質。

順便說一句，以太坊基金會測試團隊的一位化名開發者，屏幕名為「Danceratopz」，詢問開發者是否希望等待在升級 Sepolia 之前在 Goerli 測試網上評估 blob 到期。背景是，blob 到期是指在大約兩周的時間後從以太坊狀態中刪除 blob 數據。有關 blobs 和 proto-danksharding 的更多資訊，請閱讀這份 Galaxy Research 報告。

Lighthouse 的 Sean 和 Besu 團隊的 Justin Florentine 都支持在三個測試網之一上評估 blob 到期，然後再在主網上激活 Dencun。Florentine 強調，等待測試網上的 blob 到期也將有助於 Layer-2 滾動協議團隊和應用開發者為 Dencun 升級做準備。Lighthouse 的 Sean 表示，雖然在 Goerli 上觀察 blob 到期並非必要，但這可能是延長 Sepolia 和 Holesky 之間測試期間的一個理由，以便開發人員和 Layer-2 團隊可以在 Sepolia 上經歷完整的 blob 生命周期。關於 Sean 的建議，其他開發人員在會議上並沒有明確的一致意見。

相反，Lightclient 在電話中問開發者是否願意堅持 Beiko 提出的時間表，即在 1 月 30 日升級 Sepolia，然後在 2 月 7 日的一周後升級 Holesky。由於開發者沒有更多的明顯反對意見，Lightclient 表示開發者將堅持原定的時間表。Potuz 在 Zoom 聊天中寫道，他更喜歡在 2 月 7 日一次性升級 Sepolia 和 Holesky 測試網，而不是提前一周升級前者。在電話結束後的 Discord 消息中，Lightclient 再次確認 Dencun 測試網的時間表目前將保持不變。

Prague/Electra

接下來，開發者討論了在 Dencun 之後的下一個升級 Prague/Electra 中應該優先考慮哪些 EIPs。Marius van der Wijden 表示，開發者應該把重心放在 Prague/Electra 中交付 Verkle 樹升級上，而不是其他 EIPs。他對這一觀點提出了兩個注意事項，第一個是 Verkle 的準備情況。正如在 ACDE #177 上討論的那樣，開發者計劃召開專門的 ACDE 電話會議，深入研究 Verkle 的實施細節以及它是否準備好進行硬分叉升級。

van der Wijden 提到的第二個注意事項是在執行層（EL）和共識層（CL）上升級的解耦能力。van der Wijden 提到，共識層中有一些「高優先級、非常緊急」的 EIPs 可能需要比 EL 上的 Verkle 升級更快地實施。他說：「我認為共識層的人討論是否有意義對它們進行硬分叉，以及是否可以在沒有執行層參與的情況下完成，還是是否需要執行層的參與，我們總歸需要進行一個聯合硬分叉，那麼我同意進行一個較小的硬分叉。因此，高優先級肯定是 Verkle，我們應該在這兩個注意事項的基礎上推動它。」

以太坊基金會研究員 Ansgar Dietrichs 在 Zoom 聊天中寫道，他「強烈反對」將重點放在 Prague/Electra 升級的 Verkle 上，因為這可能意味著由於 Verkle 所需的代碼變更的複雜性，升級將延遲到 2025 年。Nethermind 客戶端的開發者 Lukasz Rozmej 也同意 Dietrichs 的觀點。「我的經驗告訴我，狀態重設計非常困難，需要非常長的時間，」Rozmej 說道，他補充說：「雖然我認為 Verkle 很棒，而且它正在取得很大的進展，但我認為如果我們只專注於 Verkle，至少需要一年才能進行下一個硬分叉，甚至更久。因此，我的建議是可能專注於一些較小的硬分叉，而每個團隊都將承諾 Verkle 並分配適當的資源，工作力量，智力，無論您想如何稱呼它，用於這個主題。」

聚焦 Verkle

開發者對於 Prague/Electra 是否應專注於 Verkle 還是優先考慮較小的代碼更改，這些更改可以比 Verkle 更快地發布，存在分歧。Ballet 強調，在他看來，「小分叉」這種說法是不存在的，開發人員在實施 Verkle 之前等待的時間越長，實施以太坊狀態更新就越困難。同樣是 Nethermind 客戶端的開發者 Tomasz K. Stańczak 建議採取雄心勃勃的方法，承諾包含在 Prague/Electra 中可能比實際能夠包含的更多 EIPs。「利用團隊的能力和我們必須展示我們處理最大挑戰的一年。如果到三月份，Verkle 向團隊顯示出越來越多的困難，那麼也許人們會再次質疑並說，『好吧，放棄 Verkle 吧。』但然後我們將擁有一套相當不錯的其他 EIPs，我們將包含在其中，」Stańczak 說道，具體指出了除 Verkle 之外可以包含在 Prague/Electra 中的其他一些重要 EIPs，如與質押、再質押和帳戶抽象相關的 EIPs。

對於 Stańczak 的回應，Lightclient 表示，在承諾了一組 EIPs 之後，開發人員繼續討論應該包含在 Prague/Electra 中的 EIPs 可能會很困難，其中之一，指的是 Verkle，是「一個 18 到 24 個月的項目。」Erigon 客戶端的開發者 Andrew Ashikhmin 支持在 Prague/Electra 分叉中發布較小的 EIPs，並在之後的未來分叉中並行進行 Verkle 的工作。Ballet 支持 Stańczak 的提議，將 Prague/Electra 的重點放在 Verkle 上，並在其實施中發現需要更多時間解決的重大問題時將其從升級中剔除。

專注於僅 CL 的升級

在 EL 和 CL 升級脫鈎的話題上，Potuz 提到，Prague/Electra 只提出了一個 EIP，它僅需要對 CL 進行更改。「唯一的變化 純粹是 CL 的是刪除 attestation index committee。而所有其他的變化，即使那些看起來只是 CL 的變化，比如 Max EB，它們都依賴於其他來自 EL 的變化。所以，我認為純粹的 CL 分叉是不會發生的。至少，我看不到它們在今年和明年會發生。我們沒有足夠的純粹 CL 的提案，」Potuz 說道。

儘管如此，Ansgar Dietrichs 表示，有一些主要是 CL 專注的 EIPs，它們對 EL 需要進行輕微的更改，這些更改可以由 EL 客戶端團隊輕鬆執行。這些 EIPs 仍然需要在 EL 和 CL 之間進行協調的硬分叉。然後，Dietrichs 補充說，在他看來，從 CL 方面來看，數據可用性抽樣（DAS）是 EIP 4844 之後要發布的最重要的代碼更改。Dietrichs 和 Lightclient 對於 DAS 是否需要硬分叉來實施存在一些分歧。

關注 EOF 等 EIP

一位網名為「Rodiazet」的匿名開發人員在以太坊基金會 Ipsilon 團隊工作，該團隊致力於研究以太坊虛擬機（EVM），他贊成在布拉格/Electra 實施 EOF。作為背景，EOF（代表 EVM 對象格式）是對 EVM 的一系列改進，最初考慮包含在 Cancun/Deneb 升級中。請參閱之前的ACDE#158以了解有關 EOF 的更多資訊。

在通話中，除了 Verkle 之外，開發者們提出了一些其他值得考慮的 EIPs，比如 EIP 5920（PAY 操作碼）和 EIP 2537（BLS12-381 曲線操作的預編譯）。Prague/Electra 的 EIP 候選列表可以在以太坊魔法師網站的升級元線程中找到。儘管大多數開發者支持在 Cancun/Deneb 之後以某種方式優先考慮 Verkle，但目前尚不清楚在 Prague/Electra 中應該在多大程度上優先考慮 Verkle，而不是在 2024 年更快、更容易實施的較小 EIPs。Lightclient 強調，在本周的通話中，開發者們不需要就 Prague/Electra 的內容達成最終決定。他建議在即將舉行的 ACD 通話中繼續討論這個話題。

開發者們隨後迅速涉及了 Prague/Electra Meta Thread 上尚未在通話中討論的 EIPs，包括但不限於以下 EIPs：

· EIP-7002：執行層可觸發退出

· EIP-7549：將委員會索引移至認證之外

· EIP-3074：AUTH 和 AUTHCALL 操作碼

· EIP-6110：在鏈上提供驗證者存款

· EIP-6913：SETCODE 指令

· EIP-7377：遷移事務

· EIP-4444：執行客戶端中的綁定歷史數據

· EIP-6404：SSZ 交易 Root 6

· EIP-6465：SSZ 提款 Root 4

· EIP-6466：SSZ 收據 Root 4

· EIP-7212：預編譯 secp256r1 曲線支持

有關上述 EIPs 的詳細概述，請參閱在YouTube上發布的完整通話錄音。

正式化 EIP 7587

最後，以太坊基金會研究員 Carl Beekhuizen 重新提起了有關 EIP 7587 的討論，該 EIP 將為 Layer-2 協議保留一組預編譯地址。關於 EIP 7587 的背景，請參閱先前的通話記錄。Beekhuizen 詢問開發者如何最好地將這個 EIP 正式化為一個資訊性的 EIP，為未來以太坊治理流程創建一個規範。Nethermind 開發者 Ahmad Bitar 建議將該 EIP 包含在 EIP 1 文檔中，該文檔概述了 EIP 過程的指導方針。Lightclient 建議在以太坊魔法師網站上進一步討論這個話題，並在下一次 ACD 通話中根據需要重新討論這個話題。

原文連結