2024 年 3 月 28 日，以太坊開發人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #184 會議。ACDE 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。

本周，開發人員分享了有關導致 3 月 27 日錯過區塊數量上升的原因的見解。Prysm 開發人員 Terence Tsao 表示，這種上升是由 Bloxroute MEV 中繼的問題引起的，Bloxroute 團隊正在解決該問題。開發人員還討論了 Paradigm 團隊對以太坊狀態和歷史增長進行的新研究的要點。開發人員批准在 Prague/Electra 中包含兩個追溯性以太坊改進提案（EIP），即 EIP 7610 和 7523。

最後，他們分享了其他候選 EIP 的開發更新，例如 EIP 7547（包含列表）、EIP 5920（PAY 操作碼）和 EIP 7545（Verkle 證明驗證預編譯）。

主網缺少區塊事件

3 月 27 日，缺失區塊的數量有所增加。通常，以太坊上每 30 分鐘就會錯過 2% 到 4% 的區塊。但是，在網路經歷大量 Blob 事務期間，此百分比在幾個小時內上升到 14% 以上。這一時期的 blob 價格上漲了 10 倍以上。Tsao 說，一旦 Bloxroute 團隊關閉了他們的 MEV 中繼，缺失塊的問題就立即得到了解決。導致 Bloxroute 中繼問題的細節尚不清楚，Bloxroute 團隊正在研究修復程序，他們將在未來幾天內分享該修復程序以及對問題的完整事後分析。

「所以，昨天錯過的塊並不是說客戶無法處理這種類型的工作量，因為基本上所有錯過塊都是由 Bloxroute 問題引起的。但仍然存在一個基本問題，即在昨天的流量下會發生什麼，我懷疑，客戶導入區塊的速度可能比以前慢，但這是我沒有確鑿證據的事情，這還有待觀察，「Tsao 說。為了應對丟失區塊事件，Lighthouse 客戶端團隊發布了一個「熱修復」版本，以提高節點性能和穩定性。此外，雖然調查仍在進行中，但 Bloxroute 的首席執行官 Uri Klarman 在 X 上表示，他認為這些問題與 Bloxroute 中繼無關，而是與 blob 在以太坊上的一般傳播方式有關。

以太坊基金會開發人員營運工程師 Parithosh Jayanthi 詢問該事件是否會導致開發人員重新評估客戶端斷路器條件，這些條件會自動導致驗證器節點回退到本地區塊生產。在大多數客戶端中，斷路器條件的默認值是連續錯過五個插槽的事件。Tsao 指出，太容易觸發的斷路器條件是複雜的 MEV 行為者可以利用的潛在攻擊媒介。

Prysm 開發人員「Potuz」表示，在他看來，這一事件凸顯了中繼中缺乏客戶端多樣性實現，以及中繼和協議開發人員之間缺乏溝通。「Terence 已經談論這些 blob 一個多星期了，沒有人注意到這一點，一旦它爆炸，只需要打幾個電話就可以讓正確的繼電器實際查看他們的日誌。這是不可接受的，「波圖茲說。

一些開發人員建議下次在報告網路違規行為時創建書面帖子，以提高以太坊生態系統的知名度。為了進一步討論丟失區塊事件，以太坊基金會研究員 Alex Stokes 鼓勵開發人員參加下一次 MEV-Boost 社區電話會議。

狀態和歷史增長數據分析

Paradigm 的數據科學家工程師 Storm Slivkoff 對以太坊的狀態和歷史增長進行了新的分析。根據他的發現，狀態增長並不是以太坊可擴展性的主要瓶頸。「我們發現，現有的消費類硬體可以在很長一段時間內維持當前的國家增長率，可能是幾十年。請注意，我在這裡只談論儲存容量和內存容量。這並不是說在這種框架下要聲明的讀取或寫入」。在他看來，以太坊的「沉默殺手」是歷史增長。

在書面分析中，Paradigm 研究團隊解釋說：「狀態是構建和驗證新以太坊區塊所需的數據集。狀態由合約字節碼、合約儲存、帳戶餘額和帳戶隨機數組成。歷史記錄是將節點從創世同步到最新區塊所需的數據集。歷史由區塊和交易組成。狀態和歷史是非重疊的數據集。Slivkoff 補充說，歷史的增長速度明顯快於以太坊狀態。衝擊歷史增長率的最大用例是 rollups 和其他類型的協議，需要橋接到以太坊。

Slivkoff 建議開發人員認真考慮在下一次以太坊升級 Prague/Electra 中加快解決歷史增長的 EIP，例如 EIP 4444 和 EIP 7623。他還表示，將進行進一步的分析，以分析以太坊上的其他擴容瓶頸，並將這些方法應用於分析 rollup 的擴容瓶頸，作為其團隊研究的下一步。Slivkoff 說，所有數據都將開源供公眾使用，歡迎提供反饋。

