Ethereum All Core Developers Execution Call #188 Writeup
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.