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

作者：Christine Kim

編譯：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 在電話會議開始時提醒大家，Dencun 升級將在不到一周的時間內在以太坊上線。他也提到，對許多美國人來說，將在DST 時間3 月10 日這個週末開始。鑑於所有ACD 電話會議以及升級都是根據不實行DST 的協調世界時（UTC）來安排的，那些位於美國之外的開發者和收聽電話會議的人將需要相應地調整他們的日程安排。

電話會議上的一些客戶端團隊也分享了他們將在未來幾天發布推薦版本的軟體以適應Dencun 升級，Prysm、Lighthouse 和Teku 團隊都預計將在本週末之前發布新版本。鑑於這些版本並非升級所必需，EF（以太坊基金會）協議支援負責人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，都顯示大約50% 的以太坊節點似乎已經為Dencun 升級做好了準備。 Beiko 也表達了他對一個資料工具的渴望，這個工具能夠追蹤驗證節點為升級做好準備的情況，而不僅僅是所有以太坊節點。

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) 用戶端行為，該API 規定EL 和CL 之間的通訊。 「如果這可以在引擎API 中指定，這將使我們在重組後期區塊時變得更加輕鬆，」Potuz 說。 Potuz 標記的第二項是關於他對提議者建構者分離（ePBS）有效負載提升的分析，這項升級將消除以太坊上對可信中繼的需求。 Potuz 要求提供有關分析和其他ePBS 設計限制的更多回饋。

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

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