Ethereum All Core Developers Execution Call #167 Writeup
On August 3, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #167. 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 an important change to EIP 4788. EIP 4788 aims to expose the roots of Beacon Chain blocks inside the Ethereum Virtual Machine (EVM) on the EL. Hadrien Croubois, a blockchain engineer at OpenZeppelin, and “lightclient”, a pseudonymous Geth (EL) developer, also presented two new EIPs related to the topic of account abstraction. Finally, Guillaume Ballet, a Geth (EL) developer, and his colleague Josh Rudolf shared new updates on their progress with Verkle Tries.
Martin Holst Swende, lead security engineer and Geth (EL) developer at the Ethereum Foundation, proposed a simple fix to the ambiguous definition of “emptiness” in EIP 4788. However, he also proposed a larger change to the EIP that would negate the need for further specificity around definitions and decrease the complexity of the code change. In its current implementation, EIP 4788 is a precompile. Precompiles are contracts with a fixed gas cost designed to enable the use of complex cryptographic computations in the EVM that would otherwise be prohibitively expensive for a smart contract developer to call through their own Solidity code. Swende proposed changing EIP 4788 into a regular contract coded in Solidity and priced natively through the EVM. “I think that going with a regular contract increases security, I mean it decreases the complexity of implementation, so it lessens the risk of a consensus split,” said Swende.
Representatives from the Nethermind and Erigon EL client teams were supportive of the change and said that re-implementing EIP 4788 to function as a regular contract would not delay their work on Cancun. That said, Łukasz Rozmej from the Nethermind team did highlight there were some unknowns that would need to be worked out regarding the gas economics of EIP 4788 as a precompile vs a regular contract. Paweł Bylica, a developer focused on the EVM at the Ethereum Foundation, affirmed that testing and implementation for EIP 4788 would be easier if the code change was implemented as a regular contract, instead of a precompile.
Ethereum Foundation researcher and Chair of the ACDC calls Danny Ryan questioned whether the process around verifying and preparing EIP 4788 as a regular contract would potentially delay Cancun. Ethereum Foundation researchers Alex Stokes and Ansgar Dietrichs agreed with Swende’s proposal but also shared Ryan’s concerns around delays to Cancun. To address these concerns, Tim Beiko suggested expediting decisions around how to execute EIP 4788 as a regular contract and the preferred ways to deploy the contract on mainnet as soon as possible by next Monday’s Dencun Interop Testing call, formally called the EIP 4844 implementors’ call, on August 7.
Stokes agreed to work with Swende over the next few days to update EIP specifications. Developers also agreed to wait until these updates to EIP 4788 are made before launching Devnet #8. Stokes flagged one other change to EIP 4788 on how to populate the new beacon block root header field under different assumptions about network genesis. He encouraged people on the call to review the change asynchronously.
Danno Ferrin, principal software engineer at Hedera, gave a last call warning around clarifications to EIP 6780, the deprecation of the SELFDESTRUCT opcode. As discussed on a prior ACDE call, the functionality of SELFDESTRUCT will change post-Cancun upgrade. Most major decentralized applications (dapps) will not be affected by the changes. Developers agreed to merge Ferrin’s clarifications to official EIP specifications.
Then, Beiko highlighted three changes to the Engine API that need review. He asked developers on the call to chime in with their thoughts by Monday so that these changes can be merged to Cancun specifications next week. The three outstanding Engine API issues are:
Gajinder Singh, a developer for the Lodestar (CL) and Ethereum JS (EL) clients, added the need to specify which version of the fork choice update client versions should call for the Cancun upgrade. For background on this discussion around fork choice update version, refer to prior call notes here. Andrew Ashikhmin from the Erigon (EL) team recommended updating the second Engine API issue regarding how to handle Cancun blocks to also specify fork choice update versioning. Singh agreed.
On the topic of Devnet #8, Mario Vega, who is part of the testing team at the Ethereum Foundation, highlighted that the Hive test suite for Cancun EIPs is up to date and ready for use by client teams. The only tests that have not yet been prepared are the ones that will apply to EIP 4788 once specifications are settled around its implementation as a regular contract.
Parithosh Jayanthi, also part of the testing team at the Ethereum Foundation, gave a short update on progress for the Holesky testnet. As background, Holesky is a testnet that developers are designing to replace the existing Goerli testnet. Holesky is expected to go live in mid-September. For the past few weeks, Jayanthi and his team have been running experiments running big validators, that is nodes operating 5,000 validator keys.
For the latest experiment, developers spun-up a testnet with 2.1mn validators spread across 420 nodes. The CPU limits of nodes were reached almost immediately before developers replaced the hardware with more performant machines. The goal is for the Holesky testnet to support 1.5mn validators. However, Jayanthi noted that he was unsure if this would be possible based on the results of their experiments. Jayanthi asked for support triaging the state of their preliminary networks from developers on the call.
Hadrien Croubois, a blockchain engineer at OpenZeppelin, and “lightclient”, a pseudonymous Geth (EL) developer, presented two new EIPs related to the topic of account abstraction.
EIP 5806: Presented by Croubois, this EIP creates a new transaction type that allows externally operated accounts (EOAs) to execute arbitrary code using a delegate call-like mechanism.
EIP 7377: Presented by lightclient, this EIP creates a new transaction type to help migrate assets in an EOAs to a smart contract using a one-time code deployment to the EOA.
Ferrin questioned whether developers were getting ahead of themselves with these EIPs given that in-protocol solutions for enabling account abstraction have yet to be implemented on Ethereum. “These are interesting solutions that open up interesting design space but I think we should take a step back and think if we’ll be served better by deliberate design toward account abstraction,” said Ferrin. On EIP 7377 specifically, Yoav Weiss, a security fellow at the Ethereum Foundation emphasized that the most asked questions around EIP 4337, which is an out-of-protocol solution for account abstraction, is the migration path for an existing EOA into a smart contract. “This is one of the most commonly asked questions with 4337 users and there’s quite a big ecosystem for 4337 users at this point. Very often people ask about migrating an existing account. I’m not very opinionated on how we should do the migration, but we should have some form of migration,” said Weiss.
Ansgar Dietrichs was positive about the direction of these EIPs and the conversations they spark about account abstraction features on Ethereum. However, he emphasized that in his view, these proposals were not code changes for implementation “in the very short term, because it has very far-reaching implications,” and a starting point for a longer discussion, not a discussion for “the next hard fork.” Beiko timeboxed the discussion around these two EIPs and encouraged developers to chime in with further comments on the respective Ethereum Magicians forums that have been opened for each proposal.
Verkle Trie Update
Finally, Guillaume Ballet, a Geth (EL) developer, and his colleague Josh Rudolf shared updates on their progress with Verkle Tries. As discussed on prior calls, Verkle Tries are a type of data structure like Merkle Patricia Trees (MPTs). MPTs are used on Ethereum to store and easily verify blockchain state. Vector commitments used in Verkle Tries allow for smaller proof sizes so that Ethereum nodes no longer need to store state data indefinitely. The following is a slide from Guillaume and Rudolf’s presentation that explains the benefits of statelessness on Ethereum:
Caption: Why stateless Ethereum?
Source: Guillaume Ballet and Josh Rudolf
Over the past six months, Ballet and Rudolf have shipped several versions of migrating MPTs to Verkle Tries. Rudolf said that the latest Verkle block processing times have been benchmarked to be 20% slower than MPT block processing times. Rudolf also mentioned that several client teams including Nethermind, Geth, EthereumJS, Erigon, Lighthouse, and Lodestar have been participating in early implementations and testnets. Ballet and Rudolf are now preparing to test their implementation of Verkle Tries in a shadow fork of mainnet Ethereum. They encouraged developers to join in on their Verkle Implementers Calls and their #verkle-trie-migration Discord channel.