原文標題： 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 一起包含在下次升級中。