2024 年 3 月 21 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Consensus (ACDC) call #130 會議。ACDC 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會研究員 Danny Ryan 主持，開發人員在會上討論和協調對以太坊共識層（CL）的更改。本周，開發者們討論了與 Dencun 升級相關的未完成任務、Pectra 升級的提案以及以太坊網路層的改進。開發者們同意在 Pectra 中包含 EIP 7251「增加 MAX_EFFECTIVE_Balance」，並繼續評估 EIP 7547「Inclusion lists」，以便在升級中潛在地加以包含。

Dencun 行動項目

以太坊基金會僱傭的社區協調員 Trenton Van Epps 分享了一份關於導致 Dencun 升級的多年開發的以太坊協議開發者情感匯編，該匯編已在 Mirror 上發布。這份名為「Dencun 日記」的匯編收錄了超過 45 位以太坊開發者的聲音，以及他們對準備 Dencun 的成功和挑戰的看法。

Van Epps 談到這個項目時表示：「我認為這是一個非常有用的資源。如果大家一直關注的話，你們會知道我之前為 Merge 升級和 Beacon Chain 的啟動做過類似的事情。所以，這只是為歷史記錄增加了一份。希望我們開始建立機構記憶，了解以太坊核心開發者和圍繞它的社區是如何運作的。所以，感謝所有提交的人。我認為這是對情感的一個很好的快照，希望我們在不斷學習中前進。」

他還表示，對於為 Dencun 升級做出貢獻的以太坊開發者來說，現在仍然有機會將他們的意見添加到 Dencun 日記中，並直接與他聯繫。

接着，以太坊基金會協議支持主管 Tim Beiko 向所有 Dencun EIP 作者發出呼籲，要求他們在 GitHub 上更新他們的提案，將狀態更新為「Final」，以表示他們的代碼更改現在已在以太坊主網上實施。需要此狀態更新的完整 EIP 列表可在此處找到。

關於升級對以太坊的影響，Prysm 開發者 Terence Tsao 提到他注意到重新組織的區塊數量有所增加，意味著在網路上提出但未包含在以太坊區塊的規範鏈中的區塊。Tsao 說他正在進一步調查這種行為的原因，並且他推測原因與 MEV 構建者規範有關。

以太坊基金會開發者營運工程師 Parithosh Jayanthi 表示，根據他團隊對 Dencun 的分析，他們注意到有少量數據塊延遲到達網路，延遲了四秒進入一個時隙。時隙是以太坊上選擇驗證者提出區塊的 12 秒間隔。儘管慢到達數據塊的數量不高，Jayanthi 表示重要的是要密切關注這種行為。Prysm 開發者「Potuz」提到，升級中對證明包含時間線的更改之一可能會加劇節點跟蹤資源使用的指標。Teku 開發者 Enrico Del Fante 表示，他的團隊意識到了有關 CPU 和帶寬使用率高於正常水平的問題，並將在 Teku 客戶端的下一個版本中包含修復此問題的解決方案。

最後，Lodestar 開發者加 Gajinder Singh 提出了一個微小的改名建議，將操作碼「BLOBBASEFEE」改為「BLOBBASEFEEPERGAS」。Singh 表示：「基本上是為了確保單位更符合其所傳達的含義。」Ryan 鼓勵電話會議上的開發者，特別是 EIP 4844 的作者，即引入數據塊提案的作者，審查 Singh 的變更。

審查抗性代碼更改

以太坊基金會安全研究員 Fredrik Svantes 分享了一項提案，旨在通過客戶端實現「get_Payload」請求來提高本地構建塊的價值 10%。開發者們在 2022 年底通過「get_Payload」請求在引擎 API 中添加了對塊價值的計算。這樣做是為了使驗證者能夠輕鬆比較本地構建塊的價值與第三方區塊構建者構建的塊的價值。據 Svantes 稱，64% 的構建者正在主動審查塊中的交易。為了鼓勵驗證者提出本地構建的塊，Svantes 建議將本地塊的價值提高 10%。他補充說，他正在與以太坊基金會的測試團隊合作，確保這些更改在測試客戶端軟體時不會觸發任何虛假警報或破壞現有的測試基礎設施。

