作者：Christine Kim Galaxy研究副總裁；編譯：秦晉碳鏈價值
2024年1月4日，以太坊開發人員齊聚Zoom for All Core Developers Execution (ACDE) Call #178 上。 ACDE電話會議通常由以太坊基金會協議負責人Tim Beiko主持，是一個開發人員討論和協調以太坊執行層（EL）變更的雙週系列會議。本週的會議由一位網名為「Lightclient」的匿名Geth EL開發人員主持。開發人員再次確認了Cancun/Deneb（Dencun）升級的接下來三個公共測試網啟動日期。他們也討論了Dencun之後的下一個硬分叉升級Prague/Electra中程式碼變更（EIPs）的優先事項。
Dencun更新
假期期間沒有對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 這三個以太坊公共測試網提出了公共測試網分叉時間。建議的分叉激活時間如下：
Goerli–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日之前應該先看看Goerli的進展情況。
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電話來重新討論測試網升級啟動的日期。他說：「我真正希望避免的是，我們不得不再打一次All Core Devs電話來確認日期，」他補充說：我討厭再打一次All Core Devs電話，只是為了說「好把，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的測試網時間表暫時保持不變。
Prague/Electra
接下來，開發人員討論了Dencun之後的下一次升級（Prague/Electra）應優先考慮哪些EIP。 Marius van der Wijden說，開發人員應集中精力完成Prague/Electra的默克爾樹升級，而不是其他EIP。他對這一觀點補充了兩點注意事項，首先是梅克爾樹的準備。如同在ACDE #177上所討論的，開發人員正計劃召開一次專門的ACDE電話會議，深入探討默克爾樹的實施細節及其硬分叉升級的準備情況。
Van der Wijden提到的第二個注意事項是將EL上的升級與共識層（CL）解耦的能力。 Van der Wijden 提到，CL上有一些「高優先級、超級緊急」的EIP，可能需要比EL上的默克爾樹升級更快實施。 「我認為重要的是，共識層人員要討論他們是否有必要對這些[紧急]變更進行硬分叉，是否可以在沒有EL參與的情況下完成，或者是否需要EL 參與，而我們無論如何都需要進行聯合硬分叉，然後我可以接受一個較小的硬分叉」。 van der Wijden 說：「所以，默克爾樹絕對是重中之重，我們應該在考慮到這兩點的情況下推動它。」
以太坊基金會研究員安斯加-迪特里希斯（Ansgar Dietrichs）在Zoom 聊天室中寫道，他“強烈反對”將Prague/Electra升級重點放在默克爾樹上，因為考慮到默克爾樹所需的程式碼變更的複雜性，這很可能意味著升級要推遲到2025年。 Nethermind客戶端開發人員Lukasz Rozmej也同意Dietrichs的觀點。 Rozmej說：「我的經驗告訴我，狀態的重新設計是非常困難的，而且需要非常長的時間，」他補充說，「雖然我認為梅克爾樹非常好，而且正在取得巨大進步，但我認為如果我們只專注於默克爾，下一次硬分叉至少需要一年甚至更長的時間。因此，我的建議是，可能會專注於一些較小的硬分叉，同時每個團隊都會致力於梅克爾，並為這個主題分配適當的資源、工作量、腦力，無論你怎麼稱呼它。」
聚焦梅克爾
對於Prague/Electra應專注於梅克爾還是優先考慮比梅克爾更快發布的較小程式碼變更，開發人員意見不一。 Ballet強調，在他看來，「不存在小分叉」，開發者在實施默克爾之前等待的時間越長，實施以太坊狀態更新的難度就越大。 Tomasz K. Stańczak也是Nethermind客戶端的開發者，他建議採取一種雄心勃勃的方法，承諾採用比Prague/Electra可能包含的更多的EIP。[让我们]利用團隊的能力，在這一年裡，我們必須證明我們能夠應對最大的挑戰。如果梅克爾最終向團隊表明，到3月有越來越多困難堆積起來，那麼人們可能會再次提出疑問，並說「好吧，梅克爾下課」。但我們會繼續使用我們將包括在內的一套相當不錯的其他EIP，Stańczak說道，他指定除默克爾之外，Prague/Electr還可能包括的其他一些重要EIP，如與質押、重新質押與帳戶抽象相關的EIP。
Lightclien在回答Stańczak的問題時說，開發人員在承諾採用一套EIP之後，可能很難繼續討論Prague/Electra中應該包括哪些EIP，而其中一個EIP（指默克爾）是“一個需要18到24個月的項目」。 Erigon客戶端的開發者安德魯-阿西克明（Andrew Ashikhmin）贊成在布Prague/Electra分叉中發布較小的EIP，並同時開發默克爾，以便在之後的分叉中使用。 Ballet贊成Stańczak的建議，即在Prague/Electra 中重點開發默克爾，如果發現其實施過程中存在重大問題，需要更多時間來解決，則將其從升級中刪除。
聚焦CL升級
關於將EL(執行層)和CL（共識層）升級解耦的問題，Potuz提到，Prague/Electra只有一個EIP提議只需要對CL進行更改。 「唯一的變化是取消了認證索引委員會……以及所有其他變化，即使是那些看起來只涉及CL的變化，如Max EB，也取決於EL的其他變化。因此，我認為純粹的CL分叉是不會發生的。至少，我認為今年不會，明年也不會。我們沒有足夠的純CL提案，」Potuz說。
儘管如此，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電話會議上根據需要重新討論這個主題。