Ethereum All Core Developers Consensus Call #139 Writeup
On August 8, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #139. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed fixes to Pectra Devnet 2, preparations for Devnet 3, PeerDAS implementation progress, and new data on Ethereum node distribution.
Pectra Updates
Stokes said that EF Researcher Hsiao Wei Wang is preparing the next official release, alpha.4, for Pectra CL specifications. It adds a variety of fixes from the previous version and will be released by Wang shortly.
On the topic of Pectra Devnet 2, EF Developer Operations Engineer Barnabas Busa said that the network is stable and has reached 85% network participation levels. There are a few bugs to work out in execution layer (EL) clients, primarily EthereumJS and Erigon. Most CL clients are stable on Devnet 2. However, Busa mentioned a minor issue in the Prysm client that needs further investigation. EF DevOps Engineer Parithosh Jayanthi added that investigation on an issue between Lighthouse, Teku, and Besu nodes is also needed by client teams.
Then, developers discussed improvements to communications about the launch of devnets. Prysm developer Kasey Kirkham wrote in the Zoom chat, “I didn’t realize when Devnet 2 was starting up.” To ensure that the launch of Devnet 3 is properly communicated across all client teams, developers agreed to create a weekly meeting series for testing updates about Pectra. Like the testing calls that had occurred in lead up to the Dencun upgrade, these meetings will be hosted on Mondays, though developers have yet to confirm the exact time. Jayanthi said that testing calls can be kept short, 15 to 30 minutes in length, and focus primarily on testing updates related to the various devnets related to Pectra, which include PeerDAS and EOF devnets.
On the topic of Pectra Devnet 3, developers reconfirmed that it would feature the exact same set up EIPs as Devnet 2. However, it will also feature the most updated EIP 7702 design and developers will earnestly test the interactions of this code change with the other core Pectra EIPs. Lodestar developer Gajinder Singh noted that on Devnet 2, developers found issues with EIP 7251, MaxEB. There was an issue with consolidating validator staked ETH deposit balances that has since been debugged but will need further testing on the next Pectra devnet.
As discussed on ACDE #193, there is a new Engine API specification that enables CL clients to fetch blobs from the EL blob transaction mempool. The method is called “getBlobsV1”. To avoid its misuse, Teku developer Enrico del Fante has proposed a few clarifications to CL specifications. Stokes recommended developers review these clarifications and aim to test the use of this method on Pectra Devnet 3.
Then, developers discussed mplex deprecation. Mplex is a protocol used by CL clients that allows multiple data streams to be sent over a single communication link. Mplex has since been deprecated by its maintainers and CL client teams are aiming to transition over to a new data stream multiplexer like yamux. Lodestar developer Phil Ngo said that implementation and testing for yamux is complete for their client. However, they would prefer switching over to the new protocol rather than maintaining both for a period. He explained that supporting both mplex and yamux creates overhead for their client. Nimbus developer Etan Kissling said that his team is in the process of testing yamux. Developers agreed to follow up with the other CL client teams on this topic and revisit the discussion on how to transition away from mplex in a few months’ time.
On another topic related to Pectra, Kissling asked whether developers were ready to decide on the inclusion of EIP 7688. The code change introduces a forward-compatible data structure that smart contract developers can utilize even as Ethereum developers change the EL’s data serialization method from RLP to SSZ. The full SSZ transition will not happen in the Pectra upgrade. However, Kissling has proposed EIP 7688 to introduce a data structure that will ensure forward-compatibility of EL-related related data changes in Pectra EIPs.
Stokes was not enthusiastic about including EIP 7688 in Pectra, saying the upgrade was “already massive.” Jayanthi wrote in the Zoom chat that the earliest developers could feasibly add EIP 7688 to Pectra testing would be Devnet 5. Representatives from Lodestar, Prysm, Teku and Lighthouse teams were supportive of including EIP 7688 in the upgrade. Stokes and Beiko recommended that developers refrain from adding any new EIPs in Pectra until all existing Pectra EIPs are stabilized. Kissling agreed with this recommendation and sought clarity from the group on when to bring up this topic again. While there was no clear answer, developers seemed agreeable to considering EIP 7688 again shortly before the launch of Pectra Devnet 5.
PeerDAS Updates
A representative from the Prysm client team shared an update on their PeerDAS implementation. This sparked a discussion on the necessity of the “blobsidecar” Engine API request. Stokes recommended discussing necessary changes to the Engine API due to PeerDAS on the next PeerDAS breakout call. Stokes highlighted that an EF Researcher has drafted formal specifications for removing the activity of sampling from PeerDAS to reduce upgrade complexity. On the latest PeerDAS breakout call, the proposal raised concerns that removing sampling may make it more difficult to add in through a later hard fork. Further, it remains unclear how the removal of sampling will impact the extent to which developers can safely increase the blob gas limit in Pectra. EIP 7742, a proposal to uncouple the blob gas limit across the EL and CL, was raised again on this week’s call. Stokes said that he would update the EIP and developers can discuss inclusion of it, along with topics related to changes in the blob gas limit in Pectra, on the next CL call.
Research Updates
Developers discussed three research topics on this week’s call. The first was related to edge cases when validators are consolidating their staked ETH balances under EIP 7251. Kissling explained that validator balances may not update for an extended period during the consolidation period, and this may cause the protocol to incorrectly assign sync committee responsibilities to a validator. Stokes noted that these concerns are similar in nature to how the protocol processes validator exits. He recommended leaving the design for consolidations unchanged and instead leave a note in CL specifications that acknowledges the edge cases related to consolidations.
Then, developers discussed changes to Ethereum’s networking layer, specifically the addition of a “quic ENR entry.” Quic stands for Quick UDP Internet Connection and it assists nodes in sending and receiving data. Stokes recommended creating a pull request (PR) on GitHub to further detail the exact changes for the quic ENR entry.
Finally, ProbeLab, a blockchain analytics firm, shared an update on the data they have been gathering weekly since the beginning of the year. In their latest report, they identified 8,335 nodes operating on Ethereum. 42% of these nodes are running on the Lighthouse client. 36% of nodes are operated by users out of the U.S. Roughly half of these nodes are run via a data center. Prysm developer “Potuz” asked why the number of Lighthouse nodes hosted through a data center is higher than the number of Lighthouse nodes that are self-hosted. Stokes hypothesized that the reason could be that the predominant users of Lighthouse are institutions and professional node operators.
Before ending the call, Potuz asked the group to review his PR on changes to the structure of the execution payload. This was first raised on the prior ACDC call. He stressed that developers should decide quickly on whether to incorporate the suggested changes because while they are simple in nature, they will be difficult to write into CL specifications sand developers should start working on this sooner rather than later.
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.