Ethereum All Core Developers Consensus Call #109 Writeup
On May 18, 2023, Ethereum core developers gathered over Zoom for their 109th 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, developers discussed preparations for the next Deneb specifications release. Deneb is the name of the next immediate Ethereum upgrade on the CL. Developers are targeting a release early next week, Tuesday, May 23, and plan on spinning up a new test network to confirm the latest changes to Deneb specifications shortly thereafter.
Preparing for a new spec release
There are four changes that will be included in the next Deneb release.
Consensus specifications, PR #3338: Gajinder Singh, a developer for the Lodestar (CL) client, introduced this pull request (PR) on ACDC #108. The PR introduces a “max_blob_commitments_per_block” field on the execution layer (EL) for changing the maximum number of blobs that can be attached in a block. Blobs are the new transaction type that will be introduced through EIP 4844 and used by Layer-2 rollups for cost-savings. PR #3338 introduces greater flexibility to the protocol so that only the EL needs to be updated, rather than both the CL and EL, for making changes to the maximum number of blobs per block.
Consensus specifications, PR #3359, requires Execution APIs, PR #407 and EIP 6985: During ACDE #161, developers agreed to remove SSZ encoding from the EL implementation of EIP 4844. To support this, there are a few changes that need to be made on the CL. Namely, checks of KZG commitments attached to blobs must be added to the preprocessing work of nodes alongside the usual checks of block hashes. Ryan mentioned that there needs to be “a sanity check” to ensure that the additional burden of checking KZG commitments in this way does not add material overhead to nodes. Terence Tsao, a developer for the Prysm (CL) client, also mentioned that this may impact MEV relays that are optimistically verifying blocks. “Before, the CL can verify SSZ blob transactions but now that the CL can no longer verify that, we have to rely on the EL to verify that. So, I’m not sure how the relayer will be able to [optimistically] verify that. This is an open question. I encourage people to think about that. I don’t have a good solution to this,” said Tsao.
Consensus specifications PR #3346: Related to PR #3338, this PR specifies the number of subnets for propagating blobs as equal to “blob_sidecar_subnet_count,” instead of “max_blobs_per_block.” This ensures that changes to the maximum number of blobs per block does not impact or requires changes to the peer to peer network structure and blob subnets.
Consensus specifications #3354: As discussed during ACDE #161, there is a input and out mismatch for the EIP 4844 precompile. Developers agreed to harmonize the output to rely on big-endian ordering, instead of little-endian and reconfirmed on this week’s call that in all cases went it comes to EIP 4844, the default data storage ordering should be big-endian. Hsiao-Wei Wang, a researcher for the Ethereum Foundation said that tests for this change have been fixed.
EIP 4788
Developers discussed updates on EIP 4788, which allows smart contract applications on the EL to verify proofs of CL state. This is beneficial for improving the trust assumptions of decentralized staking pools, restaking protocols, MEV applications, and more. During ACDC #108, developers agreed to start working on EIP 4788 for inclusion in the Deneb upgrade. Marius van der Wijden, a developer for the Geth (EL) client, raised concerns around the EIP’s use of the current slot number to expose Beacon Chain block roots in the Ethereum Virtual Machine (EVM) as opposed to a timestamp.
“I implemented the current spec without the slot, with only the timestamp. It’s not hard to do. It works,” said van der Wijden, adding, “Right now, what I don’t like is that it’s an opcode that leaves a certain address at a certain storage slot. I would rather make it a stateful precompile. It’s kind of a new concept but any way we implement it, it’s going to be a new concept.” Therefore, van der Wijden said that developers should not try to push EIP 4788 into Deneb before the concept around a “stateful precompile” is fully understood and thought through. Ryan recommended that a new PR be created to implement Wijden’s suggestions and further discussion around EIP 4788 be had during next week’s ACDE call.
Security improvements
Ryan shared a proposed code change to expand the attestation slot inclusion range to be both the current and next epoch. Attestations are votes from validators on the correct version of the chain that contributes to creating checkpoints like chain finality. At present, attestations are only considered valid for 32 slots, that is one epoch. This change would expand the attestation inclusion range to two epochs. According to Ryan, this is a useful change for enhancing chain security and as will be discussed later in this writeup, a forthcoming Beacon Chain feature known as the confirmation rule. Ryan said that he will format the code change as an EIP and prepare it for inclusion in an upcoming Deneb release, not the one coming up next week, but likely the one after.
Developers spoke briefly about removing certain checks related to the Merge upgrade from CL specifications. This would ensure that developers do not constantly have to re-run tests related to the Merge upgrade when testing future upgrades like Deneb. Alongside Hsiao-Wei Wang, Mario Vega who is on the testing team at the Ethereum Foundation said that he was working on similar cleanups and improvements to Ethereum specifications.
The confirmation rule
Developers gave updates on PR #3339 under the Consensus specifications repository. Also known as the confirmation rule, the PR introduces a new algorithm for nodes to calculate whether a block is confirmed, that is never to be changed or replaced with another block, based on certain assumptions such as network synchrony and the percentage of honest validators. The confirmation rule primarily improves the user experience as it could help provide confirmation of Ethereum blocks in under a minute, as opposed to 12.8 minutes, which is the time it takes for Ethereum to reach chain finality. While the confirmation rule would not be used to replace finality guarantees, it could be used for network stakeholders to more closely and accurately track the head of the Ethereum blockchain. The PR is in the process of review and performance checks.
Perpetually valid signed voluntary exits
Finally, developers discussed a proposal by “dapplion,” a developer for the Lodestar (CL) client. Dapplion explained that when a validator submits a signed message to exit the network, the message is valid for a certain number of forks, rather than in perpetuity. To improve the user experience, Dapplion has proposed a code change to ensure the validity of these signed messages through multiple forks. Tim Beiko, Chair of the ACDE calls, agreed to work on writing this proposal up into an EIP for further discussion with Dapplion.
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.