Ethereum All Core Developers Execution Call #168 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.
ERC/EIP Split
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.
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.