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

撰文：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 電話會議上根據需要重新討論這個話題。