原文標題：《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 將原文編譯如下：######On March 28, 2024, the Ethereum development community convened a Zoom meeting for the All Core Developers Execution (ACDE) call #184. The ACDE call is a biweekly series of meetings where decisions related to Ethereum's development are discussed and coordinated. Tim Beiko, the main coordinator supported coordinator the lpersed the lperss, lpersby coordinity the coordin 區, coordin 區and consensus-building on proposed changes to the Ethereum Improvement Proposals (EIPs).#######本週，開發人員分享了有關導致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 頻道上以標題為「歷史到期」的子頻道主題中進行對話。
開發人員同意實作 EIP 7610 和 7523。這些是追溯性 EIP，它們將向以太坊協議添加規則，這些規則可以從網路開始追溯應用，以進一步限制鏈上某些類型的行為。這些 EIP 的好處是簡化了以太坊測試案例，並限制了各種邊緣情況的範圍，例如建立空白帳戶的邊緣情況。兩個已追溯應用的 EIP 包括 EIPIP2681 和 3607。開發商同意在 Prague/Electra 啟動另外兩個追溯性 EIP。有關這些 EIP 約束哪些行為的背景信息，請參閱此處的先前通話記錄。
Geth 客戶團隊已經完成了一些基準測試，以估算 EIP 2537 BLS 曲線操作的 gas 成本。這些新業務將在 Prague/Electra 升級中激活，開發人員目前正在權衡這些業務的定價。 Reth 團隊的一位代表表示，他的團隊還將完成 BLS 曲線操作的額外基準，以協助確定這些操作的 gas 成本。
如ACDC #130所討論的，開發人員正在強烈考慮將 EIP 7547 包含在 Prague/Electra 升級中。本週，以太坊基金會研究員 Mike Neuder 分享瞭如何修改 EIP 7547 以與帳戶抽象向前相容的最新資訊。帳戶抽像是一項持續的舉措，旨在為以太坊上的外部帳戶（EOA）引入更大的靈活性和可程式性，這些帳戶是用戶控制的帳戶。 Neuder 提出了三種不同的方法來解決 EIP 7547 和帳戶抽象 EIP 之間的相容性問題。關於這些解決方案，Neuder 說，「這確實感覺像是包容性設計的複雜性，但我確實認為這三種選擇確實有效，而且我也不認為會有靈丹妙藥來解決這個問題。我不認為我們會找到一個更好的設計解決這些問題。
Beiko 建議在有限的時間內，在單獨的分組會議上繼續討論納入列表設計。
接下來，開發人員瀏覽了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 說。
以上是以太坊核心開發者最新會議摘要：主網狀態與成長數據分析、 Prague 升級提案的詳細內容。更多資訊請關注PHP中文網其他相關文章！
