skip to content

Ethereum All Core Developers Execution Call #166 Writeup

Ethereum All Core Developers Consensus Call -111 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.

  1. 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.

  2. 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.

  3. 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.