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

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

原文作者：Christine Kim

原文來源： galaxy

編譯：Luccy，BlockBeats

編者按：以太坊所有核心開發(fā)者共識電話（ACDE）每兩周舉行一次，主要討論和協(xié)調(diào)對以太坊執(zhí)行層（EL）的更改。本次為 ACDE 第 188 次電話會議，本次會議上，在這次會議上，開發(fā)者們就以太坊執(zhí)行層的變化進行了討論和協(xié)調(diào)。會議涵蓋了許多重要議題，包括新增執(zhí)行 API 功能、Geth 的最低優(yōu)先級小費要求、Pectra 開發(fā)網(wǎng)絡 0 和 1 的討論、Pectra 分叉范圍以及歷史記錄過期等。開發(fā)者們就這些議題進行了深入的討論和交流，并就 Pectra 升級的范圍、時間表和具體實施細節(jié)達成了一些共識。Galaxy Digital 研究副總裁 Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2024 年 5 月 23 日，以太坊開發(fā)人員齊聚 Zoom 參加了 All Core Developers Execution (ACDE) call #188 會議。ACDE 電話會議是一個每兩周舉行一次的系列會議，由以太坊基金會協(xié)議支持主管 Tim Beiko 主持，開發(fā)人員在會上討論和協(xié)調(diào)對以太坊執(zhí)行層（EL）的更改。本周，開發(fā)者們討論了以下內(nèi)容：

· 向執(zhí)行 API 添加新功能，使用戶能夠訪問交易的「返回數(shù)據(jù)」（returndata）

· Geth 的最低優(yōu)先小費要求

· Pectra Devnet 0 和 1

· Pectra 分叉的范圍

· Portal Network 的歷史數(shù)據(jù)過期集成。

· 他們同意從 Pectra Devnet 0 中移除 EIP 3074，并在下一個以開發(fā)者為重點的 Pectra 升級測試網(wǎng) Pectra Devnet 1 中包含 EIP 7702。

將返回數(shù)據(jù)（Returndata）添加到交易收據(jù)

維護智能合約編程語言 Vyper 的開發(fā)者 Charles Cooper 提出，應該調(diào)整執(zhí)行 API 中的一個端點，這樣用戶在獲取交易收據(jù)時，也可以接收交易的返回數(shù)據(jù)（returndata）。Cooper 解釋說，目前開發(fā)者獲取返回數(shù)據(jù)的常用方法，如使用交易跟蹤，并未標準化，也未在所有客戶端中普遍支持。根據(jù) Reth 等客戶端團隊對其想法的反饋，Cooper 表示，另一種解決方案是創(chuàng)建執(zhí)行 API 中的一個新端點，以獲取交易的返回數(shù)據(jù)（returndata）。開發(fā)者們在電話會議中未能就此提案達成共識。Beiko 建議開發(fā)者繼續(xù)在 GitHub 上討論，并嘗試在會議之外異步解決此問題。

最低礦工小費要求

隨后，Geth 開發(fā)者 Péter Szilágyi 提出了最近幾周用戶對 Geth 客戶端默認設置的擔憂。自從 EIP 1559實施以來，Geth 客戶端總是強制執(zhí)行交易的默認最低優(yōu)先小費要求。合并后，默認的 1 gwei 優(yōu)先小費未能正常工作，直到最近才被 Szilágyi 的團隊發(fā)現(xiàn)并修復。恢復了這一默認設置后，用戶發(fā)現(xiàn)使用 Geth 客戶端構建的區(qū)塊比其他區(qū)塊明顯更空，因為它們排除了幾乎沒有優(yōu)先小費的交易。這引發(fā)了對默認設置可能對區(qū)塊提議者和構建者動態(tài)產(chǎn)生負面影響的擔憂，因為它可能會導致對沒有優(yōu)先費用的有效交易的延遲處理。

Nethermind 開發(fā)者 Tomasz K. Stańczak 表示，Geth 的默認最低優(yōu)先小費要求是一個無關緊要的問題，協(xié)議開發(fā)者不應嘗試標準化或強制執(zhí)行。EF 研究員 Ansgar Dietrichs 建議降低默認的最低優(yōu)先小費，因為目前以太坊的交易基礎費用非常低。其他開發(fā)者建議，將 Geth 中的默認最低優(yōu)先小費設定為基礎費用的一個百分比，而不是固定金額。然而，Beiko 對此表示反對，他認為優(yōu)先小費并不是為了作為交易被包含在區(qū)塊中的費用。它應該僅用于優(yōu)先確保交易被包含在下一個區(qū)塊中，使用基于基礎費用波動的默認最低優(yōu)先小費可能會扭曲基礎費用的變化，因為部分價值會反映在交易的優(yōu)先小費中。

Beiko 補充說，討論的另一個角度是如何鼓勵構建者創(chuàng)建零小費區(qū)塊并向提議者提供帶外支付作為補償。這種情況可能會在有或沒有默認最低優(yōu)先小費要求的情況下發(fā)生，但設置默認值可能會形成規(guī)范，鼓勵構建者不要創(chuàng)建零小費區(qū)塊。Szilágyi 表示，從某種意義上說，構建者是否應該在區(qū)塊中包含零小費交易是一個哲學問題。從網(wǎng)絡角度來看，這些交易是有效的，因此應該被包含在區(qū)塊中。然而，從財務動機的提議者角度來看，包含零小費交易在區(qū)塊中沒有經(jīng)濟利益，因此不應該被包含。

