Ethereum All Core Developers Consensus Call #129 Writeup
On March 7, 2023, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #129. Chaired by Ethereum Foundation (EF) 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 shared last-minute updates about their preparations for the Dencun upgrade, which is scheduled to activate on mainnet on Wednesday, March 13. They also discussed the scope of the next Ethereum upgrade, Pectra, as well as a few research topics, one of which was block value standardization between CL clients.
Deneb
Ryan kicked off the call by reminding everyone that the Dencun upgrade will be going live on Ethereum in less than a week. He also mentioned that for many in the U.S. daylight saving time (DST) will start this weekend on March 10. Given that all ACD calls, as well as upgrades, are scheduled according to a UTC time zone, which does not have DST, developers and those listening to the call who are based out the U.S. will need to adjust their schedules for these events accordingly.
A few client teams on the call also shared that they will be releasing new recommended versions of their software for the Dencun upgrade in the coming days. The Prysm, Lighthouse, and Teku teams all expect to have new releases out by the end of this week, if not early next. Given that these versions are not mandatory for the upgrade, EF Protocol Support Lead Tim Beiko mentioned in the Zoom meeting chat that the Ethereum Foundation blog post compiling all version-compatible releases for Dencun will not be updated.
Chris Hager from the Flashbots team shared a quick update on the readiness of MEV-Boost software. Hager confirmed that the MEV-Boost version, version 1.7, released last week is stable and ready for validator node operators to use. He said the Deneb-ready Flashbots builder software is a work in progress that will be finalized and merged sometime this week. About the readiness of validators for the upgrade, Hager expressed concerns that not enough validators appeared to have updated their MEV-Boost software for the Dencun upgrade yet. Upon double-checking his numbers, Hager said roughly 50% of validators connecting to the Flashbots relay were utilizing the latest MEV-Boost release, v1.7.
Beiko added that his sources, Metrika and Ethernets, both showed that the percentage of Ethereum nodes in general that appear to be ready for the Dencun upgrade was roughly 50%. Beiko also expressed his desire for a data tool that could track the readiness of validator nodes for an upgrade, as opposed to all Ethereum nodes.
Electra
Ethereum developers discussed four code changes in relation to the Pectra upgrade.
EIP 7459
The first was Ethereum Improvement Proposal (EIP) 7549, which makes CL clients more efficient at aggregating votes, also known as attestations, for blocks. Developers agreed on a prior call to include EIP 7549 in Pectra. Teku developer Mikhail Kalinin shared further analysis on how EIP 7549 should be implemented on Ethereum and presented a few tradeoffs or “negative effects” that may be introduced because of this code change. Ryan recommended that Kalinin summarize his proposed changes to CL specifications directly on GitHub for further feedback and review.
Prysm developer Terence Tsao said that he agreed with Kalinin’s proposed implementation for EIP 7549 but recommended further documentation and specification for the Beacon API changes that would be necessary alongside this EIP. “Today, if you have 10 aggregators within the same slot, you need to sign 10 attestations and then with this change, you only need to send one message and because of this, you probably need some Beacon API changes,” said Tsao, adding, “I think that part will probably need more thinking on how to change the Beacon API validator integration to solve that.” As background, the Beacon API is the specification for the CL that enables nodes to query the network and obtain information about the network’s state.
Issuance Reduction
Then, EF Researcher Ansgar Dietrichs shared a quick update on his proposal related to reducing staking rewards through lowering network issuance. He said the proposal since it was proposed on the last ACDC call has received “mixed feedback from the community.” He reiterated that the proposal would be a minor code change that could be included in the Electra upgrade last minute, meaning by June or July, assuming a mainnet hard fork in October. However, Dietrichs also said that the conversation is “ongoing,” meaning that further discussion on the idea is needed before a decision can be made.
EIP 7547
Thirdly, EF Researcher Mike Neuder raised EIP 7547, inclusion lists, for further discussion. He said that a second breakout meeting to discuss the “exact features” of the EIP’s design would be useful and that he is considering organizing one for next Friday, March 15. He also mentioned that there is a dedicated Discord channel for the EIP called “inclusion-lists” where people interested in learning more about the proposal or asking questions should use. Tsao also shared that since the first inclusion list breakout meeting on February 16, the specifications for the proposal have been largely fleshed out. “I think the spec is probably about 75% ready,” said Tsao, adding that there are a few other components of the specifications that need work, such as the Execution API changes and specifications about honest validators.
EIP 7251
Finally, Lighthouse developer Mark Mackey expressed his support for EIP 7251, increasing the maximum effective balance (maxEB). “We’ve pretty much prototyped it in Lighthouse. There’s still work that needs to be done on the spec but it doesn’t actually seem like a significant amount of work and given that the validator set size is a bit of a ticking time bomb and we have this proposed issuance adjustment and issuance changes are always contentious so it’s not guaranteed that the community would accept it … If they don’t like, then really the only thing we can do actually is maxEB,” said Mackey. Ryan said that the major pushback on the inclusion of maxEB in Electra is due to the code change’s complexity, as expressed in prior calls by the Prysm team. “Potuz,” a pseudonymous developer for the Prysm team, said in the Zoom meeting chat that his team would review the EIP again and reassess the proposal’s complexity. Ryan requested that client teams come ready for the next ACDC call in two weeks to make “firm decisions” on both EIP 7547 and 7251.
Keymanager API Standardization
EF Developers Operations (DevOps) Engineer Barnabas Busa explained that all CL clients seem to have a slightly different method for generating validator keys, which are the cryptographic keys needed to operate and withdraw a validator. There are APIs known as “keymanager APIs” to assist validator node operators with key management, as well as onboarding and offboarding validators. Busa explained that the minor differences between clients when it comes to returning values for this API does make testing the API endpoints difficult. He also mentioned that his team has started to do basic testing for mixed validators, meaning validator node operators that use a different client for their beacon node from their validator client. As background, the beacon node is the client that maintains the state of the CL but does not manage the keypairs that are needed for the validator to participate in consensus. The validator client is the client that does utilize the keypairs to produce blocks and sign attestations on-chain. Ryan recommended that Busa start a document or pull request to present proposals for standardizing the keymanager API. Developers on the call were also supportive of further testing to ensure that mixed validators work across all CL client combinations.
Block Value Beacon API Standardization
A Nimbus developer by the screen name “Dustin” also raised concerns regarding CL standardization for the Beacon API endpoints “produceBlockV3” and “getBlockRewards.” Dustin explained that there are areas of the Beacon API that are underspecified and “not universally implemented” across clients. Specifically, when it comes to the endpoint that should return the block value, the calculation at a minimum should include the change in a validator’s balance before and after proposing the block. However, the specifications do not detail whether clients should include reward and penalties from validator balance changes that result from the actions of another validator. For example, these include sync committee duty rewards or penalties, proposer or attester self-slashing, and whistleblower rewards. Ryan agreed that clarifications should be added to the Beacon API. However, other developers on the call including Radosław Kapka and Potuz both from the Prysm team were not as confident. Potuz expressed concerns that the people using these endpoints were few in numbers and capable of standardizing block values from differing CL clients with their own tools. “I don’t even understand why we even agreed to supporting this if the consumers are restricted. I would try to study these markets and try to see if we can actually send this work to the people that are consuming these endpoints instead of ourselves,” said Potuz.
Nimbus developer Jacek Sieka pushed back on this sentiment saying that since the “produceBlockV3” endpoint exists developers need to do something about its inconsistency across clients or deprecate the endpoint in favor of a “V4”. Further, Sieka added, “I think this [endpoint] is just really basic functionality. This just makes sense to have if we envision a future in which there are multiple block sources, and you need to compare them. It’s that simple.” Ryan recommended that Dustin create a proposal to standardize the V3 and “getBlockRewards” endpoints and once the proposal is created, client teams and rediscuss whether they want to continue supporting them.
Miscellaneous
Potuz flagged two items for further feedback and discussion from developers. The first was regarding execution layer (EL) client behavior for late blocks that is not currently specified in the Engine API, the API that dictates communication between the EL and CL. “If this can get specified in the Engine API, this would make our lives much easier when reorging late blocks,” said Potuz. The second item Potuz flagged was about his analysis of payload boosts for enshrined proposer builder separation (ePBS), an upgrade that would remove the need for trusted relays on Ethereum. Potuz requested more feedback on the analysis and other ePBS design constraints.
Finally, Pooja Ranjan from the Ethereum Cat Herder group shared the launch of a new working group called Women in Ethereum Protocol (WiEP). WiEP is a new organization from the Ethereum Foundation focused on encouraging and onboarding more female Ethereum protocol developers. Ranjan said that the group will host an hour-long webinar on March 8 featuring discussions with various female Ethereum protocol contributors.
Then, Ryan noted that he will be taking a three-month break starting April 1. In his absence, EF Researcher Alex Stokes will chair the ACDC calls.
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.