Summary of the latest Ethereum core developer meeting: Agreed to remove EIP 3074, including EIP 7702

Original title: 《All Core Developers Execution Call #188 Writeup》
Original author: Christine Kim
Original translation: Lucy, BlockBeats

Editor's note:
The Ethereum All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 188th ACDE call, at which developers discussed and coordinated changes to the Ethereum Execution Layer.

The meeting covered many important topics, including the addition of new execution API features, Geth's minimum priority tip requirements, discussions on Pectra development networks 0 and 1, Pectra fork range, and historical record expiration. Developers had in-depth discussions and exchanges on these topics and reached some consensus on the scope, timeline, and specific implementation details of the Pectra upgrade.

Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the key points of the meeting, and BlockBeasts compiled the original text as follows:

On May 23, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #188. The ACDE call is a biweekly series of meetings hosted by Tim Beiko, head of protocol support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed the following:

· Adding new features to the execution API that enable users to access the "return data" of transactions

· Minimum priority tip requirements for Geth

· Pectra Devnet 0 and 1

· The scope of the Pectra fork

· Historical data expiration integration for the Portal Network.

· They agreed to remove EIP 3074 from Pectra Devnet 0 and include EIP 7702 in the next developer-focused Pectra upgrade testnet, Pectra Devnet 1.

Add Returndata to Transaction Receipts

Charles Cooper, a developer who maintains the smart contract programming language Vyper, proposed that an endpoint in the execution API should be adjusted so that users can also receive the return data of a transaction when they get the transaction receipt. Cooper explained that the common methods for developers to get return data, such as using transaction tracking, are not standardized and not universally supported in all clients. Based on feedback from client teams such as Reth on his ideas, Cooper said that another solution would be to create a new endpoint in the execution API to get the return data of a transaction. Developers failed to reach a consensus on this proposal during the conference call. Beiko suggested that developers continue to discuss it on GitHub and try to resolve this issue asynchronously outside of the meeting.

Minimum miner tip requirements

Subsequently, Geth developer Péter Szilágyi raised concerns about the default settings of the Geth client in recent weeks. Since the implementation of EIP 1559, the Geth client has always enforced a default minimum priority tip requirement for transactions. After the merge, the default 1 gwei priority tip did not work properly until recently discovered and fixed by Szilágyi's team. After reverting to this default, users found that blocks built with the Geth client were significantly emptier than other blocks because they excluded transactions with little to no priority tips. This raises concerns that the default setting could negatively impact block proposer and builder dynamics, as it could cause delayed processing of valid transactions without priority fees.

Nethermind developer Tomasz K. Stańczak said that Geth's default minimum priority tip requirement is a non-issue that protocol developers should not try to standardize or enforce. EF researcher Ansgar Dietrichs suggested lowering the default minimum priority tip because Ethereum's transaction base fee is currently very low. Other developers have suggested setting the default minimum priority tip in Geth as a percentage of the base fee, rather than a fixed amount. However, Beiko disagreed, arguing that the priority tip is not intended to be a fee for a transaction to be included in a block. It should only be used to prioritize transactions to be included in the next block, and using a default minimum priority tip based on base fee fluctuations may distort changes in the base fee because part of the value is reflected in the priority tip of the transaction.

Beiko added that another angle of the discussion is how to encourage builders to create zero-tip blocks and provide out-of-band payments to proposers as compensation. This could happen with or without a default minimum priority tip requirement, but setting a default value could form a norm that encourages builders not to create zero-tip blocks. Szilagyi said that in some sense, whether builders should include zero-tip transactions in blocks is a philosophical question. From the network perspective, these transactions are valid and therefore should be included in blocks. However, from the perspective of financially motivated proposers, there is no financial benefit to including zero-tip transactions in blocks and therefore they should not be included.

Developers generally agreed that the Geth team should set a default that they believe is best. Validator operators are free to change this default if they wish, or use other execution layer clients.

Pectra Devnet-0