在 Slivkoff 的演講之後，開發人員討論了在短期內解決歷史增長的不同方式。正如 ACDE #180 上所討論的，開發人員正在構建強大的替代網路，其中經過一定時期的歷史數據，例如合併升級之前的歷史數據，在數據無法通過以太坊節點訪問的情況下，用戶仍然可以訪問這些數據。有關歷史到期和服務歷史數據的替代選項的進一步討論，Geth 開發人員「Lightclient」建議開發人員繼續在以太坊研發 Discord 頻道上以標題為「歷史到期」的子頻道主題中進行對話。

追溯性 EIPIP7610 和 7523

開發人員同意實施 EIP 7610 和 7523。這些是追溯性 EIP，它們將向以太坊協議添加規則，這些規則可以從網路開始追溯應用，以進一步限制鏈上某些類型的行為。這些 EIP 的好處是簡化了以太坊測試用例，並限制了各種邊緣情況的範圍，例如創建空帳戶的邊緣情況。兩個已追溯應用的 EIP 包括 EIPIP2681 和 3607。開發商同意在 Prague/Electra 激活另外兩個追溯性 EIP。有關這些 EIP 約束哪些行為的背景資訊，請參閱此處的先前通話記錄。

EIP 2537，BLS 預編譯

Geth 客戶團隊已經完成了一些基準測試，以估算 EIP 2537 BLS 曲線操作的 gas 成本。這些新業務將在 Prague/Electra 升級中激活，開發人員目前正在權衡這些業務的定價。Reth 團隊的一位代表表示，他的團隊還將完成 BLS 曲線操作的額外基準，以協助確定這些操作的 gas 成本。

EIP 7547，包含列表

正如 ACDC #130 上所討論的，開發人員正在強烈考慮將 EIP 7547 包含在 Prague/Electra 升級中。本周，以太坊基金會研究員 Mike Neuder 分享了如何修改 EIP 7547 以與帳戶抽象向前兼容的最新資訊。帳戶抽象是一項持續的舉措，旨在為以太坊上的外部帳戶（EOA）引入更大的靈活性和可編程性，這些帳戶是用戶控制的帳戶。Neuder 提出了三種不同的方法來解決 EIP 7547 和帳戶抽象 EIP 之間的兼容性問題。關於這些解決方案，Neuder 說，「這確實感覺像是包容性設計的複雜性，但我確實認為這三種選擇確實有效，而且我也不認為會有靈丹妙藥來解決這個問題。我不認為我們會找到一個更好的設計解決這些問題。

Beiko 建議在有限的時間內，在單獨的分組會議上繼續討論納入列表設計。

Prague/Electra 的其他候選 EIP

接下來，開發人員瀏覽了 Prague/Electra 升級的其他候選 EIP 列表。它們包括：

EIP 5920（PAY 操作碼）：以太坊基金會研究員 Sam Wilson 指出，該操作碼的測試工作已經開始。

EIP 7609（降低 TLOAD/TSTORE 的基本成本）：Vyper 編譯器的貢獻者 Charles Cooper 重申了他的觀點，即 TLOAD 和 TSTORE 操作碼在 EVM 中應該定價更便宜。

EIP 2935 和 7545（在狀態和 Verkle 證明驗證預編譯中保存歷史塊哈希值）：Geth 開發人員 Guillaume Ballet 將這兩個提案作為代碼更改提出，這將為 Verkle 實現提供未來的好處，同時，有助於提醒更廣泛的以太坊生態系統即將到來的 Verkle 升級。

以太坊對象格式（EOF）：Besu 客戶端維護者 Danno Ferrin 表示，EOF EIP 正在由多個客戶端團隊實施，並且正在為它們編寫參考測試。他要求開發人員參考 EOF 就緒矩陣以獲取更詳細的更新。

EIP 7212 和 EIP 3074（secp256r1 曲線支持和 AUTH/AUTHCALL 操作碼的預編譯）：Besu 開發人員 Matt Nelson 重點介紹了 L2 rollup 正在實現的這兩個 EIP。他強調，為了鼓勵以太坊和 rollups 之間的兼容性，這兩個 EIP 應該在 Prague 採用。

EIP 7664（訪問密鑰操作碼）：OPLabs 開發人員「Protolambda」提出了 EIP 3074 的替代提案，該提案利用訪問列表來增強 AUTH/AUTHCALL 操作碼的功能。

EIP 6493（SSZ 交易簽名方案）：Protolambda 還表示支持與 SSZ 相關的代碼更改，以提高驗證以太坊數據的安全性和效率。

開發人員沒有時間討論此列表中的哪些 EIP 應該優先用於 Prague。Beiko 表示，在兩周後的下一次 ACDE 電話會議開始時，時間將被封鎖，以再次審查這份名單。「在接下來的幾周里，我們應該更深入地研究今天提出的所有問題，並致力於做出決定。我認為這意味著，如果我們想繼續前進，兩周後任何尚未完全弄清楚或指定的事物都可能不會進入這個分叉，「Beiko 說。

原文連結