原文標題：Ethereum All Core Developers Consensus Call #107 Writeup
原文作者：Christine Kim （編譯有刪減）
2023 年4 月20 日，以太坊開發者齊聚一堂，召開第107 次核心開發者共識電話會議(ACDC) 。 ACDC 是一個雙週會議系列，由以太坊基金會研究員Danny Ryan 主持，此次會議中，以太坊開發人員討論對以太坊共識層(CL) 方面的修改內容，更新了圍繞Deneb 的進展，並討論了下一次坎昆升級中，除了以太坊 EIP-4844 之外還有哪些提案包含其中。
Deneb Devnet #5
自 4 月12 日上海成功激活以來，以太坊開發者第一時間將注意力轉移到坎昆的籌備工作上。 Cancun 是以太坊執行層（EL）下一次升級的名稱，而Deneb 是對應CL 的升級名稱。在ACDE 電話會議期間，開發人員討論了Cancun/Deneb 升級的最終範圍，該升級將以EIP 4844 為中心，即blob 交易類型的實施，Deneb 的準備工作，從推出devnet #5 開始。
自去年10 月，開發人員就為EIP 4844 啟動了多客戶端測試網絡，也稱為devnets。 ACDE 電話會議主席Tim Beiko 表示，EIP 4844 的第五個devnet 將於下周某個時候啟動。以太坊基金會的DevOps 工程師Paritosh Jayanthi 表示，他正在為Ethereum JS (EL) 和Lodestar (CL) 等客戶進行試運行，為下週的devnet 發布做準備。
其中，引擎 API 有一個小的更改，將“getPayload V3”和“getBlobsBundle V1”調用合併為一個。 Beiko 強調，這個更改尚未合併到 GitHub 上的 EIP 4844 規範中，但將在接下來的幾天內完成，以便該更改可以在 devnet＃ 5 上進行測試，Beiko 敦促客戶端團隊盡快審查此更改。
開發人員隨後討論了有關如何在鏈重組時將blob 事務重新插入塊的問題。這個問題是由Geth（EL）開發者 Péter Szilágyi 在他在ETHTokyo上的演示中提出的（可以在 Szilágyi 的PPT中找到更多信息）。 Ryan 表示，由於blob 事務與常規事務分離的特性，重新組織後的blobs 只能從公共mempool 的交易中獲得。鑑於有很多交易會繞過mempool，即MEV 交易和捆綁包 bundles，一種保證所有blob 都可以重建的方法（即使是繞過內存池的交易），即讓CL 將每個塊的blob 數據傳遞給EL ，然後EL 可以緩存它直到塊完成。或者，網絡可以要求提交了跳過mempool 的交易用戶，在鏈重新組織事件中重新提交其交易。
Szilágyi 表示，他更喜歡前者，即將blob 數據傳輸到 EL 中，以便在重新組織時可以重新插入交易，甚至是繞過內存池的交易。在 Szilágyi 看來，這對 EL 的額外負載並不大，如果這個過程變得相當繁瑣而讓節點無法支持，則開發人員可以調整 EL 和 CL 之間的消息以減輕負擔。 “最簡單的解決方案是，在共識客戶端發送新的有效載荷時將 blob 提供給執行客戶端。” Szilágyi 說道。 Ryan 回應稱，雖然所提出的解決方案很簡單，但它會進一步破壞 EL 和 CL 層之間的抽象。此外，該解決方案將強化節點存儲完整數據的假設，而該假設在未來實施數據可用性採樣（DAS）升級中可能會被打破。
關於 DAS 的實施，Szilágyi 表示，在這次升級中，數據可用性方面會有其他期望需要改變，並建議開發人員“到那時再試著解決問題”。 Ryan 同意了他的看法，並詢問其他開發人員對鏈重組和 blob 交易重新插入情況的看法。 Lodestar (CL)客戶端的開發者 Gajinder Singh 表示，由於 MEV 交易是繞過公共內存池最常見的類型，並且 MEV 交易高度依賴特定鏈狀態進行執行，因此在鏈重組後刪除它們並不重要，因為鏈狀態已經改變，MEV 交易可能需要重新執行。
由於缺少 EL 客戶端團參與，下次 ACDE 電話會議上再次提出這個問題。
Deneb Add-Ons
除了EIP-4844 ，Deneb 升級還考慮了其他的代碼升級。
1、第一個是 EIP-4788 ，它可以在 EL 中公開 CL Beacon Chain 的狀態。這將允許在 EL 上執行的智能合約對 CL 進行最小化信任訪問，這與質押池、再質押協議、MEV 等相關。以太坊基金會研究員 Alex Stokes 是 EIP 的作者之一，他表示該功能是對 CL 的“輕量級”更改。電話會議上沒有人反對將 EIP 4788 包含在 Deneb 中。並將在下次 ACDE 電話會議上向 EL 客戶端團隊征求支持該 EIP 的意見。
2、EIP-6914 ，該提案能將已完全退出網絡並且有一段時間未活動的驗證器索數字重複使用。在驗證器退出以及新的驗證器加入到網絡的過程，該 EIP 將有助於減少驗證器列表的無限增長。 Stokes 表示，EIP 6914 的複雜性比較高，代碼更改應推遲到Deneb 後面的下一次硬分叉。在對EIP-6914 複雜性進行討論後，開發人員同意繼續磨合代碼更新的詳細信息，但將最終的實施留到Deneb 之後。
3、Ryan 提出了一個潛在的代碼更改，涉及從 Beacon Chain 創世區塊開始回填數據並創建新的“歷史摘要”內容。關於這個代碼更改的細節尚未在 EIP 中指定。 Ryan 同意與此更改的提議者 Jacek Sieka（Status 研究開發負責人，正在構建 Nimbus (CL)客戶端）聯繫以獲取更多詳細信息。
4、PR 3175 ，該提案將防止被懲罰的驗證者在退出隊列時提出區塊。如果有超過 50 ％的驗證者因惡意行為而被懲罰，在被強制從網絡中驅逐的同時，這些驗證者仍然能夠提出區塊。 Ryan 表示，更改此邏輯是一個相對較小的 CL 層更改，可以提供對“高故障模式”的保護。
5、EIP-6493 ，該提案將解決節點應如何處理在 CL 上以 SSZ 格式進行格式化但在 EL 上編碼不同的 blob 交易類型。這個 EIP 是更新以太坊序列化格式以實現跨層一致性內容的一部分。有關以太坊序列化格式的更多背景信息可以閱讀先前開發者記錄。
在Deneb 範圍的討論中，開發人員傾向於於將EIP-4788、EIP-3175 與EIP-4844 一起包含在下次升級中。