Ethereum All Core Developers Consensus Call #115 Writeup
On August 10, 2023, Ethereum core developers gathered over Zoom for their 115th All Core Developers Consensus (ACDC) call. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. These calls are usually chaired by Ethereum Foundation Researcher Danny Ryan. This week, the call was chaired by Prysm (CL) developer Terence Tsao. Developers discussed:
Timing for the launch of Devnet 8
EIP 4788 code deployment strategy
Fork choice filtering change deployment strategy
Standardization of attestation aggregations across CL clients
Stable validator set size for the Holesky test network
Devnet 8
Developers agreed to launch the next official test network for the Deneb/Cancun (Dencun) upgrade, Devnet 8, early next week. Parithosh Jayanthi, a DevOps Engineer at the Ethereum Foundation, mentioned that his team is working on updating local testing tools for client teams based on the issues discovered in client configurations on Devnet 7. Jayanthi encouraged client teams to review their configurations to ensure there are no inconsistencies for the launch of Devnet 8, the first dedicated test network that will feature the activation of all relevant Ethereum Improvement Proposals (EIPs) finalized for the Dencun upgrade. Representatives from Prysm (CL), Lighthouse (CL), and Nethermind (EL) said they were ready for the launch of Devnet 8. Andrew Ashikhmin representing the Erigon (EL) client team said that they were working on fixing certain Hive tests and was not certain they would be ready for Devnet 8.
EIP 4788
On All Core Developers Execution (ACDE) call #167, developers agreed to update EIP 4788 from a stateful precompile to a regular smart contract. As background, EIP 4788 exposes the roots of Beacon Chain blocks inside the Ethereum Virtual Machine (EVM) on the EL so that decentralized applications (dapps) can easily access this data without having to trust an oracle or off-chain data provider. Last week, Martin Holst Swende, lead security engineer and Geth (EL) developer at the Ethereum Foundation, pointed out that converting EIP 4788 into a regular contract coded in Solidity and priced natively through the EVM would decrease the complexity of the EIP and reduce the risk of it causing a chain split. Read the full call notes from ACDE #167 for further details.
On ACDC #115, developers reaffirmed the decision to rewrite EIP 4788 as a regular contract. Chair of the ACDE calls Tim Beiko said that a new pull request (PR) has been created for the EIP on GitHub by “lightclient,” a pseudonymous Geth (EL) developer, that contains the necessary changes. Beiko also highlighted that there is still uncertainty around how to best deploy the contract. “[The question is] whether we just deploy it like a regular transaction for the fork or if we couple it with the fork so that during the fork activation, we also do a contract deployment,” said Beiko. Furthermore, Beiko said the Ethereum Foundation is starting to reach out to third-party auditing services to formally review lightclient’s PR and recommended that client teams also look at the proposed code. Tsao affirmed that changes to EIP 4788 and its deployment strategy will be revisited as a topic for discussion on next week’s ACDE call.
Fork Choice Filtering
As discussed on ACDC #114, a few changes to the CL fork choice specification are required to implement the confirmation rule. The confirmation rule is a new algorithm that Ethereum CL teams have been working on for the past several months that would be used by node operators to easily and quickly determine whether a block is guaranteed not to be reorged, that is removed from the canonical chain. Rather than requiring all client teams to implement the fork choice filtering logic for the confirmation rule at a strict epoch boundary, such as the activation of the Dencun hard fork, developers expressed a preference to implement the changes through a soft fork a few weeks prior to Dencun. Ben Edington representing the Teku (CL) client team was in favor of this strategy to reduce implementation complexity. Developers agreed to move forward with merging the PR for implementing changes to the fork choice filtering logic through a soft fork before Dencun once the epoch number for Dencun activation is confirmed.
Client Behavior Standardization
Developers also discussed a PR to merge new clarifications to CL client behavior when aggregating validator attestations. Validator attestations are votes on the canonical head of the blockchain that the Ethereum network aggregates and uses to finalize new blocks. A developer named Pop Chunhapanya pointed out that certain clients such as Prysm only aggregates validator attestations in the first 6.5 seconds of a slot, rather than the full 8 seconds, while other clients such as Lighthouse aggregate attestations on a rolling basis for the entire duration of the slot. Chunhapanya’s PR recommends updating CL client specifications to specify that all Ethereum CL clients should include live attestations for the full slot duration. Tsao was in favor of this PR but recommended that the keyword for this change should not be “must” but rather “should,” as CL clients face inevitable delays in sending attestations that may force them to miss certain attestations sent in the duration of a slot.
The last PR that developers discussed was a change to proposer boost functionality. Proposer boost is a mechanism to discourage block proposers from submitting late blocks by boosting rewards for timely block submissions. Back in April 2023, a malicious block proposer on Ethereum exploited a vulnerability in the ultrasound MEV relay, that then led to minor changes to MEV relay design and MEV Boost software. The Lighthouse (CL) team has proposed a minor modification to the timing of proposer boost rewards to further mitigate similar attacks on MEV relays as the one seen in April. Developers agreed to merge the proposed PR by the end of the week. For further information on the nature of the MEV relay exploit and Lighthouse’s fix, read this blog post.
Holesky Testnet
Finally, Jayanthi gave an update on big test network experiments for the launch of the Holesky testnet. As background, Holesky is a new public testnet that Ethereum developers and client teams plan on launching in September to replace the Goerli testnet. Holesky is envisioned to be Ethereum’s largest public testnet, hosting more active validators than Ethereum mainnet. For the past few weeks, developers have been experimenting with the validator set size. At 2.1mn active validators, Jayanthi said that the testnet was not able to finalize. “There were too many validator duties [and] some blocks coming in late leading to not enough attestations being propagated throughout the network. So even though you were seeing something like 80% [block] proposals, we were only seeing between 40% to 45% of attestations on the network,” said Jayanthi.
Developers then dropped the testnet size to 1.4 mn validators from 2.1mn and the maximum number of validators per node to 3,300 from 5,000. Jayanthi said that this testnet experiment was successful. Block proposals hovered in the range of 80% to 90% and attestations similarly in the range of 82% to 84%. Developers plan on launching the Holesky testnet with an active validator set size of 1.4mn. When asked whether Jayanthi’s team would continue to pursue testing for a 2mn validator set size testnet, Jayanthi said that his team was satisfied with 1.4mn and if needed could put in the work and coordination effort to grow into a 2mn validator set size network down the line. As preparations for the Holesky testnet launch are finalized, Tsao encouraged developers to chime in with thoughts in the #interop channel on the Ethereum R&D Discord.
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.