Ethereum All Core Developers Execution Call #187 Writeup
On May 9, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #187. 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 preparations for Pectra Devnet 0, updates to the implementation of EIP 3074, and the urgency of converting the serialization method on the EL from MPT to SSZ.
Pectra Devnet-0 Updates
EF Developer Operations Engineer Barnabas Busa said that his team is in the process of testing client configurations for the first Pectra developer-focused test network and will aim to have a stable configuration for the launch of Pecra Devnet 0 by Monday, May 13. Based on the Pectra Devnet 0 readiness tracker, the Geth, Nethermind, and EthereumJS client teams have fully implemented Pectra code specifications.
On the call, Besu developer Justine Florentine said that all Pectra EIPs have been implemented for Besu but his team is still working on debugging the code. Erigon developer Andrew Ashikhmin said his team has started work on all EIPs except EIP 7002, EL triggerable withdrawals. The Reth team posted a link to their implementation tracker in the Zoom chat, which indicates that their work on EIP 7002 like the Erigon team is also pending.
On the CL clients side, Grandine developer Saulius Grigaitis said all EIPs have been implemented but his team is running into bugs when running the client alongside an EL client. A representative from the Lighthouse team said they are close to having a full implementation ready for Pectra Devnet 0 and noted that specifications in the Engine API need updating. Teku developer Mikhail Kalinin said that he is working to get these updates added to the Engine API specifications.
Mario Vegas from the EF testing team said that developers are working through adding test cases for EIP 3074, AUTH and AUTHCALL opcodes, and a few other EIPs.
EIP-3074 Updates
While developers agreed to keep EIP 3074 in Pectra specifications for Devnet 0, there has been discussion about an alternative EIP to replace it, EIP 7702. Geth developer “Lightclient” summarized the latest breakout meeting for EIP 3074 in which participants discussed what changes related to improving the programmability of user-controlled accounts should be prioritized in the Pectra upgrade. According to Lightclient, all participants agreed that full native account abstraction is a few years away from being ready to implement on Ethereum. However, there was division on whether this meant prioritizing changes to the functionality of externally owned accounts (EOAs) or the migration of EOAs to smart contract wallets. A day prior to this ACD call, on May 8, co-founder of Ethereum Vitalik Buterin proposed a new EIP, EIP 7702, that would enable a new transaction type on Ethereum to support EOAs functioning like a smart contract wallet for the duration of a single transaction. Lightclient said that sentiment among participants from the EIP 3074 break out call was generally positive about EIP 7702. However, he added later that there are important details about EIP 7702 that still need to be worked out. For example, details on how to revoke EIP 7702 transactions and how to scale the gas costs for these types of transactions remain unclear.
If EIP 7702 is accepted into the Pectra upgrade, the idea would be to replace EIP 3074 with this one as EIP 7702 accomplishes similar outcomes as EIP 3074 but with the benefits of not creating new opcodes on Ethereum and improving the ease of static analysis on new EOA behaviors. EF Researcher Ansgar Dietrichs recommended in the Zoom chat considering EIP 7702 for inclusion in Pectra and waiting roughly 2 to 4 weeks before making a formal decision on replacing EIP 3074 with 7702. It was clear from the discussion among developers on the call about EIP 7702 that further work needed to be done on the proposal before it could be considered ready for implementation by client teams. Nethermind developer Ahmad Mazen Bitar noted that the work already done for EIP 3074 would not likely be reusable for implementing 7702. Beiko confirmed that developers should still move forward with an implementation of EIP 3074 for Devnet 0 and re-discuss specifications for Devnet-1 later.
EIP-7685, SSZ, and EIP-6110
Then developers discussed a few concerns raised by Nimbus developer Etan Kissling about EIP 7685, general purpose EL requests. In a GitHub comment under this week’s call agenda, Kissling asked whether the proposed design for general purpose EL requests was needed and if the opportunity could be better used to switch to SSZ, a serialization format that developers have been meaning to update on the EL since the Merge upgrade. Most EL client teams on the call were supportive of keeping EIP 7685 in Pectra and if any blockers emerge from the inclusion of the EIP on operations like a client’s optimistic sync to then revisit the design.
On the topic of moving to SSZ, Kissling explained that the new design format for general purpose EL requests is based on the legacy serialization format, MPT and RLP, and thus will have to be updated when developers make the transition to SSZ. He noted that delaying the move to SSZ only creates more work for developers if they continue to create new MPT/RLP data structures. However, there was not a strong voice of support from EL client teams for including EIP 7495, the SSZ stable container, in Pectra. A developer by the name of “Dustin” wrote in the Zoom chat that the decision to delay the SSZ transition was “crazy” and that the issue of poorly working SSZ libraries for the EL was “a serious issue.”
On the topic of EIP 6110, supply validator deposits on chain, Kissling flagged an issue with deposit ordering. Kalinin agreed the issue was “a big concern” and that he would do more investigation on it with input from major staking pools.
EOF Updates
Independent Ethereum protocol developer Danno Ferrin and EF Solidity Research Lead Alex Beregszaszi shared updates on implementation work for EOF. As background, EOF is a bundle of code changes improving the Ethereum Virtual Machine (EVM) that is being considered by developers for inclusion in the Pectra upgrade. The Meta EIP for EOF has been finalized. Developers have also simplified the transaction creation process in EOF, and progress is being made on client implementations for EOF.
EIP-7623 Updates
A developer on the call by the screen name “William Morris” presented concerns about the gas cost changes to calldata storage in EIP 7623. He explained that the changes would allow some users to transact at reduced rates by combining their transactions and thereby encourage the creation of secondary market for gas discounts that Layer-2 rollups (L2s) and other participants may use for transacting more cheaply on the network. He recommended an alternative EIP, EIP 7703, that increases calldata costs at a flat rate to address these issues.
Buterin said that while Morris’ concerns were valid, the likelihood of secondary markets being created for calldata because of EIP 7623 were not high in practice because the number of users that would choose to participate in such markets would be extremely small. Buterin noted that the primary participants impacted by EIP 7623 were L2 developer team Starkware and inscriptions creators. He added that while the total addressable market for secondary calldata markets was small, the upside for limiting the maximum size of blocks through the calldata increase was extremely high as it could allow developers to raise the blob gas limit and thereby scale Ethereum’s capacity to support L2s. Vitalik also said that a flat increase of the calldata costs as suggested by Morris would also impact L2s and other stakeholders far more punitively than the current EIP. Buterin shared more about this thoughts on gas pricing for blobs in a blog post published before the call.
Co-author of EIP 7623 Toni Wahrstätter agreed with Buterin’s points saying that he didn’t think the creation of secondary markets for calldata was viable from a practicality standpoint for most L2s. “It's not a very practically viable, especially thinking of such markets would require trust among participants and also a high degree of coordination. And imagine you as the L2, you want to post your data down to L1 and you don't know which address will post the data or where the data will eventually be. From a practicality standpoint, you would need custom indexes and all that. So, I don't think it's very viable,” said Wahrstätter.
Reth developer Georgios Konstantopoulos asked whether developers were researching what increases to the blob gas limit could be done if EIP 7623 is included in Pectra. Without a blob gas limit increase with EIP 7623, Konstantopoulos said that the EIP “doesn’t solve much of a problem.” EF Researcher Dankrad Feist recommended increasing the blob gas limit to the point where the maximum block size on Ethereum remains unchanged with the increase to calldata costs, meaning the amount of space freed up by the EIP would be filled by blobs, binary large objects. EF Researcher Ansgar Dietrichs said that the EIP is not only useful when coupled with a blob gas limit increase but also useful from a security perspective as it may ensure that the network cannot be destabilized by blocks containing the maximum number of transactions and blobs.
To questions about the impact analysis of EIP 7623 on smart contracts and transactions, Wahrstätter said that 98% of users will not be impacted by the increase in his proposal. Beiko also mentioned that EF Developer Operations Engineer Parithosh Jayanthi may be doing more in-depth analysis on exactly how much to raise the blob gas limit considering EIP 7623.
New Alternative to EIP 7609
A developer on the call with the screen name “Charles C” presented a new EIP to prevent reentrancy attacks in smart contracts. Charles said that the proposal which creates two new opcodes to protect smart contracts was an alternative to an earlier proposal that he submitted, EIP 7609, decrease base cost of TLOAD/TSTORE, for Pectra. Charles said that he was not sure why EIP 7609 was not considered for inclusion in Pectra and is still sourcing feedback from developers about a way to prevent reentracy in a cost-effective way. He noted that the current solutions like OpenZeppelin’s Reentrancy Guard and TLOAD/TSTORE opcodes are too expensive for decentralized application developers to use by default. Beiko recommended that developers offer Charles feedback on these the new EIP on Ethereum Magicians.
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.