Ethereum All Core Developers Execution Call #166 Writeup
On July 20, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #166. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed preparations for Devnet #8 and minor changes to Deneb/Cancun EIPs, the Engine API, and the EIP editing process.
Deneb/Cancun Testing Efforts
Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, said that developers ran into issues with tooling, specifically around the use of Blobscan, for Devnet #7. Blobscan is a blockchain explorer for viewing blob transactions. The issues around Blobscan have since been resolved and though the tool was not able to capture blob data from the very beginning of Devnet #7, developers plan on using it for the genesis of Devnet #8. Devnet #8 unlike previous developer-focused test network for Dencun will feature testing for all Dencun-related EIPs. Full specifications for Devnet #8 can be found here.
In preparation for Devnet #8, client teams are working on cutting new software releases. The following are status updates from client teams shared on this week’s call:
The Nethermind (EL) team has merged all Dencun-related EIPs to a new release except EIP 4788.
The Erigon (EL) team is working on merging several EIPs, with a focus on EIP 4788 and EIP 6780.
The Besu (EL) team is also focusing on merging EIP 4788 and 6780. Other EL-focused EIPs are ready to be merged pending a few specification clarifications.
The EthereumJS (EL) team is ready for Devnet #8 pending a specification clarification around new block payloads. More on what the clarification is later in this writeup.
The Lighthouse (CL) team is in the process of doing final reviews on their release for Devnet #8.
The Teku (CL) team is also ready for Devnet #8 and working on implementing a new publishing API for supporting optional broadcast validation.
The Ethereum Foundation testing team highlighted that dedicated tests are ready for most Dencun EIPs except EIP 4788 and 1153.
Once all client releases pass relevant Hive tests for Devnet #8, Jayanthi said they will prepare the launch of the next test network. Developers are aiming to launch Devnet #8 sometime during the first week of August. Already, developers have completed a shadow fork of Sepolia with a small number of clients. According to Jayanthi, the shadow fork was helpful in identifying a few bugs in client code.
Specification Clarifications
Gajinder Singh from the Ethereum JS (EL) client team shared his proposal to simplify specifications around block construction. His proposal can be read in full here. Ethereum Foundation Researcher and Chair of the bi-weekly ACDC calls Danny Ryan said that the motivation for the change was an aesthetic one and that his leanings were neutral but that if CL client teams did want to push for this change, he would want to expedite the changes for implementation in clients by Devnet #8. “I can knock on doors after the call to see [what teams think],” said Ryan. “If we get positive all around [from teams], we’ll try and cut a release more like Tuesday to unblock this and keep things moving but if anyone has a vocal opinion on this please say so now.”
Next, Danno Ferrin, Principal Software Engineer at Hedera Hashgraph, presented his proposal for adding clarifications to EIP 6780, the removal of the SELF-DESTRUCT opcode. Ferrin’s proposal can be read in full here. Ferrin said that his proposal primarily clarifies the semantics around the implementation of EIP 6780. One of these clarifications has to do with the use of the SELF-DESTRUCT opcode for burning ETH and the changes around this ability post EIP 6780. Ferrin noted that Layer-2 protocols like Optimism rely on SELF-DESTRUCT to burn ETH and manage withdrawals back to Layer-1. Beiko said that he would reach out to Layer-2 protocol teams about their thoughts on Ferrin’s proposal and encouraged developers to revisit this issue during next Thursday’s ACDC call. Since the call, both the Optimism and Arbitrum teams have confirmed that their code will be unaffected by EIP 6780.
Geth (EL) developer “lightclient” proposed three changes to the Engine API, two of which were approved with unanimous consensus among client teams.
Add eth_getBlockReceipts: Creates a more efficient method for dapp developers to obtain large amounts of block and transaction data through a single call to the Ethereum Engine API. All client teams on the call agreed the method should be added.
Remove mining namespace: Removes all mining-related JSON-RPC methods such as “eth_mining”, “eth_hashrate”, “eth_getWork”, “eth_submitWork”, and eth_submitHashrate”. All client teams agreed these methods should be removed from specifications.
Create default locations for reading & writing JWT secrets: To spin-up a validator, node operators must authenticate the connection between their EL and CL client using a JWT token. Lightclient’s proposal attempts to reduce the complexity around locating this data and authenticating communication between EL and CL clients in a validator node.
About the third proposal, Lightclient said, “Even just for myself, I would love to not have to deal with this. I think users aren’t really getting better at running clients, they just stop running clients. I think we can do a lot better about making it easier for people to be running our software.” The sentiment from other client teams was mixed. Enrico Del Fante from the Teku (CL) team noted that the creation of a default location for the JWT token creates more client complexity and may trigger greater volumes of help requests from node operators to client teams around the JWT token path and any custom changes to it. However, Del Fante also noted that adding a default value most likely couldn’t make things materially worse for client teams given the existing complexity of this dual client set-up for node operators. Lightclient agreed to continue the conversation around his third proposal with client teams asynchronously.
ERC Repository Split
On ACDE #164, developers discussed splitting ERC proposals from EIPs in a separate GitHub repository. As background, ERC are application-level standards for Ethereum such as ERC-20 and ERC-721, which dictate standards for the creation of fungible and non-fungible tokens, respectively. EIPs on the other hand have traditionally defined code changes to the core protocol of Ethereum. Danno Ferrin and Lightclient have co-authored an EIP to formally split out ERCs from EIPs to their own separate GitHub repository. According to Ferrin, the split is meant to nurture more tailored governance processes for both ERCs and EIPs.
Though all EL and CL client teams on the call were in support of EIP 7329, or at least voiced no opposition to the EIP, EIP editor Greg Colvin said he was opposed to the EIP, favoring other changes to the EIP process outside of a split between ERCs and EIPs. Colvin’s suggestions for improving the EIP editor process are detailed here in this draft PR. Ferrin highlighted that many of Colvin’s suggestions in his draft PR could be incorporated along with EIP 7329. Even so, Colvin was opposed to EIP 7329 and said that he would quit his role as an EIP editor if EIP 7329 was approved prematurely without further discussion.
To Colvin’s objections, Beiko said, “We’ve discussed [these changes] for many years but also many months recently and there seems to be extremely strong support from the core developers and research side across both the execution and consensus layers. I think we should continue to work on [the split].” After further disagreement and debate between Colvin, Ferrin, and Beiko, developers agreed to move forward with a review of both Colvin’s PR and EIP 7329. Ferrin said that EIP 7329 would be open for comment until the end of the month.
Finally, Beiko mentioned that there is ongoing discussion around what to name the Ethereum upgrade after Deneb/Cancun. The most popular naming choice so far from previous discussions has been to name the EL upgrade Prague and the CL upgrade Electra. “Abcoathup”, the editor of Week in Ethereum News, has started a new discussion thread on Ethereum Magicians to pick a combined upgrade name. The suggestions so far by Abcoathup are “Petra” and “Electrague.” Beiko encouraged participation in this discussion on the Ethereum Magicians forum.
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 2023. All rights reserved.