Summary of the 116th Ethereum Core Developer Executive Meeting: Cancun Upgrade, Verkle Trie Conversion, and SSZ Serialization

Author: Christine Kim / Source:

Translation: Huohuo/Blockchain in Vernacular

On August 31, Ethereum developers gathered on Zoom for the Core Developers (ACDE) conference call. Hosted by the Ethereum Foundation’s Tim Beiko, the ACDE call is a biweekly series of meetings where the Ethereum client team discusses and coordinates changes to the Ethereum Execution Layer (EL). This week, developers discussed development and testing progress on:

1. Cancun/Deneb (Dencun) upgrade

2. Verkle Trie conversion

3. SSZ serialization update

1. Cancun upgrade

Devnet #8 launched two weeks ago on August 16th. Barnabas Busa, a DevOps engineer at the Ethereum Foundation, said the developer-focused Cancun upgrade testnet appears to be working well. Busa mentioned that there appeared to be some issues with nodes running the Nethermind (EL) client software. The developer of the Nethermind client, Lukasz Rozmej, explained that the essence of the problem was due to a misconfiguration in the blob transaction pool implementation. (Translator's Note: Devnet 8 is the first dedicated testnet that contains all finalized EIPs for the Cancun/Deneb upgrade)

Regarding EIP 4788, the developers briefly reaffirmed the new deployment strategy for code changes. Contracts that expose beacon chain data on EL will be deployed like regular smart contracts, requiring someone to fund the contract address before the upgrade activates. Devnet #9, the next testnet of the Cancun upgrade, will adopt this workflow and ensure that developers are familiar with the process.

Instead of pushing back the Devnet #9 release date, the developers agreed to continue testing on Devnet #8 until all issues with the client implementation are resolved. "I'd rather have confidence in Devnet #9 than say we want these things to work. ... I'd rather fix problems we know. Otherwise, if we have a hard problem in Devnet #9 , then we'll definitely have Devnet #10 again, I'm not saying we shouldn't have Devnet #10. We should have a meaningful number of devnets. I think now we can try to make Devnet #9 really reliable." Ether said Danny Ryan, fellow at the Fang Foundation and chair of the ACDC conference call.

Others on the call, including Tim Beiko, Marius Van Der Wijden and Justin Florentine, were in favor of spending more time testing on Devnet #8 and later testing the changes in EIP 4788 on Devnet #9. Beiko suggested a time for developers to reconvene Devnet #9 during the next ACDE conference call. Regarding testnet deployment strategies, Beiko recommends the following sequence:

1. Devnet #9: Another Devnet whose Dencun specification has been frozen. Stress test the network and assume developers are happy with it, then move to a public testnet. Otherwise, start Devnet #10.

2. Holesky: Fork the newly launched Holeksy testnet and deploy the Dencun upgrade on it.

