原文標題:《All Core Developers Execution Call #188 Writeup》
原文作者:Christine Kim
編按:
以太坊所有核心開發者共識電話(ACDE)每兩週舉行一次,主要討論和協調對以太坊執行層(EL)的更改。本次為 ACDE 第 188 次電話會議,本次會議上,在這次會議上,開發者們就以太坊執行層的變化進行了討論和協調。
會議涵蓋了許多重要議題,包括新增執行 API 功能、Geth 的最低優先小費要求、Pectra 開發網路 0 和 1 的討論、Pectra 分叉範圍以及歷史記錄過期等。開發者們就這些議題進行了深入的討論和交流,並就 Pectra 升級的範圍、時間表和具體實施細節達成了一些共識。
Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄,BlockBeasts 將原文編譯如下:
2024 年5 月23 日,以太坊開發人員齊聚Zoom 參加了All Core Developers Execution (ACDE) call #188 會議。 ACDE 電話會議是一個每兩週舉行一次的系列會議,由以太坊基金會協議支持主管 Tim Beiko 主持,開發人員在會上討論和協調對以太坊執行層(EL)的更改。本週,開發者們討論了以下內容:
· 為執行API 新增功能,使用戶能夠存取交易的「返回資料」(returndata)
· Geth 的最低優先小費要求
· Pectra Devnet 0 和1
· Pectra 分叉的範圍
· Portal Network 的歷史資料過期整合。
· 他們同意從 Pectra Devnet 0 中移除 EIP 3074,並在下一個以開發者為重點的 Pectra 升級測試網 Pectra Devnet 1 中包含 EIP 7702。
將返回資料(Returndata)加入交易收據
維護智能合約程式語言 Vyper 的開發者 Charles Cooper 提出,應該調整執行 API 中的一個端點,這樣使用者在取得交易收據時,也可以接收交易的回傳資料(returndata)。 Cooper 解釋說,目前開發者獲取返回資料的常用方法,如使用交易跟踪,並未標準化,也未在所有客戶端中普遍支援。根據 Reth 等用戶端團隊對其想法的回饋,Cooper 表示,另一個解決方案是建立執行 API 中的新端點,以取得交易的回傳資料(returndata)。開發者在電話會議中未能就此提案達成共識。 Beiko 建議開發者繼續在GitHub 上討論,並嘗試在會議之外異步解決此問題。
最低礦工小費要求
隨後,Geth 開發者Péter Szilágyi 提出了最近幾週用戶對Geth 用戶端預設設定的擔憂。自從EIP 1559 實施以來, Geth 用戶端總是強制執行交易的預設最低優先小費要求。合併後,預設的 1 gwei 優先小費未能正常工作,直到最近才被 Szilágyi 的團隊發現並修復。恢復了這個預設設定後,使用者發現使用Geth 客戶端建構的區塊比其他區塊明顯更空,因為它們排除了幾乎沒有優先小費的交易。這引發了對預設設定可能對區塊提議者和建構者動態產生負面影響的擔憂,因為它可能會導致對沒有優先費用的有效交易的延遲處理。
Nethermind 開發者 Tomasz K. Stańczak 表示,Geth 的預設最低優先小費要求是一個無關緊要的問題,協議開發者不應嘗試標準化或強制執行。 EF 研究員 Ansgar Dietrichs 建議降低預設的最低優先小費,因為目前以太坊的交易基礎費用非常低。其他開發者建議,將 Geth 中的預設最低優先小費設定為基礎費用的一個百分比,而不是固定金額。然而,Beiko 對此表示反對,他認為優先小費並不是為了作為交易被包含在區塊中的費用。它應該僅用於優先確保交易包含在下一個區塊中,使用基於基礎費用波動的預設最低優先小費可能會扭曲基礎費用的變化,因為部分價值會反映在交易的優先小費中。
Beiko 補充說,討論的另一個角度是如何鼓勵構建者創建零小費區塊並向提議者提供帶外支付作為補償。這種情況可能會在有或沒有預設最低優先小費要求的情況下發生,但設定預設值可能會形成規範,鼓勵建構者不要創建零小費區塊。 Szilágyi 表示,從某種意義上說,建構者是否應該在區塊中包含零小費交易是一個哲學問題。從網路角度來看,這些交易是有效的,因此應該包含在區塊中。然而,從財務動機的提議者角度來看,包含零小費交易在區塊中沒有經濟利益,因此不應該被包含。
開發者普遍認為 Geth 團隊應該設定他們認為最好的預設值。驗證節點運營商可以自由更改這個預設值,如果他們願意的話,或者使用其他執行層客戶端。
Pectra Devnet-0
以太坊基金會(EF)開發者營運工程師Parithosh Jayanthi 更新了Pectra 開發網路的情況。第一個開發網絡上週在肯亞名為Nyota Interop的以太坊協議開發者線下聚會上啟動。 Jayanthi 表示,開發網路包括所有執行層和共識層客戶端。然而,EIP 3074 尚未進行密集測試,並且存在需要修復的錯誤。客戶端團隊已經在準備第二個開發網路Pectra Devnet 1 的啟動,後者將包括對EIP 2935 實現的變更。
Pectra 範圍變更
開發者隨後討論了 Pectra 升級範圍的變更。獨立以太坊協議開發者 Danno Ferrin、Reth 開發者 Georgios Konstantopoulos 和 Solidity 團隊的代表都支持在 Pectra 中包含 EOF。 Geth 開發者 Marius van der Wijden 表示,他正在實施 EOF 規範。然而,他強調,由於 EOF 的複雜性,包含 EOF 肯定會延遲 Pectra 升級的啟動。 Lodestar 和 EthereumJS 開發者 Gajinder Singh 在 Zoom 聊天中提到,開發者應該專注於發布目前版本的 Pectra,而不是擴大升級的範圍。 EF 研究員 Alex Stokes 和 Piper Merriam 同意 Singh 的看法。
在討論 EOF 之後,開發者討論了 EIP 7702 的進展。 EIP 7702 由以太坊聯合創始人Vitalik Buterin 提出,作為EIP 3074 的替代方案。關於 EIP 7702 的重要細節,如其可撤銷設計,仍然未解決。一位名為「dror」的開發者在Zoom 聊天中寫道:「EIP 7002 是EIP 3074 的一個版本,之前只接受帶有nonce 和鏈ID(chainID)的版本。現在這些被移除了,我們需要重新討論原因。 Erigon 開發者 Andrew Ashikhmin 強調,需要有一種方法讓用戶繞過錢包自行撤銷授權。
Beiko 建議在一個單獨的小組會議中繼續討論 EIP 7002 的實施細節。同時,開發者同意從 Devnet 0 移除 EIP 3074,並在 Devnet 1 中加入 EIP 7702。
另外兩個計畫加入 Pectra 的 EIP 是 EIP 7623(增加 calldata 成本)和 EIP 7212(支援 secp256r1 曲線的預編譯)。 EF 研究員 Toni Wahrstätter 分享了關於 EIP 7623 的最新進展,智能合約錢包開發者 Ulaş Erdoğan 分享了關於 EIP 7212 的最新進展。開發者並未就這兩個 EIP 是否應納入 Pectra 達成一致。
Pectra 時間表預期
Konstantopoulos 提到開發者何時應在以太坊主網上啟動 Pectra 升級。在通話前分享的一份文件中,Reth 用戶端團隊寫道,在 2024 年底之前嘗試發布升級的「價值不大」,開發者應準備在 2025 年初發布升級。 EF Panda Ops 團隊(EF 開發者營運團隊的子集)也在通話前分享了一份文件,表達了他們對Pectra 時間表和範圍的看法。他們建議將 Pectra 分成兩個分叉,一個在今年激活,另一個包括 MaxEB、EOF 和可能的 peerDAS,在明年初激活。 Jayanthi 表示,EF Panda Ops 團隊在觀點上並不統一,但他個人認為應該將 Pectra 的範圍分成兩個分叉。他指出,Pectra 升級的邊緣情況和 EIP 互動尚未測試。
EF Solidity 開發者Alex Beregszaszi 表示擔憂,如果EOF 未被納入Pectra 中,這些程式碼變更將永遠不會被包含在以太坊的升級中。 Geth 開發者 Marius van der Wijden 和 Guillaume Ballet 對此表示反對,認為 EOF 的好處足夠顯著,即使再延遲幾個分叉,其有用性仍然存在。
Beiko 建議先就如何優先處理 peerDAS 和 blob 大小增加達成共識,然後再確定升級的其餘範圍。他建議下週參加 All Core Developers Consensus(ACDC)會議的開發者集中討論這個主題。他希望開發者在下一次 ACDE 會議上準備好最終確定 Pectra 的範圍。
Portal Network 與歷史過期
最後,Merriam 指出Portal Network 團隊已經準備好與協議開發者合作,以便與Pectra 並行發布一個歷史過期版本。更多關於Portal Network 的資訊可以在此處找到。
區塊財經BOTD – 廣播組
追蹤BOTD Instagram,獲取最新區塊鏈消息
▸https://www.instagram.com/botd_news/
免責聲明:本文內容僅供參考,投資人應獨立判斷,審慎投資,並自負風險,本文不提供或嘗試遊說觀眾做交易或投資之依據。