Summary of the latest meeting of Ethereum core developers: Agreement to remove EIP 3074, including EIP 7702

Original Title: 《All Core Developers Execution Call #188 Writeup》
Author: Christine Kim
Compiled by: Luccy, BlockBeats

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

The meeting covered many important topics, including new execution API features, Geth's minimum priority fee requirements, discussions on Pectra Devnet 0 and 1, the scope of the Pectra fork, and historical data expiration. Developers engaged in in-depth discussions 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 detailed notes on the key points of the meeting, and BlockBeats 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 bi-weekly series of meetings hosted by Tim Beiko, the Ethereum Foundation's Protocol Support Lead, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed the following topics:

• Adding new features to the execution API to allow users to access transaction "return data" (returndata)
• Geth's minimum priority fee requirements
• Pectra Devnet 0 and 1
• The scope of the Pectra fork
• Integration of historical data expiration in 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.

Adding Return Data to Transaction Receipts

Charles Cooper, a developer maintaining the smart contract programming language Vyper, proposed that an endpoint in the execution API should be adjusted so that users can receive the transaction's return data (returndata) when obtaining transaction receipts. Cooper explained that the current common methods for developers to obtain return data, such as using transaction tracing, are not standardized and are not universally supported across all clients. Based on feedback from client teams like Reth regarding his idea, Cooper suggested that another solution would be to create a new endpoint in the execution API to retrieve the transaction's return data (returndata). Developers did not reach a consensus on this proposal during the call. Beiko suggested that developers continue the discussion on GitHub and try to resolve the issue asynchronously outside of the meeting.

Minimum Miner Priority Fee Requirements

Subsequently, Geth developer Péter Szilágyi raised concerns from users regarding 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 fee requirement for transactions. After the merge, the default 1 gwei priority fee was not functioning properly, which was only recently discovered and fixed by Szilágyi's team. After restoring this default setting, users found that blocks built with the Geth client were significantly emptier than others, as they excluded transactions with almost no priority fees. This raised concerns about the potential negative impact of the default settings on block proposers and builders' dynamics, as it could lead to delayed processing of valid transactions without priority fees.

Nethermind developer Tomasz K. Stańczak stated that Geth's default minimum priority fee requirement is a trivial issue, and protocol developers should not attempt to standardize or enforce it. EF researcher Ansgar Dietrichs suggested lowering the default minimum priority fee since the current base fee for Ethereum transactions is very low. Other developers suggested setting the default minimum priority fee in Geth as a percentage of the base fee rather than a fixed amount. However, Beiko opposed this, arguing that priority fees are not meant to be the cost for transactions to be included in blocks. They should only be used to prioritize ensuring that transactions are included in the next block, and using a default minimum priority fee based on fluctuations in the base fee could distort changes in the base fee, as part of the value would be reflected in the transaction's priority fee.

Beiko added that another angle of the discussion is how to encourage builders to create zero-fee blocks and provide off-chain payments to proposers as compensation. This situation could occur with or without a default minimum priority fee requirement, but setting a default could create a norm that discourages builders from creating zero-fee blocks. Szilágyi remarked that whether builders should include zero-fee transactions in blocks is a philosophical question. From a network perspective, these transactions are valid and should be included in blocks. However, from the financial incentive perspective of proposers, including zero-fee transactions in blocks has no economic benefit and therefore should not be included.

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

Pectra Devnet -0

Parithosh Jayanthi, a developer operations engineer at the Ethereum Foundation (EF), updated the status of the Pectra development network. The first development network was launched last week at an Ethereum protocol developer in-person gathering in Kenya called Nyota Interop. Jayanthi stated that the development network includes all execution layer and consensus layer clients. However, EIP 3074 has not undergone intensive testing, and there are bugs that need to be fixed. The client teams are preparing for the launch of the second development network, Pectra Devnet 1, which will include changes to the EIP 2935 implementation.

Changes to Pectra Scope

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 including EOF in Pectra. Geth developer Marius van der Wijden stated that he is implementing the EOF specification. However, he emphasized that including EOF will definitely delay the activation of the Pectra upgrade due to its complexity. Lodestar and EthereumJS developer Gajin der Singh mentioned in the Zoom chat that developers should focus on releasing the current version of Pectra rather than expanding the scope of the upgrade. EF researchers Alex Stokes and Piper Merriam agreed with Singh's view.

After discussing EOF, developers talked about the progress of EIP 7702. EIP 7702 was proposed by Ethereum co-founder Vitalik Buterin as an alternative to EIP 3074. Important details regarding EIP 7702, such as its revocable design, remain unresolved. A developer named "dror" wrote in the Zoom chat: "EIP 7002 is a version of EIP 3074 that previously only accepted versions with nonce and chain ID (chainID). Now that these have been removed, we need to revisit the reasons. I suggest restarting the discussion on these limitations." Besu developer Daniel Lehrner suggested seeking more input from wallet developers regarding the design of EIP 7702. Erigon developer Andrew Ashikhmin emphasized the need for a way for users to revoke authorizations without going through wallets.

Beiko suggested continuing the discussion on the implementation details of EIP 7002 in a separate breakout meeting. Meanwhile, developers agreed to remove EIP 3074 from Devnet 0 and include EIP 7702 in Devnet 1.

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

Expected Timeline for Pectra

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 attempting to release the upgrade before the end of 2024 is "not very valuable," 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 Pectra timeline and scope. They suggested splitting Pectra into two forks, one to be activated this year and the other to include MaxEB, EOF, and possibly peerDAS, to be activated early next year. Jayanthi noted that the EF Panda Ops team does not have a unified viewpoint, but he personally believes that the scope of Pectra should be divided into two forks. He pointed out that edge cases and EIP interactions for 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 upgrades. Geth developers Marius van der Wijden and Guillaume Ballet disagreed, arguing that the benefits of EOF are significant enough that its usefulness will still exist even if delayed for several forks.

Beiko suggested first reaching a consensus on how to prioritize peerDAS and blob size increases before determining the remaining scope of the upgrade. He recommended that developers attending the All Core Developers Consensus (ACDC) meeting next week focus on this topic. He hopes developers will be ready to finalize the scope of Pectra at the next ACDE meeting.

Portal Network and Historical Expiration

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