Ethereum All Core Developers Consensus Call #132 Writeup
On April 18, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #132. 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 shared updates about their preparations for the first Pectra developer test network, also called Pectra Devnet 0. They discussed open questions about the specifications for Pectra Devnet 0 and briefly highlighted two outstanding research items related to network issuance and data availability sampling.
Electra Open Questions
EF developers have released the initial CL specifications and test vectors for Pectra Devnet 0. However, there are several outstanding questions about these specifications that may or may not be addressed in time for the first devnet launch. Stokes highlighted that one of these questions is related to EIP 7251 (Increase the MAX_EFFECTIVE_BALANCE). It appears developers are leaning towards enabling validator staked ETH consolidations as an execution layer (EL) triggerable operation. However, for the time being, consolidations are defined in the initial Electra specs as a CL operation. “This is fine because most of the processing logic that the Beacon Chain will need will be the same regardless of the source,” said Stokes.
Another open question that developers discussed on the call was related to EIP 7549 (Move committee index outside Attestation). The EIP changes the way validator attestations are aggregated and formatted in blocks. When Pectra is activated, there will be attestations aggregated from before the upgrade that are no longer compatible with the new attestations submitted on-chain. Stokes highlighted two possible solutions in a GitHub issue before the call. He wrote:
Clients broadcast both formats in the last Deneb epoch, with care taken to not produce slashable messages.
Extend block with extra field for the pre-Electra attestations and just allow the Deneb style during the first epoch of Electra.
As background, Deneb is the combined upgrade name for the most recent hard fork activated on Ethereum. Electra is the CL upgrade name for the next immediate hard fork scheduled on Ethereum.
Developers discussed both options on the call. Ultimately, they decided not to change Electra specifications for now and instead see how these lost attestations do or do not impact network security on devnets.
A third open question that developers discussed on the call related to Electra was the addition of a new EIP in the upgrade that would create general purpose EL requests. The EIP proposed by Geth developer “Lightclient” would simplify the process of updating how messages are sent from the EL to the CL. Due to the rise of smart contract-based staking solutions, there has been an influx of EIPs activated on Ethereum and proposed for Pectra that trigger various validator operations directly from the EL, instead of the CL. Lightclient’s proposal creates a general framework for propagating “contract-triggered requests” from the EL to the CL. Given that this EIP would change how Pectra is designed, specifically the implementation of EIP 6110 and EIP 7002, Lightclient stressed that he would appreciate feedback from client teams on his proposal as soon as possible. Developers agreed to try and finalize Lightclient’s EIP by the end of the week so that specifications for it can be built and shared by Monday, April 22.
Then, developers discussed two other open questions raised by Teku developer Mikhail Kalinin related to EIP 7549 and EIP 7251. The first was regarding changes to the validator committee index type, while the latter proposed changes to the processing of validator deposit data. Stokes encouraged developers to review both proposals in more detail for further discussion in the coming weeks.
Finally, the last open question related to Electra specifications that developers discussed was an increase to the blob count. EF Developer Operations Engineer Parithosh Jayanthi said that he would like to conduct analysis on blob activity post-Dencun upgrade and based on this analysis recommend a one-time increase to the blob count for inclusion in the Electra upgrade. EF Researcher Ansgar Dietrichs highlighted that he also put out a proposal to activate a gradual increase to the blob count that should be considered in parallel to Jayanthi’s proposal for inclusion in Electra.
Research Open Questions
There were two research items that developers briefly discussed on this week’s ACD call. The first was a new research post by EF Researcher Anders Elowsson that presents a new model for thinking about and implementing changes to Ethereum’s issuance policies. The full post can be read here. Stokes encouraged developers on the call to review the post.
The second research item raised by Lighthouse developer Adrian Manning was related to attestation subnets. As stated by Manning on GitHub, “This PR introduces the concept of a ‘network shard’ which is just an abstract concept that tags a node-id to a number (a network shard). We can then use this network shard (number) to assign topics that a node must subscribe to for a long period of time.” Manning is seeking final input on his proposal so that his team can start work on PeerDAS, Ethereum’s data availability sampling solution. For information about data availability sampling, read this Galaxy Research report.
As a point of clarification, Nethermind developer Lukasz Rozmej asked whether EIP 7547 (Inclusion Lists) had been approved for inclusion in the Electra upgrade. Developers reiterated that EIP 7547 has not been approved for inclusion.
Saulius Grigaitis, a developer building an Ethereum CL client called ‘Grandine’, raised questions regarding Ethereum’s fork choice rule considering ongoing PeerDAS research. Grigaitis asked that developers chime in with thoughts in the PeerDAS working group.
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.