原文標題：《Ethereum All Core Developers Consensus Call #130 Writeup》
原文作者：Christine Kim
原文編譯：Luccy，BlockBeats
編按：
以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論和協調對以太坊共識層（CL）的變更。本次為 ACDC 第 130 次電話會議，會議上，開發者們就 Dencun 升級的行動項、Pectra 升級的代碼變更、以及輕客戶端開發等議題進行了深入討論和決策。
開發者就 Ethereum 網路中出現的一些問題所進行的討論，並針對性地提出了解決方案和改進建議。此外，開發者們對未來的開發計畫和重要事項進行了展望。 Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，原文編譯如下：
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 切換過來。
區塊財經BOTD – 廣播組
追蹤BOTD Instagram，獲取最新區塊鏈消息
▸https://www.instagram.com/botd_news/
免責聲明：本文內容僅供參考，投資人應獨立判斷，審慎投資，並自負風險，本文不提供或嘗試遊說觀眾做交易或投資之依據。
