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.
EIP 4788
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.
EIP 6780
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.
Engine API
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.
Cancun Testing
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.
Account Abstraction
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.
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.