原文標題：《Ethereum All Core Developers Execution Call #178 Writeup》
原文作者：Christine Kim
原文編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論並協調對以太坊執行層（EL）的變更。本次為ACDE 第178 次電話會議，本次會議重新確認Goerli 測試網上坎昆升級時間為1 月17 日，並將1 月30 日和2 月7 日分別作為Sepolia 測試網升級和Holesky 測試網升級日期。若一切順利，開發者將於下週發布Goerli 用戶端，如果分叉後前24 小時內出現問題，將重新規劃升級時間。
此外，會議討論了Cancun/Deneb（Dencun）升級的公共測試網啟動日期，並重申了硬分叉升級Prague/Electra 的EIPs 的優先順序。開發者們對於Verkle 樹升級在Prague/Electra 中的重要性進行了討論，並就EIP 7587 如何被形式化為資訊性EIP 以規範未來以太坊治理過程提出了建議。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：
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 通話中根據需要重新討論這個主題。
