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

原文標(biāo)題：All Core Developers Execution Call #188 Writeup

原文作者：Christine Kim

原文來源： galaxy

編譯：Luccy，BlockBeats

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

最低礦工小費要求

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

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

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

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

Pectra Devnet-0

以太坊基金會（EF）開發(fā)者運營工程師 Parithosh Jayanthi 更新了 Pectra 開發(fā)網(wǎng)絡(luò)的情況。第一個開發(fā)網(wǎng)絡(luò)上周在肯尼亞名為 Nyota Interop的以太坊協(xié)議開發(fā)者線下聚會上啟動。Jayanthi 表示，開發(fā)網(wǎng)絡(luò)包括所有執(zhí)行層和共識層客戶端。然而，EIP 3074 尚未進(jìn)行密集測試，并且存在需要修復(fù)的錯誤。客戶端團隊已經(jīng)在準(zhǔn)備第二個開發(fā)網(wǎng)絡(luò) 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 的復(fù)雜性，包含 EOF 肯定會延遲 Pectra 升級的激活。Lodestar 和 EthereumJS 開發(fā)者 Gajinder Singh 在 Zoom 聊天中提到，開發(fā)者應(yīng)該專注于發(fā)布當(dāng)前版本的 Pectra，而不是擴大升級的范圍。EF 研究員 Alex Stokes 和 Piper Merriam 同意 Singh 的看法。

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

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

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

Pectra 時間表預(yù)期

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

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

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

Portal Network 和歷史過期

最后，Merriam 指出 Portal Network 團隊已經(jīng)準(zhǔn)備好與協(xié)議開發(fā)者合作，以便與 Pectra 并行發(fā)布一個歷史過期版本。有關(guān) Portal Network 的更多信息可以在此處找到。