作者：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升級進行具體更新。自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一樣是預發布版本。
隨后，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的測試網時間表暫時保持不變。
接下來，開發人員討論了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 中重點開發默克爾，如果發現其實施過程中存在重大問題，需要更多時間來解決，則將其從升級中刪除。
關于將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是否需要硬分叉來實現存在一些分歧。
一位網名為「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上發布的完整通話錄音。
最后，以太坊基金會研究員Carl Beekhuizen重提了有關EIP 7587的討論，該討論將保留一組預編譯地址，供第二層協議使用。Beekhuizen 詢問開發人員如何才能最好地將EIP正式化，使其成為一個信息性的 EIP，為今后的以太坊治理流程創建規范。Nethermind開發者Ahmad Bitar建議將EIP納入EIP 1文件，該文件概述了EIP流程的指導方針。Lightclient建議在以太坊魔術師網站上進一步討論這個話題，并在下一次ACDE電話會議上根據需要重新討論這個話題。
喜來順財經
