摘要：本次為ACDC第129次電話會議，會議上，開發人員分享了有關Dencun升級準備工作的最后更新，并討論了下一次以太坊升級Pectra的范圍和EIP。ACDC電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員DannyRyan主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。...

原文標題：Ethereum All Core Developers Consensus Call #129 Writeup

原文作者：Christine Kim

原文來源：galaxy

編譯：Luccy，BlockBeats

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 電話會議。