以太坊核心開發者最新會議摘要：Dencun升級最終進度及Pectra 升級範圍討論

編譯：Luccy，BlockBeats

以太坊核心開發者共識電話（ACDC）定期舉行，旨在討論和協調對以太坊共識層（CL）的調整。最近一次ACDC電話會議為第129次，開發人員分享了有關Dencun升級準備工作的最新進展，並就下一次以太坊升級Pectra的範圍和EIP進行了討論。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2024 年3 月7 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Consensus (ACDC) call #129 會議。 ACDC 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會議上討論和協調對以太坊共識層（CL）的更改。本週，開發人員分享了有關 Dencun 升級準備的最後更新，該升級計劃於 3 月 13 日星期三在主網上啟動。他們還討論了下一次以太坊升級 Pectra 的範圍，以及一些研究主題，其中之一是 CL 用戶端之間的區塊值標準化。

Deneb

Ryan reminded everyone at the start of the conference call that the Dencun upgrade would go live on Ethereum in less than a week. He also mentioned that for many Americans, it would begin week. He also mentioned that for many Americans, it would begin eek. weekend on March 10th, with the start of DST. Given that all ACD conference calls and upgrades are scheduled based on Coordinated Universal Time (UTC) without observing DST, developers and call participants outside the U.S.developers and call participants outside the U.S.

#在電話會議中，一些客戶端團隊透露他們計劃在未來幾天內發佈軟體的更新版本，以配合Dencun 升級。預計 Prysm、Lighthouse 和 Teku 團隊將在本週末之前發布新版本。儘管這些更新版本並非強制升級，但以太坊基金會的 Tim Beiko 在 Zoom 會議中指出，他們不會更新匯總所有與 Dencun 相容版本的部落格文章。

Flashbots 團隊的 Chris Hager 分享了關於 MEV-Boost 軟體準備的快速更新。 Hager 確認，上週發布的 MEV-Boost 版本 1.7 是穩定的，驗證節點操作員可以使用。他說，為 Deneb 準備的 Flashbots 建構器軟體仍在開發中，預計將在本週的某個時候完成並合併。關於驗證器為升級做好準備的情況，Hager 表示擔心似乎還沒有足夠的驗證器更新了他們的 MEV-Boost 軟體以適應 Dencun 升級。在仔細核對他的數據後，Hager 說，大約 50% 連接到 Flashbots 中繼的驗證器正在使用最新的 MEV-Boost 版本，即 v1.7。

Beiko 進一步指出，他的消息來源 Metrika 和 Ethernets 顯示，大約一半的以太坊節點已經準備好升級至 Dencun。他也表示希望能有一個數據工具，可以追蹤驗證節點升級準備情況，而不僅限於所有以太坊節點。

Electra

以太坊開發人員討論了與 Pectra 升級相關的四項程式碼變更。

EIP 7459

第一個是以太坊改進提案 (EIP) 7549，它使 CL 用戶端能夠更有效地聚合區塊的投票（也稱為證明）。開發人員同意先前的建議，將 EIP 7549 納入 Pectra。 Teku 開發人員 Mikhail Kalinin 分享瞭如何在以太坊上實施 EIP 7549 的進一步分析，並提出了一些因程式碼變更而可能引入的權衡或「負面影響」。 Ryan 建議 Kalinin 直接在 GitHub 上總結他對 CL 規範提出的更改，以供進一步回饋和審查。

Prysm 開發人員 Terence Tsao 表示，他同意 Kalinin 提出的 EIP 7549 實作方案，但建議為 Beacon API 變更提供進一步的文件和規範，這與此 EIP 是必要的。 「如今，如果同一個槽中有10 個聚合器，則需要簽署10 個證明，然後透過此更改，您只需發送一條訊息，因此，您可能需要進行一些Beacon API 更改，」Tsao 說道，並補充道，「我認為這部分可能需要更多地思考如何改變Beacon API 驗證器整合來解決這個問題。」作為背景，Beacon API 是CL 的規範，使節點能夠查詢網路並獲取有關網路狀態的資訊。

降低發行量

然後，EF 研究員 Ansgar Dietrichs 分享了他關於透過降低網路發行量來減少質押獎勵的提案的快速更新。他表示，自上次 ACDC 電話會議提出該提案以來，「社區的回饋意見不一」。他重申，該提案將是一個小的代碼更改，假設主網在 10 月進行硬分叉，在 6 月或 7 月之前可能會在最後一刻包含在 Electra 升級中。然而，Dietrichs 也表示，對話是「正在進行的」，這意味著在做出決定之前需要對這個想法進行進一步討論。

EIP 7547

第三，EF 研究員 Mike Neuder 提出了 EIP 7547，包含列表，以供進一步討論。他表示，討論 EIP 設計的「確切特徵」的第二次分組會議將會很有用，他正在考慮在下週五（即 3 月 15 日）組織一次分組會議。他還提到，EIP 有一個專門的 Discord 頻道，名為“包含列表”，有興趣了解更多有關提案或提出問題的人應該使用。 Tsao 還表示，自 2 月 16 日第一次包含清單分組會議以來，該提案的規範已基本充實。 Tsao 表示：「我認為該規範可能已完成 75% 左右。」他補充說，規範中還有一些其他元件需要改進，例如執行 API 的更改和有關誠實驗證器的規範。

EIP 7251

