最新以太坊執行層會議總結：EIP-7514 將成為 Dencun 升級的一部分

作者：@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 獲取更詳細的整個事件報道。