編按：
以太坊所有核心開發(fā)者協(xié)商電話（ACDE）每週一召開一次，主要討論和協(xié)商對(duì)以太坊執(zhí)行層（EL）的變更。本次為 ACDE 第 180 次電話會(huì)議，次本會(huì)議主要討論了三個(gè)重要的程式碼變更：Verkle，以太坊虛擬機(jī)器物件格式（EOF）和歷史過渡。他們決定將Verkle 安排在布拉格升級(jí)之後，即大阪。此外，還討論了Dencun 升級(jí)的最新動(dòng)態(tài)，包括Sepolia 和Holesky 硬分叉，以及與Dencun相關(guān)的其他測(cè)試和問題。
開發(fā)者對(duì) Verkle 進(jìn)行了初步測(cè)試，並對(duì)其複雜性提出了一些擔(dān)憂，強(qiáng)調(diào)了其在主網(wǎng)實(shí)施準(zhǔn)備情況的研究。EOF 計(jì)劃在 2024 年第四季度的 Devcon 期間進(jìn)行主網(wǎng)激活。他們決定延遲設(shè)定Dencun升級(jí)的主網(wǎng)啟動(dòng)日期，以確保處理兩個(gè)尚未解決的問題。最後，會(huì)議簡(jiǎn)要提到了EIP-7523、EIP-7587等倡議，以及針對(duì)布拉格升級(jí)的進(jìn)一步規(guī)劃。
Galaxy Digital 研究副總裁 Christine Kim 對(duì)本次會(huì)議要點(diǎn)做了詳細(xì)記錄，BlockBeasts 將編譯如下：
2024年2月1日，以太坊開發(fā)人員齊聚Zoom參加了All Core Developers Execution (ACDE) call #180會(huì)議。ACDE電話會(huì)議是一個(gè)每週六舉行一次的系列會(huì)議，由以太坊基金會(huì)協(xié)議支持主管Tim Beiko 主持，開發(fā)人員在會(huì)議上討論和協(xié)商以太執(zhí)行層（EL）的更改。本週，開發(fā)人員主要討論了三個(gè)重要的變更代碼坊：Verkle、以太坊虛擬機(jī)物件格式（EOF）和他們決定將Verkle安排在布拉格升級(jí)之後，即大阪升級(jí)的EL升級(jí)中實(shí)施。同時(shí)，他們也同意在布拉格升級(jí)的同時(shí)繼續(xù)努力開發(fā)歷史耗電所需的模組網(wǎng)絡(luò)，被稱為Portal Network。關(guān)於下一個(gè)即將到來的以太坊升級(jí)Dencun，開發(fā)者表示他們將在下週四的ACDC電話會(huì)議上討論升級(jí)的主網(wǎng)啟動(dòng)日期。
Besu 1月6日主網(wǎng)事件
Besu 的開發(fā)者 Matt Nelson 詳細(xì)介紹了今年初在以太坊上發(fā)生的大約 70% Besu 節(jié)點(diǎn)故障的情況。Besu 團(tuán)隊(duì)在他們的部落格上分享了該事件的詳細(xì)事後分析。Nelson 解釋說，故障是由於 Besu Bonsai 狀態(tài)儲(chǔ)存格式中的一個(gè)錯(cuò)誤引起的，具體來說，是Bonsai 編碼狀態(tài)如何改變的問題。已經(jīng)推出了對(duì)Besu 用戶端的緊急修復(fù)，Nelson 強(qiáng)調(diào)了他對(duì)1 月6 日事件中EL 客戶端的多元由於以太坊節(jié)點(diǎn)營(yíng)運(yùn)商也運(yùn)行了其他客戶端，如Geth、Nethermind 和Erigon，Besu 節(jié)點(diǎn)的故障並沒有在實(shí)體上影響網(wǎng)路健康或乾擾網(wǎng)路活動(dòng)。
鄧存更新
以太坊基金會(huì)（EF）的開發(fā)者運(yùn)維工程師Parithosh Jayanthi分享了關(guān)於Sepolia硬分叉的最新動(dòng)態(tài)，該分叉於1月30日星期二發(fā)生。Jayanthi表示：「這是我們我們一次平穩(wěn)的分叉?？吹搅司W(wǎng)路的最終確認(rèn)，數(shù)據(jù)塊也準(zhǔn)確地出現(xiàn)在我們希望的位置。」Beiko提醒團(tuán)隊(duì)，Holesky硬分叉計(jì)劃在下週三，即2月7日激活。Holesky將是以太坊主網(wǎng)升級(jí)前的最後一個(gè)的公共以太坊測(cè)試網(wǎng)。
關(guān)於Dencun 升級(jí)除了Holesky 分叉之外需要進(jìn)一步測(cè)試的問題，Nethermind 開發(fā)者?ukasz Rozmej 表示，他們的團(tuán)隊(duì)正在調(diào)查他們客戶端中導(dǎo)致blob 內(nèi)存池增長(zhǎng)超出指定限制的一個(gè)錯(cuò)誤。在對(duì)Devnet-12 進(jìn)行進(jìn)一步測(cè)試調(diào)查時(shí)，Nethermind 團(tuán)隊(duì)向網(wǎng)路發(fā)送大量的blob 交易，注意到由於這個(gè)bug，驗(yàn)證者參與率下降了超過20%。該團(tuán)隊(duì)計(jì)劃在接下來的步驟中向Goerli 測(cè)試網(wǎng)路發(fā)送的blob 交易。坊以太基金會(huì)（EF）的開發(fā)者維運(yùn)工程師 Barnabas Busa 要求 Nethermind 團(tuán)隊(duì)在 Goerli 上測(cè)試流失限制增加之前進(jìn)行 blob 垃圾郵件等待。
除了 Nethermind 的錯(cuò)誤外，Prysm 開發(fā)者「Potuz」表示，他的團(tuán)隊(duì)正在調(diào)查有關(guān) Sepolia 的一個(gè)早期區(qū)塊鏈計(jì)劃的異?；顒?dòng)，該計(jì)劃不包含任何 blob 交易。
由於開發(fā)者需要與Dencun調(diào)查相關(guān)的這兩個(gè)未解決的問題，他們同意在下一次ACD電話會(huì)議之前暫時(shí)不確定升級(jí)的主網(wǎng)激活日期，該電話會(huì)議計(jì)劃於下週四，即2月8日舉行Potuz補(bǔ)充說，他希望在主網(wǎng)啟動(dòng)之前從Layer2 Rollup團(tuán)隊(duì)那裡得到更多關(guān)於Dencun升級(jí)的回饋。Beiko表示同意。
布拉格提案
在通話的大部分時(shí)間裡，開發(fā)者們討論了三個(gè)主要程式碼變更的實(shí)作細(xì)節(jié)：Verkle、EOF 和歷史故障。
由於Verkle的複雜性以及本身實(shí)施需要更多研究，Rozmej和其他開發(fā)者對(duì)在布拉格升級(jí)中承諾發(fā)布代碼變更表示了擔(dān)憂。Ballet同意Verkle可能不會(huì)在布拉格中準(zhǔn)備好實(shí)施，但他擔(dān)心如果不將Verkle計(jì)劃進(jìn)行升級(jí)，無論是布拉格還是大阪，客戶端團(tuán)隊(duì)都會(huì)沒有複雜的動(dòng)力去開發(fā)它。芭蕾舞表示，以太坊狀態(tài)每年大約增長(zhǎng)25%，開發(fā)者等待在主網(wǎng)上執(zhí)行Verkle的時(shí)間越長(zhǎng)，在Verkle過渡期間需要徹底改進(jìn)的舊資料精度多。
「在我看來，要交付還需要一年的時(shí)間，」Rozmej 說。
他們?cè)?2024 年第三季在測(cè)試網(wǎng)路上啟動(dòng) EOF，希望在 2024 年第四季的 Devcon 期間啟動(dòng)主網(wǎng)。「我認(rèn)為，在未來幾年內(nèi)，對(duì)於解決 EVM 的許多技術(shù)計(jì)劃來說，這些基本變更是關(guān)鍵的。所有關(guān)於『我們無法增加程式碼大小』等問題的抱怨，在EOF 的工作方式中都得到了解決，」Ferrin 表示。Erigon 開發(fā)者Andrew Ashikhmin 表示支持在布拉格中包括EOF。Ballet表示，他首先希望在Verkle 激活的測(cè)試網(wǎng)絡(luò)上運(yùn)行時(shí)看到EOF，以了解這兩個(gè)升級(jí)將如何相互影響。Reth 開發(fā)者Dragan Rakita 表示，他並不認(rèn)為兩者之間存在一定的依賴關(guān)係，並補(bǔ)充說：“總體來說，EOF 似乎更適合Verkle 跟蹤而不是傳統(tǒng)的EVM?！?/p>
啟動(dòng)歷史故障所需的工具，Geth 開發(fā)者「Lightclient」表示：「我們真的只需要繼續(xù)執(zhí)行規(guī)範(fàn)並開始嘗試讓能夠提供這些數(shù)據(jù)，因?yàn)橐?guī)範(fàn)本身，關(guān)於導(dǎo)出數(shù)據(jù)、驗(yàn)證數(shù)據(jù)、導(dǎo)入數(shù)據(jù)等好，但是在資料可用之前，我們實(shí)際上無法繼續(xù)透過P2P網(wǎng)路刪除資料?！筁ightclient補(bǔ)充說，一旦Portal上的資料可用並由網(wǎng)路上的資料開始提供服務(wù)，開發(fā)者應(yīng)該差不多等待一年才停止在以太坊的P2P層中提供這些數(shù)據(jù)的服務(wù)。雖然在P2P層上更新提供歷史區(qū)塊數(shù)據(jù)不需要硬分叉，但是將是客戶端團(tuán)隊(duì)希望一致完成的更新，最有可能是透過對(duì)以太坊坊Wire Protocol的升級(jí)來實(shí)現(xiàn)。
在討論完三個(gè)主要的程式碼更改後，開發(fā)者們討論瞭如何在主網(wǎng)上安排它們的實(shí)施。Lightclient鼓勵(lì)客戶端團(tuán)隊(duì)立即開始研究EIP 4444，它因?yàn)椴恍枰獙?duì)坊以太坊的核心協(xié)議進(jìn)行重大更改，並且對(duì)增強(qiáng)以太坊節(jié)點(diǎn)的資料負(fù)載具有重大益處。Lightclient表示，他將與Nethermind和Besu客戶端團(tuán)隊(duì)合作，啟動(dòng)歷史故障的參考工作。
Ashikhmin 指出，從 Erigon 團(tuán)隊(duì)的角度來看，歷史故障的實(shí)施將不得不等待幾個(gè)月，直到他們的 Erigon V3 版本發(fā)布，因?yàn)樗麄兊目蛻舳四壳皶?huì)重新執(zhí)行從以太坊起源開始的區(qū)塊，因此需要存取所有歷史區(qū)塊資料來完成此過程。Ashikhmin 補(bǔ)充說，他更傾向於在布拉格中包含EOF，但如果它與Verkle 存在兼容性問題，他在配電板升級(jí)中刪除它。
Beiko詢問是否有人反對(duì)將Verkle安排在大阪升級(jí)中。沒有反對(duì)意見。以太坊基金會(huì)研究員Ansgar Dietrichs建議，在可能超過一年的情況下，對(duì)大阪升級(jí)的範(fàn)圍保持靈活，對(duì)Verkle仍然需要進(jìn)一步的研究，以正確評(píng)估其在主網(wǎng)實(shí)施上的準(zhǔn)備。
其他事項(xiàng)
在通話的最後三分之一中，Beiko 簡(jiǎn)要介紹了 ACDE＃180 的最後三個(gè)事項(xiàng)。
在引擎 API 執(zhí)行指定客戶端版本 #517：這是一個(gè)旨在改進(jìn)驗(yàn)證人節(jié)點(diǎn)運(yùn)營(yíng)商使用的執(zhí)行層（EL）客戶端追蹤的開放 PR。目前，由於大多數(shù)驗(yàn)證人使用 MEV-Boost 軟體，無法透過分析區(qū)塊資料來確定節(jié)點(diǎn)運(yùn)營(yíng)商使用的EL 用戶端類型。因此，準(zhǔn)確報(bào)告EL 用戶端多樣性需要節(jié)點(diǎn)運(yùn)營(yíng)商自行報(bào)告。此PR 建議在節(jié)點(diǎn)的「塗鴉」欄位中預(yù)設(shè)嵌入用於運(yùn)行節(jié)點(diǎn)的客戶端和版本。這是一些CL 用戶端已經(jīng)實(shí)施的做法。Beiko 鼓勵(lì)客戶端團(tuán)隊(duì)查看此PR，並發(fā)表他們的意見。
EIP-7523空帳戶廢棄用：正如在ACDE＃173上基金會(huì)討論的那樣，有一個(gè)EIP旨在減少由空帳戶引起的坊以太測(cè)試網(wǎng)絡(luò)的技術(shù)債務(wù)。以太坊開發(fā)者Pawe? Bylica此EIP的下前面提出了問題。Beiko 鼓勵(lì)Bylica 在以太坊R&D Discord 頻道中分享這些問題。
EIP-7587 為 RIP 保留預(yù)編譯位址範(fàn)圍：正如在 ACDE＃178 上討論的那樣，開發(fā)者們計(jì)劃為 Layer-2 rollup 團(tuán)隊(duì)保留一組預(yù)編譯位址。為 rollups 保留預(yù)編譯位址範(fàn)圍的 EIP 正在進(jìn)入「最後通話」階段。Beiko 鼓勵(lì)開發(fā)者在該階段提出任何最後一刻的評(píng)論或?qū)IP 的反對(duì)意見。
對(duì)於下一次 ACDE 通話，Beiko 表示，開發(fā)者將專注於進(jìn)一步確定布拉格升級(jí)的範(fàn)圍。
