skip to content

Ethereum All Core Developers Execution Call #168 Writeup

Ethereum All Core Developers Execution Call -161 Writeup

On August 17, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #168. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed:

  • the launch of Devnet #8,

  • the contract deployment strategy for EIP 4788,

  • the genesis supply for the Holesky testnet,

  • and EIP 7212, a proposal to add a new precompile that allows signature verifications in the “secp256r1” elliptic curve.

Devnet #8

On Wednesday, August 16, developers launched Devnet #8, the first dedicated testnet featuring all Cancun and Deneb code changes. Parithosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, said the launch of the testnet went smoothly but overnight the network ran into a few issues primarily impacting nodes running Prysm (CL), Lighthouse (CL), or EthereumJS (EL) software. All three of these client teams are in the process or have already issued fixes to address the issues on Devnet #8. Developers will be releasing further tooling to analyze the health of Devnet #8 in the coming weeks. The tools live already for Devnet #8, which includes a blockchain explorer, can be found here.

One testing tool that Jayanthi highlighted as being particularly useful for identifying, isolating, and resolving issues in client software has been Kurtosis. Kurtosis allows developers to easily set up a local, multi-client testnet in a few simple steps. Jayanthi has created a document outlining steps for using Kurtosis and mentioned that the tool will be used in the coming weeks for testing MEV processes with Cancun/Deneb EIPs. There are a few clients that have not yet joined Devnet #8. Erigon and Besu (EL) teams are in the process of finalizing their releases for Devnet #8.

EIP 4788

One of the main blockers to finalizing Cancun/Deneb upgrade specification is EIP 4788. EIP 4788 exposes the roots of Beacon Chain blocks inside the Ethereum Virtual Machine (EVM) so that smart contracts on Ethereum can access this data in a permissionless way, without having to rely on off-chain data providers. As discussed during ACDE #167 and ACDC #115, developers agreed to implement EIP 4788 as a regular contract, instead of a precompile. For further background on this discussion, refer to prior call notes. This week, developers discussed whether to bundle the deployment of the EIP 4788 contract with the activation of the Cancun/Deneb hard fork or deploy it independently through a standalone transaction.

Arguing for the deployment of EIP 4788 as a “system contract address” at the time of the Cancun/Deneb hard fork, Danny Ryan – Ethereum Foundation Researcher and Chair of the ACDC calls – said that the benefit of this strategy was that the EIP could be “entirely self-contained.” “[The EIP] deploys its own code and then utilizes and exposes it via just on the fork,” said Ryan, adding, “I think this makes downstream tooling easier. I think this makes testing easier. I think this makes all sorts of things simpler.” However, Ryan highlighted that ultimately the decision about deployment is “aesthetic” in nature and either strategy will work. Therefore, though he prefers triggering the deployment of EIP 4788 through the Cancun/Deneb fork, Ryan said he would be content with either strategy so long as developers can reach a consensus on the decision post haste.

Arguing for the deployment of EIP 4788 as “an EVM contract” independent of the Cancun/Deneb fork, a developer for the Geth (EL) client by the name of “Lightclient” said that there is additional logic that will need to be created in client software to support EIP 4788 as a contract triggered by a hard fork. Lightclient emphasized that the strategy promoted by Ryan would enshrine additional and unnecessary code to the core Ethereum protocol. “It does not make [Ethereum] mainnet simpler. It actually makes the code a little more complicated because now we have to write something that says if we’re at this fork, then we need to enshrine this code into this address, and it needs to be hashed into the state roots. So, there’s just like another branch of logic,” said Lightclient.

Other developers on the call were divided on this topic. Ethereum Foundation researcher Alex Stokes and Teku (CL) developer Mikhail Kalinin were in favor of deploying EIP 4788 as a system contract address, while Lightclient said that Martin Holst Swende, Security Lead at the Ethereum Foundation, who was not present on this week’s call, was in favor of an EVM contract approach for code deployment. Ryan’s main push back to the EVM contract approach was its reliance on a user, not a hard fork, to trigger the code necessary to activate EIP 4788. “What is a reality where this EIP is turned on but the code is not actually there?” asked Ryan. To this, Lightclient responded that the EVM call would likely simply fail and return an error, but Lightclient added this behavior would need additional testing by developers.