最後，Lighthouse 開發者 Mark Mackey 表達了對 EIP 7251 的支持，增加了最大有效餘額（maxEB）。 「我們幾乎已經在Lighthouse 中對其進行了原型設計。規範上仍然需要完成一些工作，但實際上看起來工作量並不大，而且考慮到驗證器集的大小有點像定時炸彈，我們提出了發行調整建議，發行變更是總是有爭議，因此不能保證社區會接受它。如果他們不喜歡，那麼我們實際上唯一能做的就是maxEB，」Mackey 說。 Ryan 表示，將 maxEB 納入 Electra 的主要阻力是由於程式碼變更的複雜性，正如 Prysm 團隊先前的電話中所表達的那樣。 Prysm 團隊的匿名開發人員「Potuz」在 Zoom 會議聊天中表示，他的團隊將再次審查 EIP 並重新評估提案的複雜性。 Ryan 要求客戶團隊為兩週後的下一次 ACDC 電話會議做好準備，以便就 EIP 7547 和 7251 做出「堅定的決定」。

金鑰管理器API 標準化

EF 開發人員營運(DevOps) 工程師Barnabas Busa 解釋說，所有CL 用戶端產生驗證器金鑰的方法似乎都略有不同，驗證器金鑰是操作和撤回驗證器所需的加密金鑰。有一些稱為「金鑰管理器 API」的 API 可以幫助驗證器節點操作員進行金鑰管理以及加入和退出驗證器。 Busa 解釋說，在傳回此 API 的值時，用戶端之間的細微差異確實會使測試 API 端點變得困難。他還提到，他的團隊已經開始對混合驗證器進行基本測試，這意味著驗證器節點營運商為其信標節點使用與驗證器用戶端不同的用戶端。信標節點是維護 CL 狀態的客戶端，但不管理驗證者參與共識所需的金鑰對。驗證者客戶端是利用金鑰對產生區塊並在鏈上簽署證明的客戶端。 Ryan 建議 Busa 啟動一個文件或拉取請求，以提出標準化金鑰管理器 API 的建議。參加電話會議的開發人員還支援進一步測試，以確保混合驗證器可以在所有 CL 用戶端組合上運作。

區塊價值信標 API 標準化

一位網名為「Dustin」的 Nimbus 開發人員也對 Beacon API 端點「productBlockV3」和「getBlockRewards」的 CL 標準化表示擔憂。 Dustin 解釋說，Beacon API 的某些領域未明確規定，並且在客戶端之間「未普遍實施」。具體來說，當涉及到應該返回區塊值的端點時，計算至少應該包括提議區塊之前和之後驗證者餘額的變化。然而，規範並未詳細說明客戶是否應該包括因另一個驗證者的行為而導致的驗證者餘額變化的獎勵和處罰。例如，其中包括同步委員會職責獎勵或處罰、提議者或證明者自我削減以及舉報人獎勵。 Ryan 同意應在 Beacon API 中新增說明。然而，其他參加電話會議的開發人員（包括來自 Prysm 團隊的 Radosław Kapka 和 Potuz）卻沒有那麼自信。 Potuz 表示擔心，使用這些端點的人數很少，並且能夠使用自己的工具標準化來自不同 CL 用戶端的區塊值。 「我甚至不明白，如果消費者受到限制，我們為什麼還要同意支持這一點。我會嘗試研究這些市場，看看我們是否真的可以將這項工作發送給使用這些端點的人而不是我們自己，”Potuz 說。

Nimbus 開發人員Jacek Sieka 反駁了這個觀點，他表示，由於「productBlockV3」端點存在，開發人員需要解決客戶端之間的不一致問題，或棄用該端點，轉而使用「V4 」。此外，Sieka 補充道：「我認為這個端點只是非常基本的功能。如果我們設想未來有多個塊源，並且您需要對它們進行比較，那麼這是有意義的。就這麼簡單。」Ryan 建議Dustin建立一個提案來標準化V3 和「getBlockRewards」端點，提案創建後，客戶團隊將重新討論是否要繼續支援它們。

其餘事項

Potuz 標記了兩個項目，以供開發人員進一步回饋和討論。第一個是關於目前未在引擎 API 中指定的後期區塊的執行層 (EL) 用戶端行為，該 A​​PI 規定 EL 和 CL 之間的通訊。 「如果這可以在引擎 API 中指定，這將使我們在重組後期區塊時變得更加輕鬆，」Potuz 說。 Potuz 標記的第二項是關於他對提議者建構者分離（ePBS）有效負載提升的分析，這項升級將消除以太坊上對可信中繼的需求。 Potuz 要求提供有關分析和其他 ePBS 設計限制的更多回饋。

最後，來自以太坊 Cat Herder 小組的 Pooja Ranjan 宣布一個名為「以太坊協議中的女性」（WiEP）的新工作小組成立。 WiEP 是以太坊基金會的一個新組織，致力於鼓勵和培養更多女性以太坊協議開發人員。 Ranjan 表示，該小組將於 3 月 8 日舉辦長達一小時的網路研討會，與多位女性以太坊協議貢獻者進行討論。

然後，Ryan 指出，他將從 4 月 1 日開始休息三個月。在他缺席的情況下，EF 研究員 Alex Stokes 將主持 ACDC 電話會議。

以上是以太坊核心開發者最新會議摘要：Dencun升級最終進度及Pectra 升級範圍討論的詳細內容。更多資訊請關注PHP中文網其他相關文章！