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.
Electra Discussions
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.
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.