Ethereum All Core Developers Consensus Call #110 Writeup
On June 1, 2023, Ethereum core developers gathered over Zoom for their 110th All Core Developers Consensus (ACDC) call. Chaired by Ethereum Foundation 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, Dankrad Feist, a researcher for the Ethereum Foundation, presented findings from a data experiment on the capacity of Ethereum mainnet nodes to propagate large amounts of data. Based on his findings, he recommended an increase in EIP 4844 specifications from a maximum of 4 blobs per block to 6.
Pending Changes for Deneb
Based on the EIP 4844 coordination call on Monday, May 29, Danny Ryan said there were a few minor changes to the specifications for Ethereum’s next upgrade, dubbed Deneb on the CL side and Cancun on the EL side. As mentioned on Monday’s call, developers are preparing to launch their 6th official test network for EIP 4844, which will include updated specifications since Devnet #5. Two of the pending Deneb changes discussed on this week’s ACDC call were:
Consensus Specifications PR #3391: Based on discussions from last week’s ACDE call
on discrepancies in the calculations used to determine the gas price of blob transactions, an additional “data_gas_used” field must be added to the EL block, that is the execution payload.
Consensus Specifications PR #3392: For consistency, the size of the new “data_gas_used” field should be reduced to a 64 bit unsigned integer (uint64) based on discussions
A Geth (EL) developer who goes by the screen name “Lightclient” volunteered to post a final call about these pending changes to the Ethereum R&D Discord channel. Danny Ryan said that he’d like to merge these changes as quickly as possible to Deneb specifications and cut a new release.
Deneb EIPs
Aside from EIP 4844, CL client teams are considering the inclusion of EIP 4788 in the Deneb upgrade. Alex Stokes, a researcher for the Ethereum Foundation, is spearheading efforts on EIP 4788 and gave an update on his progress with the code change. As background, EIP 4788 introduces a trust-minimized way for smart contracts and decentralized applications (dapps) to access the CL and information such as validator balances, activity, and rewards. On the call, Stokes explained that he has created a simpler way to implement EIP 4788 that keys the precompile’s storage by the root itself, mapping to the block timestamp in the corresponding execution payload. Stokes agreed to bring up his new proposal for EIP 4788 during next week’s ACDE call on June 8, 2023.
Then, Teku (CL) developer Mikhail Kalinin surfaced a concern around EIP 6988. As background, EIP 6988 is a code change to prevent slashed validators from being selected by the network to be a block proposer. While simple in theory, Danny Ryan wrote in a comment under the EIP that the code change would break “engineering invariants” and require specific tests examining the logic for shuffling slashed validators from a selected slot and replacing them. Kalinin encouraged CL client teams on the call to review his EIP and discuss it in two weeks’ time on the next ACDC call.
Aside from the two EIPs mentioned above, the other EIPs being considered for inclusion in Deneb are:
EIP 7045, Increase max attestation inclusion slot: As discussed on ACDC #109, this code change would expand the attestation slot inclusion range from a rolling window of one epoch to the current and next epoch, which creates more potential slots of attestation inclusion. According to Ryan, the change would be useful for enhancing chain security.
Fixed voluntary exit domains: This code change is meant to improve the staking user experience by ensuring that the signed messages from validators that want to voluntary exit from the network are valid in perpetuity, instead of only two forks. The EIP was proposed by a Lodestar (CL) developer who goes by the screen name “Dapplion.”
Ryan said that he would create a GitHub issue for tracking all candidate EIPs for Deneb. He encouraged CL client teams to focus on building EIP 4788, 7045, and fixed voluntary exit domains into Deneb specifications, alongside EIP 4844. Regarding EIP 6988, Ryan said that developers would revisit the code change during the next ACDC call.
Big Data Experiments
Next, Dankrad Feist shared findings from a data experiment testing the capacity of Ethereum mainnet to process large blocks. Feist explained that blocks containing anywhere between 128 kB of additional data to 1 MB were propagated on Ethereum and for sustained periods of 10 slots. Notably, for the entire range of block sizes, the Ethereum network remained stable and did not appear to have any issues with the additional data loads. Feist and his team tested the impact of these large-sized blocks on metrics such as bandwidth consumption, block propagation speeds, and number of missed attestations. Across all metrics, there were no abnormalities due to block size. However, there was an instance of a block reorg during the propagation a block carrying 1MB worth of additional data.
Based on the experiment, Feist recommended increasing the maximum number of blobs per block in EIP 4844 specification from 4 to 6. He also recommended reevaluating the four second deadline for receiving blocks in a slot based on the increasing amount of data that Ethereum nodes are expected to send. “I think it may be a good idea to think if we want to move the deadlines around a bit in the slot,” said Feist, adding, “Maybe it makes more sense to prolong the first phase where we wait for the block and have a little bit less time for the second and third phase because it would make the chain probably more stable and would also make it much easier to increase the number of blobs at little bit at least.”
A Nimbus (CL) developer who goes by the screen name “Arnetheduck” chimed in saying that if developers are considering changing around the deadlines, considerations should also be made for the bandwidth profile of nodes during attestations. There is a big spike in node bandwidth around the time that attestations from validators are published. To smooth out these spikes, Arnetheduck suggested implementing rules to allow attestations to be made sooner in a slot by validators.
According to Feist, developers on the call expressed concerns in the Zoom chat around increasing the maximum blob count from 4 to 6 out of an abundance of caution. To these concerns, Feist said, “I have a lot of people asking me when blobs are finally coming and there are like several teams, which are building products at the moment, really needing us. I think people underestimate how much this is going to be used and how big it’s going to be.”
Danny Ryan recommended that developers on the call continue to discuss the next steps for the experiment and possible changes from the experiment’s findings asynchronously on the Ethereum R&D Discord.
Engine API Versioning
Finally, developers discussed a proposed change to Engine API versioning to reduce the complexity of future API specifications and testing. As background, the Engine API is a standard collection of methods for communication between the CL and EL. Regarding the increasing number of versions supported by the Engine API, Mikhail Kalinin wrote in a GitHub comment, “The more forks with data structures change is supported the more validations and related complexity EL clients have to deal with in the logic of the same method handler.” He then proposed a 1:1 mapping between an Engine API method version and a version of data type the method supports. In other words, rather than an Engine API method version supporting multiple versions of a data type, the change would restrict the supported data type to one, thereby improving specification clarity and reducing specification complexity.
A Lighthouse (CL) developer who goes by the screen name “EthDreamer” said that the proposed 1:1 mapping would not be difficult to implement but that it may result in CL clients “losing the ability to deprecate old methods and … losing the ability to upgrade independent of forks.” To this, Kalinin said that the latest version of the Engine API, v3, could contain the complexity of all previous versions, including v1 and v2, and moving forward from v3, implement the new mapping logic. Kalinin said he would create a formal pull request for his proposal and share it on GitHub for further comments.
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 2023. All rights reserved.