Ethereum All Core Developers Execution Call #169 Writeup
On August 31, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #169. 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 development and testing progress for:
the Cancun/Deneb (Dencun) upgrade,
Verkle Tries transition, and
SSZ serialization update.
Dencun
Devnet #8 launched two weeks ago on August 16. Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, said that the developer-focused testnet for the Dencun upgrade is looking healthy. Busa mentioned that nodes operating the Nethermind (EL) client software appeared to be having some issues. Lukasz Rozmej, a developer for the Nethermind client, explained the nature of the issue was due to misconfigurations in their implementation for the blob transaction pool.
Regarding EIP 4788, developers briefly reconfirmed the new deployment strategy for the code change. The contract to expose Beacon Chain data on the EL will be deployed like a regular smart contract, which requires someone to fund the contract address and do so before upgrade activation. The next testnet for Dencun, Devnet #9, will feature this workflow and ensure developers are comfortable with the process.
Rather than pushing ahead with a launch date for Devnet #9, developers agreed to continue testing on Devnet #8 until all issues with client implementation are resolved. “I’d rather be very confident going into Devnet #9, rather than like saying we hope these things are going to work. … I’d rather iron out the things we know are issues. Otherwise, if we have a high chance issue in Devnet #9 then we certainly will have a Devnet #10 and I’m not saying we shouldn’t have a Devnet #10. We should have the amount of devnets that makes sense. I think at this point we can attempt to have Devnet #9 be really solid,” said Danny Ryan, Ethereum Foundation Researcher and Chair of the ACDC calls.
Other individuals on the calls including Tim Beiko, Marius Van Der Wijden, and Justin Florentine, were all in favor of spending more time testing on Devnet #8 and testing out the change in EIP 4788 on Devnet #9 later. Beiko suggested that developers reconvene on the timing for Devnet #9 during the next ACDE call. About testnet deployment strategy, Beiko suggested the following order:
Devnet #9: One more devnet with Dencun specifications frozen. Stress-test the network and assuming developers are happy with it, move on to public testnets. Otherwise, launch Devnet #10.
Holesky: Fork the newly launched Holeksy testnet and deploy the Dencun upgrade on it.
Goerli: Then deploy Dencun on Goerli. As the second last testnet launch before mainnet, the specifications for the upgrade by this point should be final and provide enough time for users and applications to test their software before mainnet upgrade activation. Dencun will likely be the last fork on Goerli before Goerli is deprecated and replaced with Holesky.
Sepolia: Finally, deploy Dencun on Sepolia for good measure.
There were no objections to Beiko’s proposed ordering for testnet launches post Devnet #9. Beiko mentioned that the above schedule would be shared with the broader Ethereum community in a blog post once the Holesky testnet is officially launched on September 15. Additionally, Beiko said that there is one additional testnet that is in the works called Ephemery. Ephemery is an Ethereum testnet catering to validator node operators that resets back to genesis state after one or two weeks. For more information about the Ephemery network, read the project’s GitHub page here.
Before moving on to a discussion about Verkle Tries, Busa highlighted an open pull request (PR) on GitHub for the Holesky testnet. At request from the Erigon (EL) team, the PR recommends removing a specific activation time for the Dencun upgrade on Holesky. Instead of rewriting over an existing value, developers will set a value for the activation of Dencun on Holesky later. Busa also raised a question around testing for a 3/6 blob target/maximum, instead of the 2/4 limits. On this topic, Beiko suggested raising the issue again on next week’s ACDC call where Ryan mentioned there would be new insights to present from recent experimentation with large block sizes.
Verkle Trie
Next, developers discussed Vitalik Buterin’s proposal to combine the Verkle Trie and State Expiry roadmaps to reduce the complexity of Verkle Trie implementation and expedite the benefits of State Expiry on Ethereum. As background, the Verkle Trie or Verkle Trees are data structures that allow a user to easily verify a large amount of data by relying on a single cryptographic proof. They are not unlike the Merkle Patricia Trie (MPT) which is the data structure used to store Ethereum state. However, Verkle Trees are comparatively more efficient to prove than MPT, which is why developers have been working on transitioning MPT to Verkle.
State Expiry is a separate initiative that addresses the issue of unbounded state growth. The goal of State Expiry is to remove parts of Ethereum state that has not been accessed by a user for a certain period, for example in 365 days, and thereby reduce state size from over 100 GB to less than 50 GB. Andrew Ashikhmin from the Erigon (EL) client team was in favor of bundling the two upgrades together under the assumption that the Verkle Trie transition would be greatly simplified if coupled with State Expiry. Guillaume Ballet from the Geth (EL) client team, who has been spearheading the Verkle Trie project, was concerned the coupling would delay Verkle Tries given that State Expiry as a research topic has been “abandoned” for the last two years.
Buterin chimed in with a bit more context around the motivation of his proposal, saying, “With the transition process [to Verkle], the issue is basically that converting a fifty plus gigabyte Merkle Patricia Trie into … a Verkle Trie in a live network is just pretty complicated. This is something that the Research team literally agonized on for more than a whole year. I remember last year at Devconnect, it was basically the topic as the Research event and it’s basically as much R&D effort as the entire rest of the Verkle roadmap put together probably, just the process of how to do the last transition. It’s literally comparable to the Merge in terms of complexity in some ways.”
Buterin went on to say how State Expiry reduces the complexity of the transition to Verkle significantly. However, he also mentioned that there are complicated pre-requisites to State Expiry such as the need to add more address space to support new “address periods” each year. Therefore, though the complexity of implementing Verkle would go down, developers would still need to tackle hard problems to execute both together. Further, if Verkle Tries are implemented before State Expiry, the urgency for State Expiry reduces such that developers should either consider doing the transition with Verkle or wait several years down the road to introduce State Expiry after Verkle. Developers were unclear about the extra value that would be created from bunding the two upgrades together and agreed to continue discussing the topic asynchronously on Discord and the Verkle Trie Implementors’ Call.
SSZ Serialization
Then, Etan Kissling, a developer for the Nimbus (CL) client, gave an update on his efforts to upgrade Ethereum’s data structures to an SSZ serialization format. For more background on this issue, read prior Ethereum developer call notes here. Kissling highlighted a new approach to updating Ethereum’s data serialization using a SSZ “PartialContainer” based format. In a comment under this week’s call agenda, Kissling wrote, “This [format] essentially combines all the advantages [of prior formats] and could also be reusable for other purposes, sunsetting the currently unused SSZ Union and SSZ Optional types.”
After his update, Beiko gave a quick shout-out for the newly created EL reference implementation in Python, known as EELS. In a recent blog post by the Ethereum Foundation, EIP Editor and Ethereum Foundation Researcher Sam Wilson wrote, “EELS is a Python reference implementation of the core components of an Ethereum execution client focused on readability and clarity. Intended as a spiritual successor to the Yellow Paper that's more programmer friendly and up-to-date with post-merge forks, EELS can fill and execute state tests, follow mainnet, and is a great place to prototype new EIPs.”
Already, some developers are using EELS to reimplement their EIPs and there is a grant funded by the Ethereum Foundation for anyone interested in updating the Yellow Paper to including missing pre-merge network upgrades like London and Paris to supplement EELS.
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.