以太坊核心開發者最新會議摘要：主網狀態與成長數據分析、Prague升級提案

閱讀本文需 16 分鐘

3月28日，以太坊所有核心開發人員參加了第184次All Core Developers Execution(ACDE) 電話會議。

原文標題：《Ethereum All Core Developers Execution Call #184 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的變更。本次為 ACDE 第 184 次電話會議，本次會議重點關注了導致 3 月 27 日錯過區塊數量上升的原因、以及 Paradigm 團隊關於以太坊狀態和歷史增長的新研究。

開發人員在會議上分享了有關 Bloxroute MEV 中繼問題以及對 Prague/Electra 中的兩個追溯性 EIP 的討論。此外，還就 EIP 7547（包含清單）、EIP 5920（PAY 操作碼）和 EIP 7545（Verkle 證明驗證預編譯）的開發更新進行了討論。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

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 說。