Ethereum All Core Developers Execution Call #177 Writeup
On December 21, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #177. Chaired by the Ethereum Foundation’s Protocol Support Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers set tentative dates for activating the Cancun/Deneb upgrade on all three public Ethereum test networks. The schedule for testnet upgrades is as follows:
Goerli fork on January 17
Sepolia fork on January 31
Holesky fork on February 7
The above dates are subject to change as developers may need to update them due to unexpected bugs and issues with client releases over the next several weeks.
Developers also discussed the performance of the second Goerli shadow fork, precompile address ranges for Layer-2s (L2s), and expectations for the Prague/Electra upgrade.
Developers agreed to cancel next Thursday’s All Core Developers Consensus (ACDC) call on December 28 and reconvene for regular ACD meetings on Thursday, January 4.
Goerli Shadow Fork
The Ethereum Foundation DevOps team launched a second shadow fork of the Goerli testnet on Tuesday, December 19. The shadow fork was activated by 290 nodes, each running 100 validators, distributed across New York, Frankfurt, Bangalore, and Sydney. Almost all Ethereum clients, except for the Erigon client, were able to join the shadow fork and upgrade successfully. Parithosh Jayanthi, a DevOps Engineer at the Foundation, said the network participation rate has ranged between 99% to 100% since the launch of the fork, indicating nearly all validators on the Goerli shadow fork are connecting to the network correctly.
He noted that due to the Cancun/Deneb upgrade, nodes on the network are experiencing a roughly 200kbps increase in bandwidth on average. Despite this, the network has not seen any block reorganization events or severe delays in block propagation, even during blob spamming and blob delay tests. However, Jayanthi also noted that block propagation events are emitted differently depending on the CL client. Certain CL clients will emit an event log for a block before blobs are verified, while others will only emit events after verification. To read a more detailed analysis on Goerli Shadow Fork (GSF) #1, refer to this writeup written by the DevOps team.
Jayanthi said that the DevOps team plan on deprecating GSF #1 by the end of day on Thursday, December 21. Gajinder Singh, a developer for the Lodestar and EthereumJS clients, noted that he is still doing additional tests on the shadow fork. Jayanthi agreed to check with Singh to make sure he can replicate those tests on Devnet #12 before shutting down GSF #1.
Next Steps
Based on the outcome of GSF #1, developers discussed the next steps for testing the Cancun/Deneb upgrade. Beiko asked whether the Prysm client team would feel comfortable with a tentative fork date for the Goerli testnet in January. James He, a developer for the Prysm client, said that this team was still working on resolving a few bugs in their client and would be looking at a tentative release date for a fixed version by January 8. Other client teams were also in favor of a Goerli fork date sometime in mid-January, rather than late January. Developers tentatively agreed to activate Cancun/Deneb on Goerli on January 17.
Beiko said that client teams will need to share updated releases for their software by January 8 or 9 at the latest so that Goerli node operators can have time to upgrade their machines if they move forward with a January 17 fork date. Beiko will also release a blog post announcing the Goerli fork date on the Ethereum Foundation blog the week of January 8 so that Goerli users are aware of the network-wide upgrade.
Ansgar Dietrichs asked whether developers should also tentatively schedule target dates for the two other Ethereum public testnets that will be upgraded before Ethereum mainnet. After some discussion, developers agreed to aim for a target upgrade date for the Sepolia testnet two weeks after Goerli on January 31 and an upgrade date for the Holesky testnet one week thereafter on February 7. Developers plan on bundling a single client release and announcement post for the Sepolia and Holesky testnet upgrades so that they can have a shorter, one-week turnaround time between these two Cancun/Deneb activations. “I think in the past we often had fewer testnets, so bundling releases seems like a good pragmatic choice,” said Dietrichs in the Zoom chat.
Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, mentioned that upgrading the Holesky testnet before Sepolia may be more useful to catch bugs related to networking early on as Holesky hosts a higher number of validators than the Sepolia testnet. However, while smaller, Sepolia hosts more active users than Holesky and therefore, may offer L2 teams more time to test their operations if it is upgraded first before Holesky. Developers agreed to stick with upgrading Sepolia before Holesky for now and revisit this order after the Goerli fork. “I think the most we’re going to learn is from Goerli because the validator set is small enough. There are a lot of esoteric [node] setups and so on,” said Jayanthi.
Precompile Address Ranges
Then, developers discussed the topic of precompile address ranges for L2s. As background, precompiles are addresses on Ethereum that behave like smart contracts and enable complex cryptographic computations that would otherwise be too costly to execute directly through the Ethereum execution engine, called the Ethereum Virtual Machine (EVM). SHA3, RIPEMD160, and BLAKE2 are examples of hash functions already supported by precompiles on Ethereum. As L2s look to expand smart contract execution functionality through the addition of new precompiles that may not necessarily exist yet on Ethereum, there is the question of whether L2s should use precompile addresses that Ethereum may one day use.
Dietrichs explained in a comment on GitHub, “In the future many new EVM precompiles will be introduced on (some or all) L2s first … They then might or might not later also be shipped to L1. It would be highly desirable to come up with a precompile address scheme that ensures that the address for any given RIP precompile is reserved on L1, meaning that no other conflicting precompile is ever introduced on that address [and] is used for that RIP precompile, if it is ever introduced on L1 in identical form.” RIP refers to the newly created “Rollup Improvement Proposal” process. The RIP process is a voluntary opt-in standard for L2s designed to encourage standardization and coordination for EVM related changes. One of the first precompiles that L2s are looking to adopt in a standardized way is the precompile for signature verification in the secp256r1 elliptic curve. For more information about this proposal, read the RIP document here.
Dietrichs said on the call that there are two options that L2s can take for assigning an address to this precompile. EVM changes that start on L2s first can be assigned a number within the precompile address range that is identical to Ethereum or use a range that is separate from Ethereum precompiles. Ethereum Foundation Researcher Danny Ryan was in favor of L2s using addresses in a different range given that there is still a lot of uncertainty about the RIP process. “I’m pro adding a range for L2s and if there is significant adoption of an EIP before L1 adopts it, to use disjoint sequencing and use what was selected from that range for L1 because it’s very unclear at this point what’s going to happen with RIPs,” said Ryan.
Geth developer Marius van der Wijden was also in favor of a disjointed address range for precompiles adopted by L2s before they are adopted on Ethereum. He also added that developers should discuss whether the same address should be used on the L1 as the L2 on a case-by-case basis. “I’m not 100% sold on just using what [L2s] propose. I think there needs to be a debate about that,” said van der Wijden.
Ryan added that creating the optionality of using different precompile addresses and decoupling the Ethereum Improvement Proposal (EIP) process from the RIP process is especially important in the event of changes to precompile functionality on L2s. However, Ethereum Foundation Researcher Carl Beekhuizen pushed back on this idea of using different precompile addresses between L2s and Ethereum mainnet, saying, “It just seems silly to potentially lose out on all the synergies just because there’s a potential for change in the future, like we just default into a worst case scenario unnecessarily.”
Due to the controversy, Dietrichs suggested that L2s use a separate precompile address range from Ethereum mainnet for now. He added that developers can decide later whether they want to use the same precompile address as the one implemented on L2s when the time comes to activate a new precompile on Ethereum that is already widely adopted on L2s. Regarding the custom address range, developers agreed to reserve the 0x512 address range for use by L2s through the RIP process. Developers also agreed to create a new informational EIP that states this and references to the RIP GitHub repository for additional information on which addresses have been used for precompiles by L2s.
ACD Call Schedule
As discussed on ACDC #124, developers will be skipping next Thursday’s ACD call and instead do an informal check-in over Discord. They will reconvene for ACDE #178 on Thursday, January 4. ACDE #178 will be chaired by Geth developer “lightclient”, in place of Beiko who will not be in attendance for the call.
Prague/Electra Proposals
As a final topic of discussion, Beiko called for attention from developers on the Ethereum Magicians thread for the Prague/Electra upgrade. Beiko stressed that client teams should review the proposals for Prague/Electra and be ready to discuss which code changes should be prioritized for the next Ethereum upgrade. About the scope of Prague/Electra, Dietrichs mentioned that developers should try to aim for the activation of a small upgrade before the end of 2024 after Cancun/Deneb, instead of trying to bundle complex code changes together, which may delay the activation of more time sensitive EIPs. Ryan added that developers do not have to do a “cross layer fork” for the Prague/Electra upgrade. Code changes for the EL and CL can be shipped independently from each other.
The major code change that developers expect to activate on the EL shortly after the Cancun upgrade is the Verkle Trie upgrade. As discussed on prior calls, the upgrade to replace the current use of Merkle Patricia Trees for data organization with more powerful Verkle trees has made significant progress over the past year and may be ready for implementation in 2024. However, due to the complexity and risk associated with the upgrade, Geth developer Guillaume Ballet said that the Verkle upgrade should not be paired with other complex code changes or EIPs. Developers agreed to revisit the conversation on a “Verkle only upgrade” in the new year. They also agreed to schedule a dedicated ACDE call to discuss the details of the Verkle upgrade more deeply.
As an aside, Dietrichs mentioned that data availability sampling, which is an upgrade to reduce the costs for data availability on Ethereum, is making “good progress” and will likely not need any in-protocol changes when ready for implementation on the CL. For more information about data availability and blockchain modularity, read this Galaxy Research report.
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.