以太坊開發者會議回顧：坎昆升級、硬分叉與布拉格

會議也討論了Dencun 之後的下一個硬分叉升級Prague/Electra 中程式碼變更的優先事項。

撰寫：Christine Kim，Galaxy 研究副總裁

編譯：秦晉，碳鏈價值

2024 年1 月4 日，以太坊開發人員齊聚Zoom for All Core Developers ution (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 的測試網時間表暫時保持不變。

布拉格/伊萊克特拉

接下來，開發人員討論了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 電話會議上根據需要重新討論這個主題。