Ethereum All Core Developers Consensus Call #125 Writeup
On January 11, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #125. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers gave brief updates on Cancun/Deneb upgrade testing. They also discussed two research topics related to translating Beacon API specifications into OpenAPI schemas and optimizing CL attestation subnets through utilization of the node-id prefix.
Cancun/Deneb Goerli Shadow Fork #2
The Ethereum Foundation testing team launched a shadow fork of the Goerli testnet on January 11. This is the third and final Goerli shadow fork before Cancun/Deneb is activated on Goerli next Wednesday, January 17. All final client releases for the Goerli upgrade have been tested on Goerli Shadow Fork (GSF) #2. A view of the live shadow fork test network can be seen on this block explorer. Ethereum Foundation DevOps Engineer Parithosh Jayanthi noted that initial analysis on GSF #2 was positive, saying, “Blobs and blocks seem to be propagated fine.” More details about the final client releases for the Goerli upgrade and Cancun/Deneb specifications can be found in this Ethereum Foundation blog post released yesterday, January 10.
Fork Choice Filtering Change
As discussed on ACDC #114 and ACDC #115, there are minor changes to CL fork choice specifications that client teams are expected to roll out in an asynchronous fashion near the time of Cancun/Deneb mainnet activation. Mikhail Kalinin from the Teku client team explained, “What was previously decided is that we are rolling out this change within Deneb and doing it in a loosely coordinated fashion. So basically, these changes should be enabled in the mainnet releases.” Kalinin suggested that client teams either start merging the changes into their releases over the next few weeks or alternatively, wait for an epoch fork boundary such as the Cancun/Deneb activation epoch to trigger the changes and have them go live in all clients after a specific timestamp. For more details on the fork choice filtering change, read this GitHub pull request (PR).
Developers agreed to merge the changes as soon as possible without waiting or coordinating an epoch boundary, indicating client teams were confident that they could incorporate changes post haste in their next releases.
OpenAPI Type Definitions for Beacon API
Lodestar developer “Dapplion” shared that the canonical mapping of SSZ to JSON for all Beacon API routes has been completed as of this week. The benefits of this type of mapping include the simplification of code. “It looks much cleaner. It’s way less code,” said Dapplion. “For now, it’s not critically important but for future forks, it should alleviate a lot of maintenance and we can easily SSZ everything if we want later, which is an idea that has been floating around for a while and this would make it very easy.” For background on SSZ -harmonization discussions, read prior ACD call notes here.
Dapplion asked developers about their thoughts on moving from OpenAPI to SSZ as a next step. There were no vocal disagreements. Dapplion said that he would reach out to respective teams about the changes to specifications listed in his PR and ensure that that the transition happens in a smooth fashion.
Modify Attestation Subnet Calculations
Developers also discussed a minor change to long-lived attestation subnets (attnets) for nodes. As background, attnets are the networks that staking node operators connect to when publishing their attestations for blocks. Developers rolled out a revamp to attnets last in May 2023. To further optimize attnets, Lighthouse developer Age Manning has proposed elevating the use of the node-id prefix to assist node discovery on subnets, or in Mannings’ words, “searching for the prefix to find all nodes on a subnet.” Developers briefly discussed the potential negative impacts this may have on networking and the likelihood of attack vectors related to using the node-id prefix for finding nodes. Ryan said that the change proposed by Manning in any case would require a hard fork. He asked Pop Chunhapanya, one of the developers on the call, to investigate strategies for implementing Manning’s proposal and source feedback on this topic from other developers in the PR.
As a final topic of discussion, Ryan opened the floor for suggestions on what code changes or Ethereum Improvement Proposals (EIPs) to prioritize for the next upgrade after Deneb, which is dubbed Electra. Ryan said that he would lead a more “structured conversation” on the topic during the next ACDC call in two weeks. In the meanwhile, Ryan encouraged developers to review the EIPs proposed on Ethereum Magicians and GitHub and chime in with their thoughts on these forums.
Ethereum Foundation Researcher Ansgar Dietrichs said that in his view data availability sampling (DAS) is the “highest priority” for a CL-focused upgrade. “[DAS] very much has the nature of a feature that usually would be part of an EIP but just because of the way we structured 4844, it does not actually require a hard fork or attached EIP and I think with that comes the risk of maybe not having quite the same visibility,” said Dietrichs. Ryan pushed back on this comment, saying that that DAS in his view would be included in an EIP given that the change would naturally be coupled with conversation about modifications to Ethereum’s data gas limit. For background on what DAS is and how it has been implemented on other blockchains like Celestia, read this Galaxy Research report.
Ryan mentioned that there is a draft PR for DAS and that it would be proposed with a formal EIP number in two weeks. Ryan encouraged client teams on the call to consider what should be prioritized in Electra for the next ACDC call on January 25.