3月7日，以太坊開發者參加了ACDC #129電話會議，討論了Dencun升級準備工作和下一個Pectra升級的範圍。關於Dencun升級，開發人員分享了準備工作的最新更新，計劃於3月13日在主網啟動。此外，討論了Pectra升級中的四個程式碼更改，其中包括CL客戶端的升級。也討論了金鑰管理器API標準化和區塊價值信標API標準化等其他事項。此外，成立了一個名為「以太坊協議中的女性」的新工作小組。作者提到，以太坊基金會研究員將在4月1日開始三個月休息。
作者：克莉絲汀金
編譯：Luccy，BlockBeats
編按：以太坊所有核心開發者共識電話（ACDC）每週舉行一次，主要討論並協商以太坊共識層（CL）的變更。本次為ACDC第129次電話會議，會議上，開發人員分享了有關Dencun升級準備工作的最後更新，並討論了下一次以太坊升級Pectra的範圍和EIP。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將編譯如下：
2024年3月7日，以太開發人員齊聚Zoom參加了全核心開發者共識（ACDC）電話會議#129會議。 ACDC電話會議是一個每週六舉行一次的系列會議，由以太坊基金會研究員Danny Ryan主持，開發人員在會上討論和協調對以太坊研討會層（CL）的更改。本週，開發人員分享了有關Dencun升級準備工作的最後更新，該升級計劃於3月13日週三在主網上激活他們還討論了下一次以太坊升級Pectra的範圍，以及一些研究主題，其中之一是CL客戶端之間的區塊值標準化。
天津四
Ryan在電話會議開始時提醒大家，Dencun升級將在不到一周的時間內在以太坊上線。他也提到，對許多美國人來說，將在夏令時間3月10日這個週末開始。和所有ACD電話會議以及升級都是根據不實行夏令時的協調世界時（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%的以太坊節點似乎已經為Decun升級做好了準備。 Beiko也表達了他對一個資料工具的渴望，這個工具能夠追蹤驗證節點對於升級準備就緒的情況，而不僅僅是所有以太坊節點。
伊萊克特拉
以太坊開發人員與Pectra討論了升級相關的四項程式碼變更。
電子IP 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 也表示，對話是「正在」的”，這意味著做出決定需要在之前對這個想法進行進一步的討論。
電子IP 7547
第三，EF研究員Mike Neuder提出了EIP 7547，包含列表，以便進一步討論。他表示，討論EIP設計的「意圖特徵」的第二次分組會議將會很有用，他正在考慮在下週五（即3月15日）組織了一次分組會議。他還提到，EIP有一個專門的Discord頻道，名為“包含列表”，有興趣了解更多有關提案或提出問題的人應該使用。 Tsao也表示，自2月16日包括第一次清單分組會議以來，該規範的規範已基本完成。 Tsao表示：「我認為該規範可能已完成75%左右。」他補充說，規範中還有一些組件其他需要改進，例如執行API的更改和有關誠實驗證器的規範。
電子IP 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 用戶端的工具來標準化限制區塊值。 「我甚至不明白，如果消費者受到影響，我們為什麼還要同意支持這一點。我會嘗試研究這些市場，看看我們是否真的可以將這項工作發送給使用這些端點的人，而不是我們自己，」波圖茲說。
Nimbus 開發人員Jacek Sieka 反駁了這種觀點，他表示，由於「productBlockV3」端點存在，開發人員需要解決客戶端之間的不一致問題，或者放棄使用該端點，轉而使用「V4」。此外，Sieka 補充道：「我認為這個端點只是非常基本的功能。如果我們設想未來有多個塊源，並且您需要對它們進行比較，那麼這是有意義的。就這麼簡單。」Ryan 建議達史汀創建一個提案來標準化V3和「getBlockRewards」端點，提案創建後，客戶團隊將重新討論是否要繼續支援它們。
其餘事項
Potuz 標記了兩個項目，以供開發人員進一步回饋和討論。第一個是關於目前未在引擎API 中指定的高階區塊的執行層(EL) 用戶端行為，該API 規定EL 和CL 之間的Potuz 說：「如果這可以在引擎API 中指定，這將使我們在重組升級區塊時變得更加輕鬆。」Potuz 有效標記的第二項是關於他對提議者構建者分離（ePBS）負載提升的分析，這一升級將消除以太坊上對可信集群的需求。 Potuz 要求提供有關分析和其他ePBS 設計限制的更多回饋。
最後，來自以太坊貓牧者小組的Pooja Ranjan宣布一個名為「以太坊協議中的女性」（WiEP）的新工作小組成立。 WiEP是以太坊基金會的一個新組織，鼓勵並培養更多的人Ranjan表示，該小組將於3月8日舉辦長達一小時的網路研討會，與多位女性以太坊協議貢獻者進行討論。
然後，Ryan 指出，他的民主黨4 月1 日開始三個月休息。在他缺席的情況下，EF 研究員Alex Stokes 將主持ACDC 電話會議。
資訊來源：0x資訊編譯自網際網路。版權歸作者區塊律動BlockBeats所有，未經許可，不得轉載