3. Goerli: Then deploy Dencun on Goerli. As the launch of the penultimate testnet before the mainnet, the upgrade specification at this time should be final and provide enough time for users and applications to test their software before the mainnet upgrade activates. Dencun is likely to be the last fork on Goerli before it is deprecated and replaced by Holesky. (Translator's Note: The word Dencun is a compound word composed of Cancun (Cancun) and Deneb. Cancun is the name of the Ethereum execution layer upgrade, while Deneb is the name of the protocol layer upgrade. Therefore, Cancun upgrade and Deneb The upgrades are collectively called Dencun upgrades.)

4. Sepolia: Finally, Dencun was deployed on Sepolia to achieve good results.

No one objected to Beiko's proposal to release a testnet after Devnet #9. Beiko mentioned that the aforementioned timeline will be shared with the wider ethereum community in a blog post once the Holesky testnet officially launches on September 15. In addition, Beiko said there is also a testnet called Ephemery under development. Ehemery is an Ethereum testnet for verification node operators that will reset back to the genesis state after a week or two. For more information about the Ephemery Network, read the project's GitHub page here.

Before moving on to discuss Verkle Tries, Busa highlighted an open pull request (PR) on GitHub for the Holesky testnet. At the request of the Erigon (EL) team, the PR proposes to remove the specific activation time for the Dencun upgrade on Holesky. The developer will later set a value for Dencun activation on Holesky rather than overwriting the existing value. Busa also asked about testing the 3/6 blob target/max instead of the 2/4 limit. On this topic, Beiko suggested raising the issue again on next week's ACDC call, with Ryan mentioning that recent experiments with large block sizes will bring new insights.

2. Verkle Trie conversion

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 accelerate State Expiry’s benefits on Ethereum. As background, a Verkle Trie or Verkle Tree is a data structure that allows users to easily verify large amounts of data relying on a single cryptographic proof. They are no different from Merkle Patricia Trie (MPT), which is a data structure used to store Ethereum state. However, the proof efficiency of Verkle trees is relatively higher than MPT, which is why developers have been working on transitioning MPT to Verkle.

State Expiration is a separate initiative designed to address the problem of unlimited state growth. The goal of state expiration is to delete parts of the Ethereum state that users haven't accessed for a period of time (eg, 365 days), thereby reducing the state size from over 100 GB to less than 50 GB. Andrew Ashikhmin of the Erigon (EL) Account Team favored bundling the two upgrades, assuming that Verkle Trie conversion would be greatly simplified if combined with State Expiry. Guillaume Ballet from the Geth (EL) client team, who has been leading the Verkle Trie project, is concerned that the coupling will delay Verkle Tries, as state expiration as a research topic has been "abandoned" over the past two years.

Buterin added more background on his proposal's motivations, saying: "With [Verkle] The transition process, the problem is basically converting 50+ GB of Merkle Patricia Trie to... Verkle Trie in a live network is just quite complicated. This is indeed something that the research team has been struggling with for more than a year. I remember last year at Devconnect, it was basically the subject of a research event and basically as much R&D work as the whole rest of the Verkle roadmap put together, just the process of how to make that last transition. In some ways, its complexity is indeed comparable to that of mergers. "

Buterin went on to describe how State Expiry significantly reduces the complexity of transitioning to Verkle. However, he also mentioned that state expiration has complex prerequisites, such as the need to add more address spaces to support new "address periods" every year. So while the complexity of implementing Verkle will decrease, developers still need Solving the puzzle is required to do both simultaneously. Additionally, if Verkle Tries is implemented before State Expiry, State Expiry will have less urgency, so developers should consider using Verkle for the transition, or wait a few years for State Expiry to be introduced after Verkle. Development The staff was unclear about the additional value that would result from bundling these two upgrades together, and agreed to continue discussing the topic asynchronously on Discord and the Verkle Trie Implementors' Call.

3. SSZ serialization

Then, Etan Kissling, developer of the Nimbus (CL) client, presented an update on his progress in upgrading Ethereum data structures to the SSZ serialization format. For more background on this issue, read the transcript of a previous Ethereum developer call here. Kissling highlighted a new approach to updating Ethereum data serialization using an SSZ "PartialContainer" based format. In comments under this week's conference call agenda, Kissling wrote, "This [format] essentially combines all the advantages of [the previous format] and can also be reused for other purposes, thereby phasing out the currently unused SSZ Union and SSZ optional type." (Translator's Note: Simple Serialization (SSZ) is the serialization method used on the beacon chain. This method replaces the implementation layer used everywhere in the consensus layer except the peer discovery protocol. Recursive length-prefixed serialization. Simple serialization is deterministic by design and can also be effectively Merkleized.)

After the update, Beiko was quick to praise the newly created EL reference implementation in Python (called EELS). In a recent Ethereum Foundation blog post, EIP editor and Ethereum Foundation researcher Sam Wilson wrote: “EELS is a Python reference implementation of the core components of the Ethereum execution client, focusing on readability and clarity. EELS is designed to be a spiritual successor to the Yellow Paper, more programmer-friendly and in sync with post-merge forks, EELS can fill out and execute stateful tests, adhere to mainnet, and is a great place to prototype new EIPs.”

Some developers are already using EELS to reimplement their EIPs, and the Ethereum Foundation is offering a grant to anyone interested in updating the Yellow Paper to include missing pre-merged network upgrades like London and Paris to complement EELS .