摘要：本周，開發者們討論了以下內容：·向執行API添加新功能，使用戶能夠訪問交易的「返回數據」（returndata）·Geth的最低優先小費要求·PectraDevnet0和1·Pectra分叉的范圍·PortalNetwork的歷史數據過期集成。...

原文標題：All Core Developers Execution Call #188 Writeup

原文作者：Christine Kim

原文來源： galaxy

編譯：Luccy，BlockBeats

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）的版本。現在這些被移除了，我們需要重新討論原因。我建議重新開始討論這些限制。」Besu 開發者 Daniel Lehrner 建議向錢包開發者獲取更多關于 EIP 7702 設計的意見。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 的更多信息可以在此處找到。