skip to content

Ethereum All Core Developers Consensus Call #115 Writeup

Ethereum All Core Developers Execution Call #130 Writeup - Galaxy Research

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.