After further discussion on the merits and drawbacks of these two strategies, Beiko suggested going with Lightclient’s suggested approach as it would not require additional code for client teams to implement. “I would lean towards deploying it in a separate transaction for now. If people want to keep discussing it and feel strongly about it, we can bring it up in two weeks and if people implement it and feel like it’s actually a terrible approach, and the other way is better, we can revisit that and then add the extra code path in two weeks,” said Beiko. Developers agreed to merge Lightclient’s pull request for the deployment of EIP 4788 as a separate transaction to Cancun specifications.

Holesky Testnet ETH Supply

Then, developers discussed updates to the development of the Holesky testnet. As mentioned by Jayanthi last week, the starting validator set size for the Holesky testnet will be 1.4mn validators. After weeks of testing and experimentation with large validator set sizes, Jayanthi asked whether the ETH supply of Holesky should mirror that of mainnet Ethereum, which is currently 120mn ETH, or stick to its default figure of 1.6bn ETH at genesis. Given that testing for Holesky has already been configured to support a large ETH supply at genesis, developers agreed to move forward with a 1.6bn ETH supply. Jayanthi reminded developers that the Holesky testnet is scheduled to launch on September 15, 2023, the same day that Ethereum developers activated the Merge upgrade on Ethereum mainnet a year before.


Sam Wilson, an EIP Editor and Researcher at the Ethereum Foundation, gave a quick update on the proposal to split ERC proposals from EIPs. For background on this discussion, refer to prior call notes. Wilson reported that the EIP Editors were in favor of splitting ERCs from EIPs and would be moving forward with implementing this proposal. He said that the EIP Editors are working towards making the governance process around EIPs and ERCs “more transparent” by creating a written document explaining the process step-by-step. Finally, he said that despite the split between ERCs and EIPs in terms of process, the EIP Editors would remain one group and one organization. Currently, there are five active EIP Editors. They are:

  • Alex Beregszaszi (@axic)

  • Gavin John (@Pandapip1)

  • Greg Colvin (@gcolvin)

  • Matt Garnett (@lightclient)

  • Sam Wilson (@SamWilsn)

Greg Colvin, one of the EIP Editors who had been strongly opposed to splitting ERCs from EIPs, said that his goal for the EIP governance process is to ensure that editors never delay or get in the way of making upgrades on Ethereum happen. The next planning call to discuss improvements to the EIP governance process will take place Tuesday, August 23.

EL Fork Specification Naming

Erigon (EL) developer Andrew Ashikhmin raised a minor issue around the organization of fork specification documents on GitHub for prior EL upgrades. At present, fork specifications for EL upgrades are labelled by the upgrade name, such as Cancun, London, Paris, etc. Instead of ordering these documents by name, Ashikhmin proposed attaching a number to these documents that reflect the order in which these upgrades were activated on Ethereum. He noted that CL upgrades are easier to organize by their name, as they are already alphabetically ordered – Altair, Bellatrix, Cancun. However, EL upgrades are named after major cities and could benefit from a numbering scheme. Developers agreed to move forward with this usability improvement for organizing EL fork specification documents.

EIP 7212

Finally, Ulaş Erdoğan, a blockchain developer based in Istanbul, presented EIP 7212. EIP-7212 creates a precompile for signature verification in the “secp256r1” elliptic curve. This is the curve most widely used and supported by mobile devices like Apple iPhones and Android devices. “I think that this precompile contract can onboard lots of new users and solutions which connect Web2 to Web3, especially in the account abstraction wallets,” said Erdoğan. Related to this discussion around EIP 7212, developers briefly discussed progress on EIP 6601 and a proposal to implement “progressive precompiles" to take into account different shipping timelines for new features on Layer-2 rollups vs. Ethereum mainnet. For further discussion on EIP 7212, Beiko encouraged developers to chime in with thoughts on Ethereum Magicians.