2024年1月4日，已召開Zoom會議#178，以太坊開發人員聚集在一起進行討論和協調以太坊執行層（EL）變更。他們確認了Cancun/Deneb（Dencun）升級的接下來的三個公共測試網啟動日期，並討論了Dencun之後的下一個硬分叉升級布拉格/Electra中程式碼變更的優先事項。關於硬分叉啟動日期，團隊有不同意見，一些開發者提出需要更多測試時間，有些則認為可以繼續按原計劃進行。對於下一次升級，開發者還討論了默克爾樹升級和其他EIP。以太坊基金會研究員Carl Beekhuizen也重提了EIP 7587的討論。
請為2024年1月4日，以太坊開發人員齊聚Zoom for All Core 開發工程師s Execution (ACDE) Call #178上。 ACDE電話會議通常由以太坊基金會協議負責人Tim Beiko主持，是一個開發人員討論和協調以太坊執行層（EL）變更的雙週系列會議。本週的會議由一位網名為「Lightclient」的匿名Geth EL開發人員主持。開發人員再次確認了Cancun/Deneb（Dencun）升級的接下來的三個公共測試網啟動日期。他們還討論了Dencun 之後的下一個硬分叉升級布拉格/Electra 中程式碼變更（EIP）的優先事項。
鄧存更新
假期期間沒有對Dencun升級進行具體更新。自12月21日上次ACDE電話會議以來，客戶端團隊一直在為Goerli測試網準備新版本。之前由於Prysm導致升級測試延遲，Geth開發者Marius van der Wijden 要求Prysm 用戶端為他們提供新版本的最新進展。 Prysm 開發者Terence Tsao 團隊證實，Prysm 團隊將在下週準備好Goerli 硬分叉的新版本。不過，針對Goerli 的版本將是一個「預發布」版本，這意味著它不會是推薦在以太坊主網上使用的Prysm 版本。在Goerli 硬分叉之後，Prysm 團隊計劃發布另一個版本，其中包含某些更改和更新，推薦用戶在主網上運行，並在Sepolia或Holesky測試網上進行測試。
雖然Tsao 表示Prysm 團隊對Goerli 硬分叉激活日期為1 月17 日感到滿意，正如ACDE #177 上討論的那樣，但他建議在Goerli 硬分叉之後再確定Sepolia 和Holesky 硬分叉激活日期。 ACDE #177以來，以太坊基金會協議支持負責人Tim Beiko已為Goerli、Sepolia和Holesky這三個以太坊公共測試網提出了公共測試網分叉時間。建議的分叉激活時間如下：
格爾利–2024年1月17日–紀元231680–計時器1705473120
Sepolia–2024年1月30日–紀元132608–計時器1706655072
Holesky–2024年2月7日–紀元29696—時間1707305664
Lightclient詢問Prysm以外的其他客戶端是否同意團隊Beiko提出的Goerli硬分叉啟動時間。參加電話會議的所有客戶端團隊（包括Geth、Lodestar、Lighthouse、Teku和Besu）都確認，他們認為時機合適，不錯，最遲下週才能為Goerli節點操作員發布版本。 Lighthouse客戶端團隊指出，如果他們現在正在測試其客戶端的某些網路功能，他們發布的版本可能與Prysm一樣是預發布版本。
Dencun時間軸封閉
對此，Lightclient就Sepolia和Holesky測試網的建議啟動時間展開討論。一位名叫「Potuz」的Prysm開發者（化名）建議在最後兩個測試網的升級日期之前暫時緩和確定主網。不要現在就承諾日期，因為Goerli的事情可能不太順利，從那裡返回了問題。新增一個具有正確紀元的新版本，不做任何排序是很容易的刪除。一個版本並修復錯誤書寫問題。這比幾週的時間要長離婚，」Potuz表示。
Lightclient強調說，客戶端團隊在Goerli硬分叉一周後才需要發布新版本，因此，除非在1月24日或之後在Goerli上發現升級問題，否則不一定要刪除新版本。 Geth開發者Marius van der Wijden表示，他認為Sepolia和Holesky測試網設定的日期並沒有什麼壞處，因為如果Goerli上出現問題，開發者可以隨時更改日期。
以太坊基金會DevOps工程師巴納巴斯-布薩（Barnabas Busa）在Zoom聊天室中承認，在他看來，只有在確認Goerli的版本正常運作後，才需要為Sepolia和Holesky的升級發布新版本。一位名叫「Sean」的Lighthouse開發者同意這個觀點，他說開發者可以為Sepolia硬分叉設定一個「暫定」日期，但在1月30日之前應該先看看格爾利的進展情況。
Potuz在建議Goerli和Sepolia硬分叉活化之間增加一周的測試時間，基本上用一周的時間進行分析，而不是三週。他說，增加一週的測試時間可以讓客戶端發行版「浸泡」幾下天，然後客戶端團隊才需要為下一次測試網升級再次切割新版本。 「這個時間太近了。這就是我要指出的問題。」Potuz 補充說，如果Goerli 用戶端發行版得到了充分的分析和測試，那麼在Sepolia和Holesky硬分叉激活之間可能需要三週的轉時間。
Potuz的觀點引發了爭議。以太坊基金會的安斯加-迪特里希斯（Ansgar Dietrichs）稱，升級的第一個公共測試網激活與升級的主網激活之間的時間通常是開發者的“最初時間”，不需要延長。不過，Dietrichs 也指出，對於延長測試網升級間隔時間的願望，開發者應該在硬分叉背景下更認真地討論，而不僅僅是Dencun 升級。 Dietrichs 說： “如果有人希望有一個更深入的過程，那麼我們應該在有時間的時候討論這個問題，而不是在硬分叉之前。”
Lightclient同意Dietrichs的觀點，認為如果早在10月就進行討論，開發者很可能會對延長Dencun的測試網時間表更加寬鬆。 Lightclient說：我認為還有一部分原因是，我們想在去年秋天完成升級，所以現在我們真的在努力實現這個目標，我認為我們的時間表安排應該更積極一些。
堅持積極的時間表
根據開發者在電話會議上分享的觀點，以太坊基金會DevOps工程師Parithosh Jayanthi建議將Sepolia硬分叉升級推遲一周左右，把Sepolia硬分叉的日期定在Goerli升級之後的1月25日ACDE電話會議上。 Marius van der Wijden反對完全依賴ACDE電話來重新討論測試網升級啟動的日期。他說：「我真的希望避免的是，我們不得不再打一次所有核心開發人員電話來確認日期，」他補充道：我討厭再打一次所有核心開發者的電話，只是為了說「好把，Sepolia 現在可以開始了。」而現在我們必須等待一個星期，才可以真正開始實現Sepolia。
為了安撫大家的情緒，Geth開發者Guillaume Ballet建議為Sepolia硬分叉創建兩套暫定日期，如果Goerli硬分叉的結果是積極的，開發者堅持可以使用其中一套日期；如果Goerli硬分叉叉的結果是負面的，開發者可以使用另一套日期。然而，Lightclient和Dietrichs都反對這個想法，因為在開發者為Sepolia硬分叉設定新的時間表之前，必須先對Goerli上的錯誤和問題的性質進行評估。
順便說一句，以太坊基金會測試團隊的一位網名叫“Danceratopz”的化名開發者詢問，開發者是否想等評估完Goerli測試網絡上的blob過渡問題之後升級Sepolia。作為背景知識，blob中期指的是大約在周三後從以太坊狀態中刪除blob資料。
來自Lighthouse的Sean和Besu團隊的Justin Florentine都贊成在主網啟動Dencun之前，先在三個測試網上評估blob的情況。 Florentine強調說，在測試網上等待blob也將有利於第一個二層Rollup協議團隊和應用開發人員為Dencun升級做好準備。來自Lighthouse的Sean表示，雖然在Goerli上觀察blob並不是必需的，但這可能是延長Sepolia和Holesky之間測試期的一個原因，這樣開發人員和第二層團隊就可以在Sepolia上經歷整個blob生命週期。電話會議上，其他開發人員沒有明確同意Sean的建議。
相反，Lightclient在會議上詢問開發人員是否願意堅持Beiko提出的時間表，即1月30日昇級Sepolia，一周電話後的2月7日昇級Holesky。由於開發人員沒有更多不同的意見，Lightclient表示開發人員將再次堅持原來的時間表。 Potuz 在Zoom 聊天中寫道，他希望在2 月7 日同時升級Sepolia 和Holesky 測試網，而不是提前一周升級之前。在通話後的Discord 訊息中，Lightclient 確認Dencun的網路測試時間表暫時保持不變。
布拉格/伊萊克特拉
接下來，開發人員討論了Dencun之後的下一次升級（布拉格/埃萊克特拉）應優先哪些EIP。 Marius van der Wijden說，開發人員應集中精力完成布拉格/埃萊克特拉的默克爾樹升級，而不是其他EIP他對這一觀點補充了兩點注意事項，首先是默克爾樹的準備情況。如同在ACDE #177 上所討論的，開發人員計劃召開專門一次的ACDE 電話會議，深入探討默克爾樹的實施細節及其硬分叉升級的準備情況。
范德韋登提到的第二個事項注意EL上的升級與腦層（CL）解耦的能力。范德韋登提到的，CL上有一些「高優先級、超級緊急」的EIP，可能需要比EL上的默克爾樹升級更快實施。 「我認為重要的是，磋商層人員要討論他們是否有必要對這些[紧急]變更進行硬分叉，是否可以在沒有EL參與的情況下完成，或者是否需要EL參與，而我們無論如何都需要進行聯合硬分叉，然後我可以接受一個較小的硬分叉」。van der Wijden 說：「所以，梅克爾樹絕對是重中之重，我們應該考慮到這一點的情況來推動它。 」
以太坊基金會研究員安斯加-迪特里希斯（Ansgar Dietrichs）在Zoom聊天室中寫道，他“強烈反對”將布拉格/伊萊克特拉升級重點放在默克爾樹上，因為考慮到梅克爾樹所需的程式碼變更的複雜性，這很可能意味著升級要推遲到2025年。 Nethermind客戶端開發人員Lukasz Rozmej也同意Dietrichs的觀點。 Rozmej說：「我的經驗告訴我，狀態的重新設計是非常困難的，而且需要非常長的時間，」他補充說，「雖然我認為默克爾樹非常好，而且正在取得巨大進步，但我認為我們如果只關注默克爾，下一次硬分叉至少需要一年甚至更長的建議的時間。 因此，我的可能會專注於一些較小的硬分叉，同時每個團隊都會致力於默克爾，並為這個主題分配適當的資源、工作量、腦力，無論你怎麼稱呼它。”
聚焦梅克爾
對於Prague/Electra來說，應該優先考慮梅克爾還是比梅克爾更快發布較小的程式碼變更，開發人員意見不一。 Ballet強調，在他看來，“存在不小分叉”，開發者在實施默克爾之前等待的時間越長，實施以太坊狀態更新的難度就越大。 Tomasz K. Stańczak也是Nethermind客戶端的開發者，他建議採取一種雄心勃勃的方法，承諾採用比布拉格/伊萊克特拉可能包含更多的EIP。[让我们]再次利用團隊的能力，在這一年裡，我們必須證明我們能夠應對最大的挑戰。如果梅克爾最終向團隊表明，到了3月份已經越來越多困難了，那麼人們可能會提出疑問，並說「好吧，梅克爾下課」。但我們會繼續使用包括在內的一套相當不錯的其他EIP，Stańczak說道，他指定除默克爾之外，布拉格/電力還可能包括的其他一些重要的EIP，如與質押、重新質押與帳戶抽象相關的EIP。
Lightclien在回答Stańczak的問題時說，開發人員在承諾採用一套EIP之後，可能很難繼續討論Prague/Electra中應該包括哪些EIP，而其中一個EIP（指默克爾）是“一個需要18到24 「 Erigon客戶端的開發者安德魯-阿西克明（Andrew Ashikhmin）贊成在布布拉格/伊萊克特拉分叉中發布較小的EIP，並同時開發默克爾，以便在之後的分叉中使用芭蕾舞贊成斯坦恰克的建議，即在布拉格/伊萊克特拉中重點開發默克爾，如果發現其實施過程中存在重大問題，需要更多時間來解決，則將其從升級中刪除。
聚焦CL升級
關於將EL（執行層）和CL（頭腦層）升級解耦的問題，Potuz提到，Prague/Electra只有一個EIP提議只需要對CL進行更改。 「唯一的變化是取消了認證索引委員會… …以及所有其他變化，即使是那些看起來只涉及CL 的變化，如Max EB，也取決於EL 的其他變化。因此，我認為純粹的CL 分叉是不會發生的。至少，我認為今年不會，明年也不會。我們沒有足夠的純CL提案，」波圖茲說。
不過，Ansgar Dietrichs 還是說，有些EIP 主要以CL 為中心的升級，只需要對EL 稍作佈局，EL 用戶端團隊就可以輕鬆執行。這些EIP 還是需要EL 和CL 硬協調分叉。 Dietrichs 也補充說，他認為從CL方面來看，資料可用性取樣（DAS）是EIP 4844之後最重要的程式碼變更。 Dietrichs和Lightclient就DAS是否需要硬分叉來實現存在一些叢集。
關注EOF和其他EIP
一個網名為「Rodiazet」的化名開發者在以太坊基金會的Ipsilon 團隊工作，該團隊致力於以太坊虛擬機器（EVM）的研究。背景作為，EOF 是EVM Object Format 的縮寫，是EVM的一系列改進，最初被考慮納入Cancun/Deneb升級。
梅克爾外，開發人員也提出了一些其他EIP供考慮，例如EIP 5920（PAY操作碼）和EIP 2537（BLS12-381曲線操作的預編譯）。 Prague/Electra候選EIP的完整清單可以在除以太坊魔術師網站上的升級元線程中找到。雖然大多數開發者都支持在Cancun/Deneb會議之後在某種程度上優先考慮默克爾，但目前還在十字軍在大規模編程中默克爾應被優先考慮對於Prague/Electra，而不是那些在2024年可以更快、更容易實現的小型EIP。 Lightclient強調，開發人員在本週的電話會議上就Prague/Electra的內容做出最終決定。即將舉行的ACDE電話會議上繼續討論該主題。
研究人員很快就談到了Prague/Electra主題中尚未在通話中討論的EIP，包括但不限於以下EIP：
EIP-7002：執行層可觸發退出
EIP-7549：將委員會指標移至認證之外
EIP-3074：AUTH和AUTHCALL操作碼
EIP-6110：在鏈上提供驗證器存款
EIP-6913：SETCODE 指令
EIP-7377：遷移事務
EIP-4444：執行客戶端中的綁定歷史數據
EIP-6404：SSZ交易根
EIP-6465：SSZ提取根
EIP-6466：SSZ 收據根
EIP-7212：預編譯secp256r1的圓形支持
上述EIP 觀點的詳細概述，請參閱YouTube 上發布的完整通話錄音。
正式確定EIP 7587
最後，以太坊基金會研究員Carl Beekhuizen重提了有關EIP 7587的討論，該討論將保留一組預編譯位址，供第二層協議使用。 Beekhuizen詢問開發人員如何最好地暗示EIP正式化，使其成為一個資訊性的EIP，為未來的以太坊治理流程創建規範。 Nethermind開發者Ahmad Bitar建議將EIP納入EIP 1文件，該文件概述了EIP流程的指導方針。 Lightclient建議在以太坊魔術師網站上進一步討論這個主題，並在下一次ACDE電話會議上根據需要重新討論這個主題。
資訊來源：0x資訊編譯自網際網路。版權歸作者Christine Kim所有，未經許可，不得轉載！