開發(fā)者普遍認為 Geth 團隊應該設置他們認為最好的默認值。驗證節(jié)點運營者可以自由更改這個默認值，如果他們愿意的話，或者使用其他執(zhí)行層客戶端。

Pectra Devnet-0

以太坊基金會（EF）開發(fā)者運營工程師 Parithosh Jayanthi 更新了 Pectra 開發(fā)網(wǎng)絡的情況。第一個開發(fā)網(wǎng)絡上周在肯尼亞名為 Nyota Interop的以太坊協(xié)議開發(fā)者線下聚會上啟動。Jayanthi 表示，開發(fā)網(wǎng)絡包括所有執(zhí)行層和共識層客戶端。然而，EIP 3074 尚未進行密集測試，并且存在需要修復的錯誤。客戶端團隊已經(jīng)在準備第二個開發(fā)網(wǎng)絡 Pectra Devnet 1 的啟動，后者將包括對EIP 2935 實現(xiàn)的更改。

Pectra 范圍更改

開發(fā)者隨后討論了 Pectra 升級范圍的變化。獨立以太坊協(xié)議開發(fā)者 Danno Ferrin、Reth 開發(fā)者 Georgios Konstantopoulos 和 Solidity 團隊的代表都支持在 Pectra 中包含 EOF。Geth 開發(fā)者 Marius van der Wijden 表示，他正在實施 EOF 規(guī)范。然而，他強調(diào)，由于 EOF 的復雜性，包含 EOF 肯定會延遲 Pectra 升級的激活。Lodestar 和 EthereumJS 開發(fā)者 Gajinder Singh 在 Zoom 聊天中提到，開發(fā)者應該專注于發(fā)布當前版本的 Pectra，而不是擴大升級的范圍。EF 研究員 Alex Stokes 和 Piper Merriam 同意 Singh 的看法。

在討論 EOF 之后，開發(fā)者討論了 EIP 7702 的進展。EIP 7702由以太坊聯(lián)合創(chuàng)始人 Vitalik Buterin 提出，作為 EIP 3074 的替代方案。關于 EIP 7702 的重要細節(jié)，如其可撤銷設計，仍然未解決。一位名為「dror」的開發(fā)者在 Zoom 聊天中寫道：「EIP 7002 是 EIP 3074 的一個版本，之前只接受帶有 nonce 和鏈 ID（chainID）的版本。現(xiàn)在這些被移除了，我們需要重新討論原因。我建議重新開始討論這些限制。」Besu 開發(fā)者 Daniel Lehrner 建議向錢包開發(fā)者獲取更多關于 EIP 7702 設計的意見。Erigon 開發(fā)者 Andrew Ashikhmin 強調(diào)，需要有一種方法讓用戶繞過錢包自行撤銷授權。

Beiko 建議在一個單獨的小組會議中繼續(xù)討論 EIP 7002 的實施細節(jié)。同時，開發(fā)者同意從 Devnet 0 中移除 EIP 3074，并在 Devnet 1 中加入 EIP 7702。

另外兩個計劃加入 Pectra 的 EIP 是 EIP 7623（增加 calldata 成本）和 EIP 7212（支持 secp256r1 曲線的預編譯）。EF 研究員 Toni Wahrst?tter 分享了關于 EIP 7623 的最新進展，智能合約錢包開發(fā)者 Ula? Erdo?an 分享了關于 EIP 7212 的最新進展。開發(fā)者沒有就這兩個 EIP 是否應納入 Pectra 達成一致。

Pectra 時間表預期

Konstantopoulos 提到開發(fā)者應何時在以太坊主網(wǎng)上激活 Pectra 升級。在通話前分享的一份文件中，Reth 客戶端團隊寫道，在 2024 年底之前嘗試發(fā)布升級的「價值不大」，開發(fā)者應準備在 2025 年初發(fā)布升級。EF Panda Ops 團隊（EF 開發(fā)者運營團隊的一個子集）也在通話前分享了一份文件，表達了他們對 Pectra 時間表和范圍的看法。他們建議將 Pectra 分成兩個分叉，一個在今年激活，另一個包括 MaxEB、EOF 和可能的 peerDAS，在明年初激活。Jayanthi 表示，EF Panda Ops 團隊在觀點上并不統(tǒng)一，但他個人認為應將 Pectra 的范圍分成兩個分叉。他指出，Pectra 升級的邊緣情況和 EIP 交互尚未測試。

EF Solidity 開發(fā)者 Alex Beregszaszi 表示擔憂，如果 EOF 未被包括在 Pectra 中，這些代碼更改將永遠不會被包含在以太坊的升級中。Geth 開發(fā)者 Marius van der Wijden 和 Guillaume Ballet 對此表示反對，認為 EOF 的好處足夠顯著，即使再延遲幾個分叉，其有用性仍然存在。

Beiko 建議首先就如何優(yōu)先處理 peerDAS 和 blob 大小增加達成共識，然后再確定升級的其余范圍。他建議下周參加 All Core Developers Consensus（ACDC）會議的開發(fā)者集中討論這個話題。他希望開發(fā)者在下一次 ACDE 會議上準備好最終確定 Pectra 的范圍。