在 Deneb 範圍的討論中，開發人員傾向於將 EIP-4788、EIP-3175 與 EIP-4844 一起包含在下次升級中。
- 原文標題：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 有一個小的更改，將「getPayloadV3」和「getBlobsBundleV1」調用合併為一個。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 一起包含在下次升級中。
編譯：DeFi之道