Potuz 反對了 Svantes 的建議，表示塊價值應由客戶端配置。「我們應該停止指定這些東西。我們應該停止以協調的方式這樣做，」Potuz 說，並補充道：「我認為客戶端應該自由地設置這些東西。它們可以由用戶進行配置，我們不應該對實際行動感到害怕以實現我們的信念。」其他電話會議上的開發者，包括 Lodestar 開發者 Phil Ngo 和 Lighthouse 開發者「Sean」，都同意了 Potuz 的看法。

「不將其設置為 10% 的一個原因可能是，這將是一種意外情況，有點像利用用戶可能不知道此功能的事實。而一個更好的方法，也許在 Lighthouse 中，是要求用戶在使用構建器時設置該值。這樣一來，可以提高標誌的意識，而不是對其應該設置為何種值給出建議，」Sean 說道。

隨後，開發者們討論了什麼樣的邊際會鼓勵驗證者選擇本地塊而不是由構建器構建的塊。由於電話會議時間有限，Ryan 建議繼續進行其他會議議程。

Pectra 代碼更改

Ryan 開始了關於在 Electra 中包含的重大代碼更改的討論，重點介紹了兩個最主要的提案，即 EIP 7251 和 EIP 7547，它們在競選中處於領先地位。"我們已經來回討論過了。我們曾經認為其中一個或另一個被埋沒了，它們在不同時間又浮出水面，但我們肯定已經到了如果我們不做決定，我們確實需要儘快做出決定的時候。有意在五月份某個時間點擁有 Electra 的功能原型和開發網路，我們在三月底要關閉了。所以，我只是想讓大家明白，這些是中等大小的項目，如果不是大項目的話，我們可以繼續討論，但我們不能再繼續把這個問題拖得太久了。否則，我認為默認情況就是"不"。我想猶豫不決本身就是一種決定，"Ryan 說道。

包含列表

隨後，Ryan 將發言權交給以太坊基金會研究員 Mike Neuder，他正領導着準備 EIP 7547，即包含列表（ILs），用於 Pectra 的工作。Neuder 分享了最近關於 ILs 的分組會議的更新。該會議的摘要可以在這裡找到。Singh、Sean 和其他電話會議上的人表示支持在 Pectra 中同時包含 ILs 和 EIP 7251，也被稱為 MaxEB。Potuz 提到的有關 IL 規範的突出問題之一是它對銘記的帳戶抽象（AA）的影響。未來，以太坊開發者計劃為用戶控制的以太坊帳戶，也稱為外部擁有的帳戶（EOAs），引入增強的靈活性，而 ILs 的當前設計可能會使這一過程變得複雜。開發者討論了更新 IL 規範的方式，使其更加兼容未來的 AA 代碼更改。開發者還討論了他們首次嘗試在自己的客戶端中實現 ILs 的初步工作，以及在某些情況下使用引擎 API 的權衡之間的權衡。Neuder 和 Terence 建議在下一次 IL 分組會議上討論與 IL 規範相關的問題，而不是在電話會議上討論 ILs 的技術細節。

MaxEB

開發者們還討論了 MaxEB 在 Pectra 中實施的準備情況。Ngo 分享了最新的 MaxEB 分組會議的更新，該會議於 3 月 20 日星期三舉行。可以在這裡找到此次會議的摘要。Lighthouse 開發者「ethDreamer」表示，他的團隊更傾向於優先考慮 MaxEB，但也願意在 Pectra 中同時包含兩者。基於他同事對 MaxEB 的評估，Potuz 表示，Prysm 團隊確信 MaxEB 可以在年底之前實現，這是開發者們試圖完成 Pectra 升級的時間範圍內。

Ryan 提醒電話會議上的開發者，在 Pectra 升級的同時，他們已經承諾着着手進行 peerDAS 的工作，這是一項着眼於通過引入數據可用性採樣和提高每個塊中數據塊數量來安全增加以太坊數據可用性容量的代碼更改。Ryan 說：「我直覺上認為 MaxEB 或 IL 之一進入 Electra 可能不會對能夠進行 peerDAS 研發的並行性造成很大影響，但如果兩者同時存在，我們現在開始權衡，可能真的無法同時處理這三件事情。」

