Galaxy Digital Holdings Ltd.

08/22/2024 | Press release | Distributed by Public on 08/22/2024 21:01

Ethereum All Core Developers Consensus Call #140 Writeup

On August 22, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #140. 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 development progress on Pectra Ethereum Improvement Proposals (EIPs) and PeerDAS. They also discussed naming for the next Ethereum CL upgrade and agreed to name it after the star name "Fulu". They also agree to use the portmanteau "Fusaka" when referring to the Fulu-Osaka upgrade in future discussions.

Pectra

Stokes flagged that there is a new CL specifications release for the Pectra upgrade, tagged as v1.5.0-alpha.5. He encouraged client team to review the release. Then, EF Developer Operations Engineer Parithosh Jayanthi spoke about the status of Pectra devnets. He noted that the Geth client has produced a couple of invalid blocks on Pectra Devnet 2, which developers are investigating. Jayanthi said the Erigon client has is facing issues staying connected to the canonical chain. Developers are actively debugging the devnet. Also, Jayanthi said there is a JSON RPC standardization issue in execution layer (EL) clients causing additional issues on the devnet that requires fixing.

Pectra Devnet 3

Stokes reconfirmed the plan to launch Pectra Devnet 3 in one week time. The specifications for Devnet 3 can be found here. There is an update to EIP 2935, save historical block hashes in state, that developers will incorporate into Devnet 3. It is a semantics change that should not impact client implementations. More information about it can be found here.

EIP 7251 Update

Developers are considering an update to EIP 7251, maximum effective balance increase, to resolve an edge case scenario where the correlation penalty is incorrectly computed for a slashed validator with a large effective balance of staked ETH. Stokes encouraged client team to closely review the updates and chime in with thoughts. The proposed changes can be found here.

Beacon Block Body Update

As discussed on prior ACDC calls, there are parts of the execution payload that CL clients will need to access in order to process state transitions correctly after the Pectra upgrade. Currently, CL clients do not store the execution payload for reference. Instead of organizing the necessary information or requests from the execution payload in a separate "envelope" of sorts for CL clients to use, as was the initial suggestion by Prysm developer "Potuz", developers are now weighing moving these requests to a new field in the Beacon block called "ExecutionClientRequests".

Generally, developers on the call were supportive of the idea, commenting that this proposal is easier to implement than the initial suggestion. Potuz highlighted that existing tests for the CL will be broken by the creation of the new field. Thus, developers will need to work on creating new specification test vectors to incorporate this change on future devnets. Stokes asked client teams to review the proposal in detail. It can be found at this GitHub link.

Engine API Update

Then, developers discussed a proposal by Geth developer "Lightclient" to simplify block conversion for EL clients. EIP 7685 in Pectra will make it difficult for EL client to easily differentiate block versions without referencing a fork schedule, as summarized on a prior call. Lightclient's proposal to unify requests into a single type so that EL clients can pass along the interpretation of them to the CL was generally well-taken by most developers on the call. However, Nimbus developer "Dustin" expressed concerns that the change could make it more challenging for clients to use without a functioning SSZ library. However, Lightclient and Potuz pushed back on these concerns saying that the proposal would not make it any more difficult for clients without a SSZ library to use as they can fall back to utilizing the old method for request representation. Stokes also leaned in favor of the proposal and said it should be merged into Engine API specifications after another week of review. For more information about the "unify request objects" change in the Engine API, refer to this GitHub link.

PeerDAS

EF Developers Operations Engineer Barnabas Busa said that his team will launch PeerDAS Devnet 2 on Friday, August 23. Representatives from the Lodestar and Teku client teams affirmed that they have PeerDAS implementations ready for testing on Devnet 2. Stokes shared progress made on EIP 7742, a way to update the blob gas target and maximum so that these values can be dynamically set by the CL. While there remains a few outstanding design questions about the EIP, the EIP appears to have strong support from developers for inclusion in the Pectra upgrade. Representatives from the Lodestar and Lightclient teams shared their preference for including EIP 7742 in Pectra. Stokes, the author of the proposal, said that he would continue to work on the code changes and raise it again for discussion, and perhaps inclusion in a Pectra devnet, on a future call.

Then, developers spent some time discussing blob count configurability in clients. There were no concrete decisions made about this. Stokes recommended that client teams continue to think through how best to configure blob counts in clients to avoid difficulty when changing or updating these values in the future.

Stokes highlighted a few comments left on this week's call agenda by Nimbus developer Etan Kissling. Progress continues to be made on the implementation and testing for EIP 7688, forward compatible consensus data structures. Developers have not decided yet on whether to include it in Pectra. Kissling also requested feedback on a change to consensus specifications related to how CL clients handle blocks with transactions containing one or more zero-length transactions. Further details about the change can be found at this GitHub link.

Research

Developers agreed to name the next CL upgrade after Electra "Fulu". Fulu is the name of a star in the Cassiopeia constellation. CL upgrades are generally named after major stars, while EL upgrades are named after major cities.

A representative from ProbeLabs, a blockchain analytics company, shared insights about message propagation through the Ethereum networking layer, also known as the gossipsub protocol, since the activation of the Dencun upgrade. Their analysis has been shared on their blog and can be read it more detail here.

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.