Ethereum All Core Developers Consensus Call #143 Writeup
On October 3, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #143. The ACDC calls are a biweekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also known as the Beacon Chain. This week, the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes.
Developers discussed testing progress on Pectra and PeerDAS.
Pectra Devnet 3 Updates
EF Developers Operations Engineer Parithosh Jayanthi said debugging efforts on Pectra Devnet 3 are still underway. Network participation rates on Pectra Devnet 3 have fallen, according to Stokes. Jayanthi said that this is due to a bug in the Besu client that the Besu team is working to fix. He added that there is also an issue with Lighthouse/Nethermind nodes that he is currently investigating.
Pectra Devnet 4 Readiness
Stokes shared a post by the EF DevOps team about the list of open pull requests (PRs) pending for Pectra Devnet 4. One of the main outstanding PRs for the upcoming devnet launch is about the execution requests structure. As discussed on ACDE #197, developers are pursuing a new strategy to simplify the communication of execution layer (EL) triggerable requests such as EL triggerable validator consolidations, withdrawals, and deposits. Geth developer Felix Lange shared that there are open questions related to the formatting of the requests. Developers debated on whether to send a custom hash of the requests over the Engine API or the full request objects. “Potuz” from the Prysm team was in favor of the former for efficiency reasons. He wrote in the Zoom chat, “Not agreeing on a simple hashing system is really a failure of communication, choosing a manifestly less efficient algorithm over just picking essentially any other option seems childish to me.” Other developers on the call such as “Arnetheduck” from the Nimbus team disagreed. Without a clear consensus on the matter, Stokes recommended continuing the discussion on Discord over the next few days and coming to a resolution on it by next week’s ACD call.
Stokes noted that CL specifications for Devnet 4 will likely be based on the “alpha.7” release, which is in the process of being finalized by his team. Stokes also highlighted that PR 3918 in the consensus specs repository has undergone review and will be merged shortly. Additionally, PR 3818 is ready for review. (This is a PR that creates a queue for the processing of validator deposit requests.) Stokes encouraged developers on the call to review the changes.
Then, developers moved on to discussing two PRs related to how CL clients handle validator attestations. Arnetheduck who is championing both noted that one has more benefit for implementing in the immediate hard fork, Pectra, while the other can wait for implementation in a separate upgrade. Stokes agreed that developers could then drop PR 3787 and focus their attention on PR 3900. He recommended “soft” including PR 3900 to Pectra Devnet 5 to give client teams more time to review the PR and work on its implementation over the next few weeks.
PeerDAS Devnet Updates
EF DevOps Engineer Barnabas Busa said the latest PeerDAS devnet is struggling to reach finalization. Developers may have to relaunch the devnet with fixed client implementations. Busa said there is “lots of debugging” work happening on the PeerDAS devnet and developers will have a breakout meeting on Tuesday to discuss bug fixes.
“engine_getBlobsV1” Implementation Updates
There is a new execution API method called “engine_getBlobsV1”. It is designed to assist validators operating with low bandwidth to propose blocks in a timely manner. Representatives from Prysm, Lodestar, and Teku said they are in the process of implementing the method and Stokes stressed that this should be a “top priority” for client teams. The benefits from this change will be analyzed by developers in the coming weeks to better assess whether a blob target increase in Pectra can safely be added without the risk of negatively impacting network decentralization.
Developers discussed outstanding questions related to the method, one of which was raised by Teku developer Enrico del Fante. He created PR 3864 which suggests various clarifications in the P2P spec in the event of specific edge cases. Stokes encouraged developers to continue discussing these clarifications and others related to engine_getBlobsV1 outside of the call.
Blob Throughput Increase Discussion
Then, Stokes asked developers about their views on the strategy to scale blob throughput discussed on last week’s ACD call. Developers had agreed to gather more data about block reorg rates and home staking activity before moving forward with the inclusion of a blob target increase in Pectra. EF Researcher Toni Wahrstätter said that he has done more empirical analysis since then on block reorg rates for validators building blocks locally versus validators that rely on a third-party block builder. Developers discussed how best to go about doing an empirical analysis of node syncing capabilities in the event the network cannot reach finality. Potuz highlighted fundamental differences between re-syncing nodes to the head of the chain on devnets versus public testnets, saying that the former does not inform the behavior of nodes on the latter due to differences in P2P architecture.
EF Researcher Ansgar Dietrichs suggested including a blob target increase in Pectra now and if further analysis shows that this is not safe for the network, removing it later so that developers do not have to scramble to include this code change last minute. Potuz pushed back on this suggestion, saying that in his view removing a change to the blob target increase is just as much work as including. Jayanthi chimed in to say that a blob target increase is not a simple change for many client teams to implement, especially if developers are also thinking of coupling the increase with EIP 7742, uncoupling blob count between CL and EL. Stokes said, “My read is most people, or if not everyone, is in favor of 7742, so I think that's going to happen.”
Developers agreed to update EIP 7691 to reflect the latest desire among developers to increase the target blob count from 3 to 4, while keeping the maximum blob count unchanged at six.
Pectra Testnet for Devcon
In preparation for Devcon, an annual Ethereum developer conference, Jayanthi said that his team would like to launch a dedicated Pectra testnet that attendees of the conference can build on and test their integrations with new code changes like EIP 7702. Jayanthi asked client teams to create a duplicate release for this testnet that is a stable version of what will be released for Pectra Devnet 4. Stokes was skeptical about whether Devnet 4 would be stable by Devcon, which will start on November 12.
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.