然而，電話會議上的開發者們，如 Sean、Singh、Ngo、Lighthouse 開發者 Age Manning 等人，紛紛表示支持在 Pectra 中同時包含 MaxEB 和 ILs。如果開發者們仍然計劃在年底之前在主網上推出 Pectra，Potuz 則強烈反對同時包含兩者。在 ILs 的話題上，Ryan 問道，它的實施是否也給 EL 客戶端團隊帶來了沉重的工作負擔。Geth 開發者「Lightclient」表示，從他的觀點來看，實施 ILs 的工作負擔在 CL/EL 客戶端團隊之間是 80/20 的分配比例。在開發者們對這兩項代碼更改進行了更多討論之後，Beiko 建議繼續在 Pectra 中包含 MaxEB，同時繼續在 EL 和 CL 客戶端團隊之間進一步討論後，對 ILs 進行進一步的範圍界定，以便在升級後可能包含 ILs。這意味著開發者們優先考慮 MaxEB 而不是 ILs。最終，開發者們同意採納 Beiko 的策略，在 Pectra 中包含 MaxEB，並在一到四周內重新討論 ILs。

「我個人認為，這兩件事情加在一起，使我們進入了比過去幾個月討論的升級更為複雜的領域。所以要有所知曉。此時此刻，我還要說，我們總是非常有信心和興奮地應對複雜性，並且還有很多工作要做，」Ryan 在關於 Pectra 範圍的最後警告中說道。正如在ACDC＃129中提到的，本周的會議結束後，Ryan 將休假三個月。以太坊基金會研究員 Alex Stokes 將代表他主持 ACDC 電話會議。

Blob gas 增加

在討論了 maxEB 和 ILs 之後，開發者們討論了以太坊基金會研究員 Ansgar Dietrichs 起草的一項提案，該提案旨在在 Pectra 升級後的四個月內，逐步將每個塊中的 blob 數量增加到最多 16 個，從而使其從 6 個增加到 16 個。這種增加將進一步降低數據可用性的成本以及建立在以太坊上的 Layer 2 rollups 的成本。Ryan 表示支持該提案，前提是滿足以下三個關鍵條件：

· 關於 blob 性能的可靠數據。

· 在 Pectra 中激活 EIP 7623，該提案限制了最大塊大小。

· 進一步討論關於時間增加 blob 數量的確切機制。

Ryan 鼓勵開發者們在未來幾周內發表他們對該提案的看法。

輕客戶端開發

Nimbus 開發人員 Etan Kissling 分享了兩份與影響 CL 規範的輕客戶端開發相關的草案提案。同步委員會的懲罰和輕客戶端數據回填是輕客戶端路線圖的兩個組成部分，開發人員正在與 Pectra 升級同時進行。Kissling 要求 CL 客戶端團隊就這些組成部分提供意見，特別是 maxEB 對參與同步委員會的大型驗證者的懲罰條件會產生什麼影響。關於同步委員會的背景，請閱讀以太坊基金會的這篇文章。

網路更新

在正在進行的研究項目方面，Manning 分享了一種新的對注釋子網（attnets）的處理方法，這是一種使驗證者能夠發送和接收注釋的網路層。儘管目前實施並不緊急，但這種向後兼容的提案似乎在 peerDAS 生效後為網路提供了優化。

Manning 還提出了向網路對等體發送新控制消息的實施，該消息將「顯着減少」節點帶寬。Manning 表示，他的團隊已經開始測試「IDONTWANT」控制消息，並且可以獨立發布，但需要整個網路的協調才能開始看到此更改的好處。他請求電話會議上的開發者審查該提案，並看看他們是否考慮一起發布該更改。

最後，Manning 提出了在 libp2p 庫中廢棄 mplex 的問題。Mplex 是一種流復用器，用於通過一個通信鏈路發送多個數據流。由於 mplex 的廢棄，Manning 表示，他的團隊和其他客戶端團隊正在升級到另一種稱為 yamux 的不同流復用器。Manning 詢問了客戶端團隊的遷移狀態，以及是否還在使用 mplex。來自 Teku 和 Lodestar 團隊的代表表示，他們正在努力開發他們的 yamux 實現，但還沒有準備好從 mplex 切換過來。

原文連結