skip to content

Ethereum All Core Developers Execution Call #188 Writeup

All Core Developers Execution Call #188 Writeup — Galaxy Research

On May 23, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #188. Chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed:

  • A new feature to add to the Execution API that would enable users to access the “returndata” from a transactions

  • Geth’s minimum priority tip requirement

  • Pectra Devnet 0 and 1

  • Pectra fork scope

  • Portal Network integration for history expiry.

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

Add Returndata to Transaction Receipts

Charles Cooper, a developer who maintains the smart contract programming language Vyper, made the case for adjusting an endpoint in the Execution API such that when users fetch transaction receipts, they can also receive the returndata for transactions. Cooper explained that the most common ways developers rely on getting returndata such as using transaction traces is not standardized and not universally supported across clients. Based on feedback from client teams such as Reth about his ideas, Cooper said that another solution to this issue would be to create a new endpoint in the Execution API that fetches the returndata for a transaction. Developers did not reach a consensus about this proposal on the call. Beiko recommended developers to continue the discussion on GitHub and try to resolve the matter asynchronously from the call.

Minimum Miner Tip Requirement

Then, Geth developer Péter Szilágyi raised concerns about a default setting in the Geth client that certain users have pushed back about in recent weeks. Ever since the implementation of EIP 1559, the Geth client always enforced a default minimum priority tip requirement for transactions. After the Merge, the default priority tip of 1 gwei was not working and only recently discovered and fixed by Szilágyi’s team. Since restoring this default client functionality, users have pointed out that blocks built using the Geth client are significantly emptier than others as they exclude transactions containing little to no priority tips. This has created concerns that the default may negatively impact block proposer and builder dynamics by encouraging undue delays for valid transactions with zero priority fees.

Nethermind developer Tomasz K. Stańczak said that Geth’s default minimum priority tip requirement was a non-issue that protocol developers should avoid trying to standardize or enforce in any way. EF Researcher Ansgar Dietrichs recommended lowering the default minimum priority tip given that transaction base fees on Ethereum are presently very low. Other developers chimed in with suggestions to set the default minimum priority tip in Geth as a percentage of the base fee, rather than a fixed amount. However, this led to push back from Beiko who pointed out that the priority tip is not intended to function as a fee for transaction inclusion in a block. It should strictly be used to prioritize a transaction’s inclusion in the next immediate block and the use of a default minimum priority tip that oscillates based on the base fee may skew changes in the base fee itself as some of its value becomes reflected in the priority tip of a transaction.

Beiko added that another angle to this discussion is related to how builders could be encouraged to create zero-tip blocks and offer proposers out-of-band payments for them. While this could happen with or without a default minimum priority tip requirement, setting a default may enforce norms encouraging builders not to create zero-tip blocks. Szilágyi said that in some sense the decision about whether builders should include zero-tip transactions in a block is a philosophical one. From a network perspective, those transactions are valid and therefore should be included in a block. However, from a financially motivated proposer perspective, there is no economic gain from including zero-tip transactions in a block and therefore should not be included.

Developers broadly agreed that the Geth team should set what default they think is best. Validator node operators are free to change this default if they wish or use other EL clients.

Pectra Devnet-0

EF Developer Operations Engineer Parithosh Jayanthi gave an update about Pectra devnet. The first one was launched last week during an in-person gathering of Ethereum protocol developers in Kenya called Nyota Interop. Jayanthi said the devnet features all EL and CL clients. However, intensive testing on EIP 3074 has not been conducted and there is a bug that needs fixing. Client teams are already preparing for the launch of the second devnet, Pectra Devnet 1, which will include changes to EIP 2935 implementation.

Pectra Scope Changes

Then, developers discussed changes to Pectra upgrade scope. Independent Ethereum protocol developer Danno Ferrin, Reth developer Georgios Konstantopoulos, and representatives from the Solidity team, were all in favor of including EOF in Pectra. Geth developer Marius van der Wijden said that he is in the process of implementing EOF specifications. However, he stressed that the inclusion of EOF will certainly delay the activation of the Pectra upgrade due to EOF’s complexity. Lodestar and EthereumJS developer Gajinder Singh wrote in the Zoom chat box that developers should focus on shipping the current version of Pectra, rather than expanding the upgrade’s scope. EF Researchers Alex Stokes and Piper Merriam agreed with Singh’s sentiments.

Moving on from the discussion about EOF, developers discussed the status of EIP 7702, which was proposed by co-founder of Ethereum Vitalik Buterin as a replacement to EIP 3074. Important details about EIP 7702 such as its revocability design still appear to be unresolved. A developer by the screen name “dror” wrote in the Zoom chat, “EIP 7702 is a version of 3074, which was only accepted with nonce and [chainID]. Now they were removed, and we have to re-argue the reasons again. I suggest to start again with this restrictions.” Besu developer Daniel Lehrner recommended sourcing more input on EIP 7702 design with wallet developers. Erigon developer Andrew Ashikhmin emphasized there needs to be a way for users to bypass wallets and revoke authorizations on their own.

Beiko recommended continuing the discussion on EIP 7702 implementation details at a separate breakout meeting. In the meanwhile, developers agreed to remove EIP 3074 from Devnet 0 and work on including EIP 7702 in Devnet 1.

Two other EIPs pending inclusion in Pectra are EIP 7623, increase calldata cost, and EIP 7212, precompile for secp256r1 curve support. EF Researcher Toni Wahrstätter shared updates on EIP 7623 and smart contract wallet developer Ulaş Erdoğan shared updates on EIP 7212. Developers did not reach a consensus on the inclusion of either of these EIPs in Pectra.

Pectra Timeline Expectations

Konstantopoulos brought up the question of when developers should activate the Pectra upgrade on Ethereum mainnet. In a document shared before the call, the Reth client team wrote that there is “low value” in trying to ship the upgrade before the end of 2024 and developers should aim to prepare the upgrade for early 2025. The EF Panda Ops team, a subset of the EF Developer Operations team, also shared their views on Pectra timeline and scope in a document shared before the call. One of their suggestions was to split Pectra into two forks, one that would activate this year and the other which would include MaxEB, EOF, and potentially peerDAS to activate early next year. Jayanthi said that the EF Panda Ops team is not unified in their views, but his personal view is to split the scope of Pectra into two forks. Jayanthi noted that edge cases and EIP interactions have yet to be tested for the Pectra upgrade.

EF Solidity developer Alex Beregszaszi expressed concerns that if EOF is not included in Pectra, these set of code changes will never make it into an Ethereum upgrade. Geth developers Marius van der Wijden and Guillaume Ballet pushed back on this sentiment saying that the benefits of EOF are significant enough that its usefulness would still be relevant even if delayed another few forks.

Beiko recommended first coming to consensus on how to prioritize peerDAS and blob size increases before scoping out the rest of the upgrade. He recommended that developers joining for next week’s All Core Developers Consensus (ACDC) call focus on this topic. He asked that developers be ready to finalize the scope of Pectra on the next ACDE call thereafter.

Portal Network & History Expiry

Finally, Merriam flagged that the Portal Network team is open and ready to work with protocol developers to ship a version of history expiry on Ethereum in parallel to Pectra. More information about the Portal Network can be found here.