以太坊開發者在ACDE電話會議上討論了Pectra Devnet 0和EIP 3074實施準備。各客戶團隊分享了他們在準備Pectra Devnet 0方面的進展，討論了EIP 3074規範的修改建議和測試進展。也提到了其他重要的內容，例如Pectra升級中可能的程式碼變更和以太坊EIP流程的變更如何受L2/RIP流程影響。開發者們也就EIP是否有足夠社群支援進行了討論。最後，他們考慮了新的RIP流程對以太坊EIP的影響，討論了L2上的功能實施，以及是否對未來EIP進行限制。
編按：
以太坊所有核心開發者協商電話（ACDE）每週一召開一次，主要討論和協調以太坊執行層（EL）的變更。本次為ACDE 第186 次電話會議，在次本會議上，開發人員討論了Pectra Devnet 0 和EIP 3074 實施的準備工作。他們詳細介紹了各個客戶團隊在準備Pectra Devnet 0 方面的進展，並討論了關於EIP 3074 規範的修改建議以及相關的測試進展。
另外，本文也提及了其他重要的珊瑚，例如對Pectra 升級中可能包含的其他程式碼變更的討論，以及對以太坊EIP 流程的變更如何受L2/RIP 流程影響的討論。 Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了記錄，BlockBeasts 將詳細編譯如下：
2024年4月25日，以太坊開發人員齊聚Zoom參加了All Core 開發工程師s Execution (ACDE) call #186會議。 ACDE電話會議是一個每週舉行一次的系列會議，由以太坊基金會協議支持主管Tim Beiko 主持，開發人員在會上討論和協調了對以太執行坊層（EL）的更改。本週，開發人員討論了Pectra Devnet 0 和EIP 3074 實施的準備工作。他們也討論了應考慮將哪些其他EIP引入Pectra升級，以及考慮到以太坊「Rollup以中心的路線圖」對治理變革的廣泛思考。
Pectra Devnet 0 最新進展
Beiko 在電話會議上要求客戶團隊分享Pectra Devnet 0 的最新進展。 Nethermind 團隊的Marek Moraczyński 表示，Nethermind 已經實現了所有Pectra EIP，正在對其進行測試工作。 Besu 團隊的Justin Florentine 表示，Besu 正在實施Pectra EIP ，並與他們一起準備Devnet 0 的推出。 Erigon 團隊的Andrew Ashikhmin 說，「我不確定Erigon 是否準備好套件Devnet 0 的EIP 的數量，部分原因是這些EIP 的規範仍在不斷變化，而且Erigon 用戶端正在到新的主要版本Erigon 3，這佔用了團隊的資源和時間。 Geth 團隊的「Lightclient」表示，Geth 距離為Devnet 0 做好準備還有「幾天的時間」。 EthereumJS 團隊的Gajinder Singh 表示，Ethereum JS 也支持Devnet 0「做好準備」。
EIP-7685
Lightclient 合併了EIP 7685，它創建了一個通用框架，用於將EL 觸發的請求儲存到共識層(CL) 及其對EIP 6110 和7002 的影響。 Beiko 表示，開發人員應該在其Devnet 0 版本中加入此EIP，並不斷改進Pectra EIP。
在測試方面，EF 測試團隊的Mario Vega 表示，EIP 6110 和2537 的測試已經完成，EIP 7002 和EIP 2935 的測試將在本週或下週完成。 EIP 3074 的測試尚未為Devnet 0 準備好。研究人員Antonio Sanso 表示，EIP 2537 規格已更新，並且GitHub 儲存庫中新增了新的測試支持，他建議大家都去GitHub 上看看。 EF 研究員Hsiao Wei Wang 指出CL 規範測試支援中存在錯誤，因此錯誤很快就被修改了，並且發布了新版本。
EIP-3074 的更新
本週的ACDE 對EIP 3074 規範的呼叫提出了幾項變更。 Ahmad Mazen Bitar 建議更改EIP 3074 的行為，以允許在AUTHCALL 之前進行DELEGATECALL，這樣可以擴大EIP 的範例。區塊鏈錢包網路ZeroDev 的創始人兼理念Derek Jiang 建議創建一個“noncemanager”，以便在需要時促進全球撤銷AUTH 訊息和其他更改。一些參加電話會議的開發人員認為應該推遲對EIP 3074 的更改，因為這將大大增加其實現的入口。
Beiko建議開發人員在單獨的分組會議上討論了EIP 3074的國防變更。他指出，為了有足夠的時間在Pectra中實施EIP 3074，開發人員應該嘗試「在未來一兩個月內」確定其最終規範。 Lightclient同意組織EIP 3074分組會議。對於Devnet 0，Beiko確認客戶團隊應該在不進行任何更改的情況下實施EIP 3074，即使開發人員可能決定未來的devnet以不同的方式實施EIP或從升級中將其全部刪除。
除了EIP 3074 的實作細節之外，開發者們也認真討論了EIP 是否有足夠的社群支援。一位顯示為「Siri」的開發人員在電話會議中表示擔心，「EIP 3074 原則上很糟糕，會減慢我們實現完全帳戶抽象的速度」。 Beiko 回應稱，根據以太坊魔術師和ACD 通話討論，客戶團隊似乎支持EIP 3074，而不是其他與帳戶抽象(AA) 相關的提議。 Beiko 表示：「這似乎是短期內最有思想的倡議，我們實際上可以在下一個分叉中改善EOA 的狀態。」為此Siri 認為客戶團隊不應該孤立地做到這一點。 「我們應該決定其他利益相關者的意見，」Siri說道，並補充說，「我們不想轉向製造有爭議的硬分叉領域。…我認為最好了解其他利益相關者的看法以及他們如何看待這個提議。
Beiko 和Siri 也在ACD 通話中討論如何為EIP 建立更廣泛的共識。 Chiang 建議先召開EIP 3074 分組會議，深入討論EIP 的技術規範，然後是否應該保留在Pectra 升級中。 EF 研究員Ansgar Dietrichs 表示“我們應該明白，除非我們取得足夠的進展，否則EIP 3074 將被撤回。”
以太坊聯合創始人Vitalik Buterin補充說，“未來幾年用戶的帳戶功能即將發生變化，特別是外部擁有帳戶（EOA）。激活帳戶抽象相關的EIP，例如EIP 3074等。”
其他Pectra 提案
開發人員繼續討論應考慮將哪些其他程式碼變更包含在Pectra 升級中。 Geth 開發者Marius van der Wijden 表示，這應該取決於像EOF 這樣複雜度更高的EIP 是否會進入Pectra。 ，那麼會導致分叉洪水。如果我們不包括EOF，也許我們可以包括更多內容，」van der Wijden 說。
Siri 對尚未安全審核就將EIP 3074 納入Pectra 表示擔憂。 Beiko 建議擱置此討論，直到EIP 3074 的規範最終確定。
Bitar 表示，他希望看到Pectra 中加入EIP 7212。 EIP 7212 將建立一個新的預編譯，在secp256r1 橢圓形橢圓中執行簽名驗證。這可以與支援用戶生物特徵識別的硬體設備一起使用。 Bitar 表示，支援生物辨識來簽署以太坊交易將是用戶體驗的重大改進。阿希赫明表示，他也支持這項提議。 Dietrichs 指出，這是唯一一個透過「Rollup 改進提案」（RIP）流程被Layer-2 Rollups批准實施的方案。
其他開發者包括Dietrichs、van der Wijden 和Moraczyński 都表達了對EIP 7623 的支持，這將增加通話資料的成本，從而限制最大區塊大小。 Beiko 建議將EIP 7623 和EIP 7212 標記為「考慮納入」或CFI 進入Pectra，並在Devnet 0 啟動後重新佔用客戶端通道的頻寬以支援這兩個改進提議。
關於與將EL 的序列化方法更新為SSZ 相關的EIP 捆包，van der Wijden 表示擔心這些在Pectra 中運輸太困難。他在Geth 團隊Guillaume Ballet 的同事也同意這項評估。 Buterin 插話道，「至少更新交易收據的序列化方法將具有超越以太坊本身的「價值重大」，因為它消除了以太坊上構建的第2 層Rollup 的額外安全審計開銷。 」。 SSZ 相關EIP 的主要支持者、來自Nimbus團隊的Etan Kissling 沒有出席電話會議，但他在GitHub 上寫了一份詳細的解釋，講述了為什麼這些代碼更改很重要，並且應該考慮將其包含在Pectra 中。
開發人員也重新討論了EOF。獨立以太坊協議開發人員Danno Ferrin 表示，EOF 團隊正在針對程式碼變更進行EL 規格測試。 EVMOne 和Reth 是兩個EL 用戶端團隊，據報告已經完成了EOF 實作。 Ferrin 表示，Geth 團隊在實施方面取得了「良好進展」。 Ferrin 補充說，Ballet 正在與Solidity 團隊的「Daniel」合作，以解決對EOF 和Verkle 填充的擔憂。
Ballet 指出，根據他與Daniel 和Dietrichs 等其他開發人員的對話，很難在不破壞其目的的情況下縮小EOF 的範圍，並為開發人員今後實現另一組類似EOF 的程式碼變更創造更多工作。
一款名為「Charles C」的螢幕的開發人員建議尋找一種透過Side Car 機制（例如用於Blob 事務的機制）輕鬆迭代地實現EOF 的方法，而不是在小型或大型EOF 升級之間進行選擇。 Dietrichs 在聊天中詢問，如果降低Pectra 的EOF 複雜性，客戶團隊是否會對它有更大的興趣。 Ipsilon 團隊指出，導致EOF 中最高複雜性的程式碼變更（例如「TX create」）已經解決，刪除「EOF create」等功能的特定請求不會很大程度上降低EOF 複雜性。作為背景，Ipsilon 是EF 資助的EVM 研發團隊的名稱。 Beiko 建議開發人員在反覆出現的EOF 分組討論中整體繼續討論EOF 實現。
ACD/EIP 和L2/RIP
作為ACDE #186 討論的最後一個主題，開發人員討論了考慮新的RIP 流程對以太坊EIP 的變更。 Dietrichs 指出流程，自行開發人員啟動Rollup 協調、RollCall 和RIP 流程的會議系列以來，已經六個過去了關於這些流程將如何以及應該如何影響以太坊EIP流程，目前還存在一些懸而未決的問題。 Dietrichs表示，L2中釋放的一個研究問題是，對於Rollup而言，與以太坊虛擬機（EVM） ）的長期相當於是否是可取的。他還補充說，一個懸而未決的問題是，L2上實施的變更最終會在某種程度上影響坊以太坊第1層的協議決策。
Geth 開發人員Péter Szilágyi 表示，L2 上提供的某些功能可能不適合在L1 上提供，而在某些情況下，即使遵循L2 上提供的功能，L2 之間也可能會有所不同，這可能會導致以太坊協議開發人員帶來困惑。 EF研究員Carl Beekhuizen指出，RollCalls和RIP流程不需要以太坊協議開發人員在L2上發布任何功能，而是改善Rollups和以太坊開發人員之間的通信，以便避免像Szilágyi 描述了那樣令人困惑的情況。 Van der Wijden 對協議開發人員花時間支援在L2 上實施的變更表示擔憂，而這些變更會變得過時或最終不必要，因為L2 本身會關閉或停止使用。
對於這些擔憂，Dietrichs 表示：「我人們一直認為Layer 2 可以進行實驗並變得更加瘋狂。我認為在實踐中我們看到的是，他們中的大多數人決定不這樣做，甚至或至少可能開始這樣做，然後隨著時間的流逝，大多數人都停止了。生態發展的最佳方式，我們至少缺乏Layer 2 明確的指導和溝通，就像這裡的最佳前進道路一樣。
資訊來源：0x資訊編譯自網際網路。版權歸作者Christine Kim所有，未經許可，不得轉載