作者：@TimBeiko 翻譯：火火/白話區塊鏈
9月15日又結束了一次@ethereum #AllCoreDevs 會議：會議討論了開發網絡的更新，對Dencun 的增加，還全面概述了Reth ！
議程：https://github.com/ethereum/pm/issues/857直播鏈接：https://youtube.com/live/aobFWu7NANc?feature=share
以下是由@TimBeiko 做出的會議總結。
1、Devnet-8 的狀態更新
首先，關於devnet-8 的狀態更新：該網絡正在進行最後的開發，許多客戶端已經向其推送了新的更新。與此同時，我們已經開始使用@KurtosisTech 進行MEV/block 構建流程的測試。 @NethermindEth 表示他們的blob 事務池現在已經就緒，在單個節點上進行了幾天的測試後，他們已經將其部署到了所有的Dencun 測試節點上。
Geth 的blob 事務池也快要完成了。 Besu 正在對其交易池進行廣泛的改進（限制blob 和非-blob 交易的總大小），預計將在其下一個版本中發布。 Erigon 仍在繼續改進其交易池，希望能在devnet-9 上準備就緒。 Prysm 也指出在接收blob sidecars 方面存在一些延遲，他們表示這些sidecars 通常在區塊後大約延遲約500毫秒到達（而區塊處理需要約15毫秒）。
他們正在調查這個問題，以確定是否可能是blob 和區塊導入之間的競態條件引起的。關於在硬分叉之前是否允許在內存池中支持blob 事務的問題，團隊們一致同意不這樣做。
2、EIP-7514
接下來，我們繼續了上週ACDC 電話會議上的討論，討論是否要向驗證器激活隊列添加一個常數上限。此提案已經正式形成為EIP-7514。簡而言之，這將減緩在最壞情況下ETH 投注的百分比增長速度。 Dankrad 在通話中表達了對該提案的支持，他表示這會為我們爭取時間，以進行潛在更複雜的驗證器獎勵方面的變更。
所有CL 團隊都讚成這項變更，但有一個附加條件，即這只適用於存款隊列，不適用於提款隊列。經過更多討論，我們決定將限制設置為8。因此，EIP-7514 將成為Dencun 升級的一部分！預計在接下來的幾天內，EIP 和相關的CL 規範PR 將會更新以反映這一變更。
3、EVM 與Blob
接下來，我們討論了另一個臨時提案：在以太坊虛擬機（EVM）中添加一個操作碼來公開blob 基礎費用。這個提案是由來自Arbitrum 的@PlasmaPower0 提出的，他在本週早些時候在R&D Discord 上表示這對他們（以及其他Layer 2 解決方案）會很有用。我們已經有一個類似的操作碼，可以公開EIP-1559 中的BASEFEE，這個操作碼是在EIP 激活的同時引入的。這使得Layer 2 解決方案更容易根據L1 數據成本來確定向用戶收取的正確的gas價格。
來自Optimism 的@protolambda 也參加了會議，並提出這不是獲得L2 的blob 基礎費用的唯一方式，因為他們可以查看區塊頭（其中包含用於計算blob 基礎費用的值），並提供針對這些值的Merkle證明。儘管如此，他也同意這是一個不錯的功能。 Arbitrum 目前不執行區塊頭解析，而依賴這一點對於不可變的Layer 2 解決方案來說可能會有問題，因為如果區塊頭格式最終發生變化，會帶來麻煩。
其中一位EIP-4844 的作者@adietrichs 提到，這個操作碼沒有包括在原始規範中，因為當時有希望開發一種更通用的方式來訪問區塊頭信息（而不是添加一次性的操作碼）。儘管如此，與引入這個操作碼相比，採取這種更為宏大的改變將是一項更加雄心勃勃的任務。
這個操作碼暴露的信息已經是EL 客戶端需要計算的信息，從語義上講，它幾乎與BASEFEE 操作碼相同。客戶端團隊一致同意，因此我們應該添加這個操作碼，即使只是為了與BASEFEE 保持一致。如果將來我們提出了一個“更巧妙”的機制，那麼這個新操作碼中的任何冗餘功能也會成為使用區塊頭信息的其他操作碼的問題。此外，值得強調的是這是很小的一個改變：@vdWijden 在EIP 存在之前在Geth 中實現了它，大約只用了約20分鐘，而Reth 團隊在ACD 電話會議期間提交了一項關於這個變更的PR.
4、EIP-4788
接下來，我們討論了對EIP-4788 的一些更新，該提案將beacon 根存儲在以太坊主鏈上的合約中。在過去的幾周里，我們對該合約進行了多次審計和模糊測試，這導致了在這個PR 中描述的一些小的變更。儘管還沒有完成所有的審計工作，而且報告也還沒有出來，但@lightclients 給出了迄今為止考慮的變更的概述。第一個變更是對0時間戳的明確處理，使其導致回滾（就像其他無效的時間戳一樣），而不是返回0。第二個變更是關於緩衝區大小的。假設時隙時間發生了變化，原始合約將會導致存儲浪費，因為模運算的工作方式。
5、Gas 優化
最後，還有一個減少加載CALLDATA 次數的gas優化。審計員將審查這些變更，我們預計在下一個ACDE 會議之前將獲得他們的最終報告。為了保持模糊測試和實施工作的進展，我們同意現在合併提出的變更。
@shemnon 還提到這些變更應該在實際的EIP 中進行文檔記錄- 我們正在處理！接下來，我們討論瞭如果系統合約地址是狀態的一部分，但在執行結束時為空，客戶端應該如何處理。雖然這在主網上實際上不太可能發生（按我理解的情況！），但這是一種在測試中出現的邊緣情況，通過在創世區塊中設置地址來測試。
鑑於這是一個相當特殊的邊緣情況，並且沒有明確的規範行為，我們同意花更多時間來思考這個問題，並在下週的測試會議上繼續討論。這就是有關規範變更的全部內容！以上所有內容都已計劃包含在devnet-9 中。客戶端團隊一致認為，應該可以在下週的ACDC 之前實施和測試所有內容。在那次電話會議上，我們將達成devnet-9 的啟動日期協議。
下一次ACDE 計劃於9 月28 日，UTC 時間14:00 舉行。在那之前，可以關注@terencechain 獲取測試會議總結，關注@benjaminion_xyz 獲取ACDC 會議信息，以及關注@christine_dkim 獲取更詳細的整個事件報導。