Parithosh Jayanthi, developer operations engineer at the Ethereum Foundation (EF), updated on the status of the Pectra development network. The first development network was launched last week at an offline gathering of Ethereum protocol developers in Kenya called Nyota Interop . Jayanthi said the development network includes all execution layer and consensus layer clients. However, EIP 3074 has not been intensively tested and there are bugs that need to be fixed. The client team is already preparing for the launch of the second development network, Pectra Devnet 1, which will include changes to the EIP 2935 implementation .

Pectra Scope Changes

Developers then discussed changes to the scope of the Pectra upgrade. Independent Ethereum protocol developer Danno Ferrin, Reth developer Georgios Konstantopoulos, and representatives from the Solidity team all supported the inclusion of EOF in Pectra. Geth developer Marius van der Wijden said he was implementing the EOF specification. However, he stressed that including EOF would definitely delay the activation of the Pectra upgrade due to its complexity. Lodestar and EthereumJS developer Gajinder Singh mentioned in a Zoom chat that developers should focus on releasing the current version of Pectra instead of expanding the scope of the upgrade. EF researchers Alex Stokes and Piper Merriam agreed with Singh.

After the discussion of EOF, developers discussed the progress of EIP 7702. EIP 7702 was proposed by Ethereum co-founder Vitalik Buterin as an alternative to EIP 3074. Important details about EIP 7702, such as its revocable design, remain unresolved. A developer named "dror" wrote in a Zoom chat: "EIP 7002 is a version of EIP 3074 that only accepted versions with nonce and chainID. Now that these have been removed, we need to revisit the reasons. I suggest re-starting the discussion on these restrictions." Besu developer Daniel Lehrner suggested getting more input from wallet developers on the design of EIP 7702. Erigon developer Andrew Ashikhmin emphasized that there needs to be a way for users to revoke authorization themselves, bypassing the wallet.

Beiko suggested that the implementation details of EIP 7002 continue to be discussed in a separate group meeting. In the meantime, developers agreed to remove EIP 3074 from Devnet 0 and include EIP 7702 in Devnet 1.

The other two EIPs planned for Pectra are EIP 7623 (increased calldata cost) and EIP 7212 (support for precompiles for the secp256r1 curve). EF researcher Toni Wahrstätter shared the latest progress on EIP 7623, and smart contract wallet developer Ulaş Erdoğan shared the latest progress on EIP 7212. Developers did not reach a consensus on whether these two EIPs should be included in Pectra.

Pectra Timeline Expectations

Konstantopoulos mentioned when developers should activate the Pectra upgrade on the Ethereum mainnet. In a document shared before the call, the Reth client team wrote that there is "little value" in trying to release the upgrade before the end of 2024, and developers should prepare to release the upgrade in early 2025. The EF Panda Ops team (a subset of the EF Developer Operations team) also shared a document before the call, expressing their views on the timeline and scope of Pectra. They suggest splitting Pectra into two forks, one activated this year and another including MaxEB, EOF, and possibly peerDAS, activated early next year. Jayanthi said the EF Panda Ops team is not united in their views, but he personally believes that the scope of Pectra should be split into two forks. He noted that edge cases and EIP interactions of the Pectra upgrade have not been tested. EF Solidity developer Alex Beregszaszi expressed concern that if EOF is not included in Pectra, these code changes will never be included in Ethereum's upgrade. Geth developers Marius van der Wijden and Guillaume Ballet disagreed, arguing that the benefits of EOF are significant enough that its usefulness will remain even if it is delayed for a few more forks. Beiko suggested first reaching a consensus on how to prioritize peerDAS and blob size increases before determining the rest of the scope of the upgrade. He suggested that developers attending the All Core Developers Consensus (ACDC) meeting next week focus on this topic. He hopes that developers will be ready to finalize the scope of Pectra at the next ACDE meeting.

Portal Network and Historical Expiration

Finally, Merriam noted that the Portal Network team is ready to work with protocol developers to release a historical expiration version in parallel with Pectra. More information about Portal Network can be found here .

「 Original link 」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia