Ethereum All Core Developers Execution Call #190 Writeup
On June 20, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #190. 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 shared updates on their progress towards implementing a variety of code changes including Ethereum Improvement Proposal (EIP) 7251 and 7702, as well as Ethereum Virtual Object Format (EOF) and PeerDAS.
Beiko also shared a proposed template for EIP discussion thread and EF Developer Operations Engineer Parithosh Jayanthi highlighted a new GitHub page for Ethereum mainnet and testnet configurations called “eth-clients”. Finally, Beiko reminded teams that the next ACDE call will occur on a U.S. holiday, July 4. Though he will not be in attendance for this call, EF Research Alex Stokes will chair the call in his place.
Pectra Devnet 1
Developers kicked off the call with a discussion on Pectra Devnet 1. Developers are aiming to launch the next dedicated testnet for the Pectra upgrade over the next week. The main specification changes between the prior testnet, Devnet 0, and the one upcoming are:
The addition of EL triggered validator consolidations
The replacement of EIP 3074 with EIP 7702
EL client teams are making progress on their implementations for Devnet 1. Representatives from each major Ethereum EL team shared updates:
Besu: A first version of their implementation for Devnet 1 is ready. It has some tests missing and the team has questions about the specs regarding gas pricing operations.
Nethermind: They are working on reviewing their Devnet 1 implementation, merging various code changes and software branches, and writing test cases.
Erigon: They have a draft implementation of EIP 7702. They are reviewing the latest changes to EIP 7251, namely the addition of EL triggered validator consolidations.
Reth: Their implementation for Devnet 1 should be finished before the next ACD call.
EthereumJS: The team is working on the implementation for EIP 7702. They expect to be ready for Devnet 1 in a week or so.
Geth: The team is also working on the implementation for EIP 7702.
As client teams were sharing their updates, a developer with the screen name “Racytech” asked if implementations for EOF would be excluded from Devnet 1. Beiko confirmed that EOF would not be tested on Devnet 1 and that implementations for EOF should be rebased on top of the latest Pectra specifications instead of finalized Deneb ones. EF Developer Operations Engineer Barnabas Busa stressed that this strategy will make debugging EOF harder as Pectra specifications are changing and also being debugged at the same time. “Even if that's true, it still feels like the right approach, in a way, because we want teams working on the core Pectra [EIPs] and fixing those bugs. So, it seems more reasonable than basing [EOF] on top of the previous fork and then having to potentially rebase it on Prague really late in the process, and then also finding all those bugs,” said Beiko. Prague is the EL name for the Pectra upgrade.
EIP 7702 Updates
Even though developers are working on implementing EIP 7702 in Devnet 1, there is the possibility of the code change being revised in major ways to support new features, specifically the ability for users to revoke EIP 7702-enabled transaction authorizations.
A pseudonymous Geth developer by the name of “Lightclient” has proposed new changes to the EIP that would support EIP 7702 revocations. He explained, “It's not as easy to see what types of authorizations you have in the air at any given moment, and it's difficult to know like what has been revoked and what's not been revoked. There are design patterns that avoid these types of scenarios but the reality is that maybe we won't know how wallets are going to use this and to have a more defensive mechanism an idea I think Vitalik mentioned on the last call, or maybe it was in a breakout room, [is] instead of having the authorizations be these temporary things that must be included with the transaction to set the code in the account, we can instead save the authorizations so that in the account you can actually look to see what code the account was delegated to at any given moment.”
A developer by the screen name “Arik” said that he preferred the current version of EIP 7702 over the proposed changes to the EIP by Lightclient. Arik said that there are certain use cases that would be possible under the new EIP 7702. Lightclient pushed back on these comments saying that all the use cases enabled by EIP 7702 in its old design are preserved but with the added benefit of a robust revocability mechanism. However, Lightclient did point out that the proposed changes for the EIP make its implementation in clients more complex. Beiko stated in the meeting chat box that finalizing the design of EIP 7702 is the “#1 outstanding spec issue for Pectra” and he recommended that developer organize another breakout call for reaching consensus on its revocation mechanism. “It would be nice if by the next call we had something that people were generally happy with and we could use whatever new version, whether it’s this one or a tweak of it, as part of Devnet 2,” said Beiko.
Besu developer Daniel Lehrner questioned if developers should spend the time implementing the current version of EIP 7702 in Devnet 1 if specifications would change for Devnet 2. “The proposals are quite different so we might implement something that afterwards we have to part of it throw away after a few weeks because 7702 is changing again,” said Lehrner. Richard Meissner, co-founder of the crypto wallet Safe, said that in his view it is helpful for wallet teams to have some version of EIP 7702 implemented on a testnet. Beiko added that the implementation of EIP 7702 in its current form will not in his view delay client teams “a ton” and there may be complications to Devnet 1 if developers try to remove it from Pectra specifications now.
EOF Updates
On the topic of EOF, Busa shared that his team will test EOF implementations after other Pectra code changes have been implemented. The readiness of EL client teams for EOF are tracked on GitHub. So far, two EL client teams, Besu and Reth, have implemented all EOF EIPs, while the others are still working on building out all the EOF EIPs. A representative from the Erigon team noted that additional test cases simulating Ethereum blocks containing EOF transactions would be useful. Mario Vega, who is part of the EF testing team, wrote in the chat that his team is working on releasing more tests for EOF and that he can share more on the next EOF breakout meeting. The EOF calls have switched from a weekly to a bi-weekly cadence, said independent Ethereum protocol developer Danno Ferrin, as EOF specifications are now finalized, and the focus of work for EOF is on testing and client implementations.
PeerDAS Updates
Busa shared a quick update on implementation work for PeerDAS. He said that the next PeerDAS Devnet should be up and running in the next week or two. PeerDAS as discussed on the last ACDC call will be developed on top of finalized Dencun specifications as opposed to Pectra ones.
Announcements
Beiko has proposed a new default template for EIP authors to structure their Ethereum Magicians posts. The new template is intended to facilitate “high quality reviews on EIPs.”
Jayanthi highlighted the “eth-clients” GitHub page, which hosts several resources for Ethereum developers including the canonical configurations for Ethereum testnets and mainnet, among other resources. It is currently maintained by representatives from all the CL client teams. Jayanthi asked for representatives from EL client teams to volunteer and help maintain this GitHub page.
Lightclient asked for updates on client teams progress with history expiry. There were no updates on this effort shared on the call.
Beiko said that he will not host the next ACDE call which falls on a U.S. holiday, July 4. Instead, EF Researcher Alex Stokes will run the call in his place.
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.