以太坊所有核心開發者協商電話（ACDE）第178次電話會議中確認了Goerli測試網升級時間為1月17日，同時討論了Sepolia測試網升級以及Holesky測試網升級的日期。他們計劃在Goerli客戶端發布後進行分叉，但如果24小時內出現問題，將重新規劃升級時間。會議還討論了Cancun/Deneb升級的公共測試網啟動日期，並優先考慮了硬分叉升級布拉格/伊萊克特拉的EIP的優先順序。開發者也討論了Verkle樹升級的重要性，並提出了關於EIP 7587如何被形態化為資訊性EIP的建議。開發者在時間表上持續溝通並討論各種升級及硬分叉的實施日期。
原文標題：《以太坊所有核心開發人員執行呼叫#178 Writeup》
譯者：Christine Kim
編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者協商電話（ACDE）每週四召開一次，主要討論和協調以太坊執行層（EL）的變更。本次為ACDE第178次電話會議，次本會議重新確認Goerli測試網上坎昆升級時間為1月17日，並分別為1月30日及2月7日分別作為Sepolia測試網升級和Holesky測試網升級日期。若一切順利，開發者將於下週發布Goerli客戶端，如果分叉後前24小時內出現問題，將重新規劃升級時間。
此外，會議討論了Cancun/Deneb（Dencun）升級的公共測試網激活日期，並優先考慮了對硬分叉升級布拉格/伊萊克特拉的EIP的優先級。開發者對於Verkle樹升級在布拉格/伊萊克特拉中的重要性性進行了討論，並就EIP 7587 如何被形態化為資訊性EIP 以規範未來以太坊治理過程提出了建議。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將編譯如下：
2024年1月4日，以太坊開發人員齊聚Zoom參加了All Core 開發工程師s Execution (ACDE) call #178會議。 ACDC電話會議是一個每週舉行一次的系列會議，通常由以太坊基金會協議支持主管Tim Beiko 主持，開發人員在會上討論和協調對以太坊層執行（EL）的更改。本週，電話會議由一個名為「Lightclient」的Geth EL 開發人員主持。開發人員確認了坎昆/ Deneb（Dencun）升級的下三個公共測試網啟動日期，並討論了Dencun 接下來的下一個硬分叉升級布拉格/Electra 的程式碼更改優先權，這些變更通常被稱為以太改進坊提議（EIPs）。本次會議是開發者討論和協調對以太坊執行層（EL）的更改的系列會議之一。
鄧存更新
在假期期間，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的情況不太好，而後退是一個問題。添加一個標記的正確紀元但沒有更改的新版本很容易。刪除一個版本並修復錯誤是一個難題。這要花費多於幾週的時間，」波圖茲說。
Lightclient 強調，客戶端團隊在Goerli 硬分叉之後一周內不必發布新版本，因此，除非在1 月24 日或發現了與升級相關的問題，否則可能不一定刪除版本。 Geth 開發人員Marius van der Wijden表示，目前開發人員隨時可以更改它們，他認為在Sepolia 和Holesky 測試網路上設定的日期不會有任何問題，即使Goerli 出現問題。
以太坊基金會DevOps 工程師Barnabas Busa 在Zoom 聊天中寫道，在他看來，確認Goerli 版本正常運作後，才對Sepolia 和Holesky 升級切割新版本有意義。 Sean”，表示開發人員可以為Sepolia 硬分叉設定一個“暫定”日期，但應在確認Goerli 版本正常運行後再決定是否繼續1 月30 日的計劃。
Potuz 建議在Goerli 和Sepolia 硬分叉活化之間增加一周的測試時間，而不是基本上是一周的分析時間，是三週。他說，額外的一周測試時間將為客戶端提供時間，讓其在客戶端團隊需要再次為下一個測試網升級切割新版本之前「浸泡」幾天。 「這太緊張了。這是我指出的問題，」Potuz 說，並補充說，如果Goerli 用戶端版本經過充分的分析和測試，那麼在Sepolia和Holesky硬分叉激活之間可能需要三週的轉時間。
Potuz的觀點引起了爭議。以太坊基金會的Ansgar Dietrichs稱升級的第一個公共測試網激活和主網激活之間的時間通常是開發人員不需要延長的「死亡時間」。不過，Dietrichs也指出，在測試網升級之間延長時間的願望是開發人員應該在分叉的整體背景下更認真討論的問題，而不僅僅是在Dencun升級中。 「如果有延長過程硬的願望，那麼我們可能應該在有時間的時候進行討論，而不是在硬分叉之前，」Dietrichs 說。
Lightclient同意Dietrichs的觀點，表示如果在例如十月早些時候進行討論，開發人員可能會更願意延長Decun測試網的時間。 “我認為其中的一部分原因是我們在去年秋天發布了這個升級，所以現在我們真的在努力實現它，我認為我們制定了一些更加積極的時間表，”Lightclient 說。
堅持積極的時間表
根據開發人員在會議上分享的觀點，以太坊基金會DevOps工程師Parithosh Jayanthi建議將Sepolia硬分叉升級推遲一周左右，並在1月25日的ACD會議上為Sepolia硬分叉設定一個日期，該日期在Goerli 升級後。 Marius van der Wijden 反對補充依賴ACD 會議重新討論測試網升級啟動日期。 「我真的不希望我們必須去另一個所有核心開發人員來確認日期，」他說，並補充說：「我不想再參加另一個所有核心開發會議只是為了說，『很好，Sepolia 現在可以進行。’然後我們必須等待幾分鐘才能真正進行Sepolia。」
嘗試安撫部分，Geth 開發者Guillaume Ballet 建議為Sepolia 硬分叉創建暫定日期，一組是在Goerli 硬分叉的結果積極的情況下開發者堅持使用的，另一組是在Goerli 硬分叉分叉的結果為負的情況下開發者回退使用的。然而，Lightclient 和Dietrichs 都反對這個想法，因為在開發人員實際上可以為Sepolia 硬分叉設定新的時間表之前，必須先評估Goerli 上的錯誤和問題的性質。
順便說一句，以太坊基金會測試團隊的一位化名開發者，螢幕名為“Danceratopz”，詢問開發者是否希望等待在升級Sepolia之前在Goerli測試網上評估blob方向。背景是，blob方向是指在大約兩週的時間後從以太坊狀態中刪除blob資料。有關blob和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測試網的時間表目前將保持不變。
布拉格/伊萊克特拉
接下來，開發者在Dencun 討論了接下來的一個考慮升級布拉格/Electra 中應該優先哪些EIP。 Marius van der Wijden 表示，開發者應該把重心放在布拉格/Electra 中交付Verkle 樹升級上，而不是其他EIPs。他對這個觀點提出了兩個注意事項，第一個是Verkle 的準備。正如在ACDE #177 上討論的那樣，開發者計劃召開專門的ACDE 電話會議，深入研究Verkle 的實施以及細節它是否準備好進行硬分叉升級。
范德韋登提到的第二個注意是在執行層（EL）和預警層（CL）上升級的解耦能力。范德韋登提到的，預警層中有一些「高優先級、非常緊急」的EIP 可能需要比EL 上的Verkle 升級更快地實施。他說：「我思考層的人討論是否對他們有意義進行硬分叉，以及是否可以在沒有執行層參與的情況下完成，或者是否需要執行層的參與，我們總歸需要進行一個聯合硬分叉，那麼我同意進行一個更嚴重的硬分叉。因此，高優先級肯定是Verkle，我們應該在這兩個注意事項的基礎上推動是它。”
以太坊基金會研究員Ansgar Dietrichs 在Zoom 聊天中寫道，他「強烈反對」將重點放在布拉格/Electra 升級的Verkle 上，這可能意味著因為Verkle 所需的程式碼變更的複雜性，升級將會延遲到2025 年。 Nethermind 用戶端的開發者Lukasz Rozmej 也同意Dietrichs 的觀點。 「我的經驗告訴我，狀態重新設計非常困難，需要非常長的時間，」Rozmej 說道，認為他補充說：「雖然我Verkle 很好，而且它正在取得很大的進展，但我認為如果我們只專注於Verkle，至少需要一年才能進行下一個硬分叉，甚至更久。因此，我的建議可能是專注於一些較小的硬分叉，而每個團隊都將承諾Verkle 並分配適當的資源、工作力量、能力，無論您想如何應對它，用於這個主題。”
聚焦韋爾克爾
對於布拉格/伊萊克特拉的開發者是否應該考慮Verkle還是優先考慮較小的程式碼更改，這些更改可以比Verkle更快地發布，存在關閉。 Ballet強調，在他看來，「小分叉」這種說法是不存在的，開發人員在實施Verkle之前等待的時間越長，實施以太坊狀態更新難度。同樣是Nethermind客戶端的開發者Tomasz K. Stańczak建議採取雄心勃勃的方法，承諾包含在Prague/Electra中可能實際上再次能夠包含更多的EIP。 「利用團隊的能力和我們必須展示我們處理今年最大的挑戰。如果到了三月份，Verkle 向團隊展示出越來越多的困難，那麼也許人們會質疑並說，『好吧，放棄Verkle 吧。』但然後我們將擁有一套相當不錯的其他EIP，我們將包含在其中，」Stańczak 說道，具體指出了除Verkle 之外可以包含在布拉格/伊萊克特拉中的其他一些重要的EIP，如與質押、再質押和帳戶抽象相關的EIP。
對於Stańczak 的回應，Lightclient 表示，在承諾了一組EIP 之後，開發人員繼續討論應該包含在布拉格/Electra 中的EIP 可能會很困難，其中之一，指Verkle，是「一個18 到24 個」月的項目。 「Erigon客戶端的開發者Andrew Ashikhmin支持在Prague/Electra分叉中發布更小的EIP，並在之後的未來分叉中玩具進行Verkle的工作。Ballet支持Stańczak的提議，將Prague/Electra的重點放在Verkle上，並在其實施中發現需要更多時間解決的重大問題時將其從升級中剔除。
專注於CL 的升級
在EL 和CL 升級脫鉤的話題上，Potuz 提到，Prague/Electra 只提出了一個EIP，它只需要對CL 進行更改。 「唯一的變化純粹是CL 是刪除證明索引委員會。而所有其他的變化，即使那些看起來只是CL 的變化，比如Max EB，它們都依賴於其他來自EL 的變化。所以，我認為純粹的CL 分叉是不會發生的。至少，我今年和明年看不到它們會發生。我們沒有足夠的純粹CL的提議，」Potuz說。
儘管如此，Ansgar Dietrichs 表示，有一些主要是CL 關注的EIP，它們對EL 需要進行一些更改，這些更改可以由EL 用戶端輕鬆團隊執行。這些EIP 仍然需要在EL 和CL 之間進行協調的硬性分叉。然後，Dietrichs 補充說，在他看來，從CL 方面來看，資料可用性（DAS）是EIP 4844 之後要發布的最重要的程式碼變更。 Dietrichs 和Lightclient for DAS 是否需要硬分叉來實施存在一些封閉。
關注EOF 等EIP
一位網名叫「Rodiazet」的匿名開發人員在以太基金會Ipsilon 團隊工作，該團隊致力於研究以太坊虛擬機（EVM 坊），他贊成在布拉格/Electra 實施EOF。作為背景，EOF（代表EVM）物件格式）是針對EVM 的一系列改進，最初考慮包含在Cancun/Deneb 升級中。請參閱前面的ACDE#158 以了解有關EOF 的更多資訊。
在普通中，除了Verkle 之外，開發者們提出了一些其他值得考慮的EIP，例如EIP 5920（PAY 操作碼）和EIP 2537（BLS12-381 曲線操作的預編譯）。 Prague/Electra 的EIP 候選清單可以在以太坊魔法師網站的升級元線程中找到。雖然大多數開發者支援在Cancun/Deneb 之後以某種方式優先考慮Verkle，但目前尚在布拉格/Electra 中應該在數位程式設計優先考慮Verkle，而不是在2024 年更快、更容易實施更小的EIP 。 Lightclient 強調，在本週的通話中，開發者需要就布拉格/Electra 的內容達成最終決定。他建議在即將舉行的ACD 中通話中繼續討論這個主題。
開發者們迅速涉及了布拉格/Electra Meta Thread上尚未在通話中討論的EIP，包括但不限於以下EIP：
· EIP-7002：執行層可觸發退出
· EIP-7549：將委員會指標移至認證之外
· EIP-3074：AUTH 和AUTHCALL 操作碼
· EIP-6110：在鏈上提供驗證者存款
· EIP-6913：SETCODE 指令
· EIP-7377：遷移事務
· EIP-4444：執行客戶端中的綁定歷史數據
· EIP-6404：SSZ交易根6
· EIP-6465：SSZ提款Root 4
· EIP-6466：SSZ 收據根 4
· EIP-7212：預編譯secp256r1 橢圓形支持
有關EIP 的詳細概述，請參閱YouTube 上發布的完整通話錄音。
正式化EIP 7587
最後，以太坊基金會研究員Carl Beekhuizen 重新提起了有關EIP 7587 的討論，該EIP 將Layer-2 協議保留一組預編譯位址。關於EIP 7587 的背景，請參閱先前的通話記錄。 Beekhuizen 詢問開發者如何最好地將這個EIP 正式化為一個資訊性的EIP，為未來的以太坊治理流程創造一個規範。 Nethermind 開發者Ahmad Bitar 建議將EIP 納入EIP 1 文件中，該文件概述了EIP 流程的指導原則。 Lightclient建議在以太坊魔法師網站上進一步討論這個主題，並在下一次ACD通話中根據需要重新討論這個主題。
資訊來源：0x資訊編譯自網際網路。版權歸作者區塊律動BlockBeats所有，未經許可，不得轉載！