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ā)者們在電話會議中未能就此提案達成共識。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)生負面影響的擔(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 尚未進行密集測試，并且存在需要修復(fù)的錯誤?？蛻舳藞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 的進展。EIP 7702 由以太坊聯(lián)合創(chuàng)始人 Vitalik Buterin 提出，作為 EIP 3074 的替代方案。關(guān)于 EIP 7702 的重要細節(jié)，如其可撤銷設(shè)計，仍然未解決。一位名為「dror」的開發(fā)者在 Zoom 聊天中寫道：「EIP 7002 是 EIP 3074 的一個版本，之前只接受帶有 nonce 和鏈 ID（chainID）的版本?，F(xiàn)在這些被移除了，我們需要重新討論原因。我建議重新開始討論這些限制。」Besu 開發(fā)者 Daniel Lehrner 建議向錢包開發(fā)者獲取更多關(guān)于 EIP 7702 設(shè)計的意見。Erigon 開發(fā)者 Andrew Ashikhmin 強調(diào)，需要有一種方法讓用戶繞過錢包自行撤銷授權(quán)。

?

Beiko 建議在一個單獨的小組會議中繼續(xù)討論 EIP 7002 的實施細節(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 的最新進展，智能合約錢包開發(fā)者 Ula? Erdo?an 分享了關(guān)于 EIP 7212 的最新進展。開發(fā)者沒有就這兩個 EIP 是否應(yīng)納入 Pectra 達成一致。

?

Pectra 時間表預(yù)期

?

Konstantopoulos 提到開發(fā)者應(yīng)何時在以太坊主網(wǎng)上激活 Pectra 升級。在通話前分享的一份文件中，Reth 客戶端團隊寫道，在 2024 年底之前嘗試發(fā)布升級的「價值不大」，開發(fā)者應(yīng)準(zhǔn)備在 2025 年初發(fā)布升級。EF Panda Ops 團隊（EF 開發(fā)者運營團隊的一個子集）也在通話前分享了一份文件，表達了他們對 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 中，這些代碼更改將永遠不會被包含在以太坊的升級中。Geth 開發(fā)者 Marius van der Wijden 和 Guillaume Ballet 對此表示反對，認(rèn)為 EOF 的好處足夠顯著，即使再延遲幾個分叉，其有用性仍然存在。

?

Beiko 建議首先就如何優(yōu)先處理 peerDAS 和 blob 大小增加達成共識，然后再確定升級的其余范圍。他建議下周參加 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 的更多信息可以在此處找到。