Author: Christine Kim, galaxy; Translator: Huohuo / Plain Language Blockchain
On August 31st, Ethereum developers gathered on Zoom for the Core Developers Execution (ACDE) conference call. The ACDE conference call, hosted by Tim Beiko of the Ethereum Foundation, is a bi-weekly series of meetings where Ethereum client teams discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed the following development and testing progress:
1) Cancun/Deneb (Dencun) upgrade
2) Verkle Trie transformation
- Taking down $200 million TVL in one day, a detailed explanation of how the core mechanism Ve(3,3) of Aerodrome ‘flash attacks’ Base?
- Did CYBER’s first on-chain proposal end in failure? A review of the CYBER governance farce.
- Ethereum Core Developer Meeting Summary Cancun Upgrade, Verkle Trie Transformation, and SSZ Serialization
3) SSZ serialization update
1. Cancun Upgrade
Devnet #8 was launched two weeks ago on August 16th. Barnabas Busa, DevOps engineer at the Ethereum Foundation, said that the developer-centric Cancun upgrade testnet seems to be running smoothly. Busa mentioned that there seems to be some issues with nodes running the Nethermind (EL) client software. Lukasz Rozmej, a developer for the Nethermind client, explained that the nature of the problem is due to a configuration error in the Blob transaction pool implementation. (Translator’s note: Devnet 8 is the first dedicated testnet that includes all finalized EIPs for the Cancun/Deneb upgrade.)
About EIP 4788, developers briefly reconfirmed the new deployment strategy for code changes. Contracts that publicly expose beacon chain data on the EL will be deployed like regular smart contracts, requiring someone to provide funds for the contract address before the upgrade is activated. The next testnet for the Cancun upgrade, Devnet #9, will follow this workflow and ensure developers are familiar with the process.
Developers did not postpone the release date of Devnet #9 but agreed to continue testing on Devnet #8 until all issues with client implementations are resolved. “I’d rather be confident about Devnet #9 than say we hope these things work out…. I’d rather address the known issues. Otherwise, if we encounter difficult issues in Devnet #9, then we’ll definitely have a Devnet #10, and I’m not saying we shouldn’t have Devnet #10. We should have a meaningful number of development networks. I think now we can try to make Devnet #9 really reliable,” said Danny Ryan, a researcher at the Ethereum Foundation and chair of the ACDE conference call.
Others on the call, including Tim Beiko, Marius Van Der Wijden, and Justin Florentine, agreed to spend more time testing on Devnet #8 and test the changes in EIP 4788 on Devnet #9 later. Beiko suggested reconvening Devnet #9 during the next ACDE conference call. Regarding the testnet deployment strategy, Beiko proposed the following sequence:
1) Devnet #9: Another Devnet with the Dencun spec frozen. Stress test the network and assuming developers are satisfied, transition to the public testnet. Otherwise, launch Devnet #10.
2) Holesky: The newly launched Holeksy testnet for the fork and the deployment of Dencun on top of it.
3) Goerli: Then deploy Dencun on Goerli. As the second-to-last testnet before the mainnet, the upgrade specification at this time should be final, providing users and applications with enough time to test their software before the mainnet upgrade is activated. Dencun is likely to be the last fork on Goerli before it is deprecated and replaced by Holesky. (Translator’s Note: Dencun is a compound word composed of “Cancun” and “Deneb”. Cancun is the name of the Ethereum execution layer upgrade, while Deneb is the name of the protocol layer upgrade. Therefore, the Cancun upgrade and the Deneb upgrade are collectively referred to as the Dencun upgrade.)
4) Sepolia: Finally, deploy Dencun on Sepolia for optimal results.
There were no objections to Beiko’s proposal to release a testnet after Devnet #9. Beiko mentioned that once the Holesky testnet officially launches on September 15th, the above schedule will be shared with the wider Ethereum community in a blog post. In addition, Beiko mentioned that another testnet called Ephemery is currently under development. Ephemery is an Ethereum testnet aimed at validator node operators and will be reset to the genesis state in one to two weeks. For more information about the Ephemery network, please refer to the project’s GitHub page.
Before continuing the discussion on Verkle Tries, Busa emphasized the open pull requests (PR) on GitHub for the Holesky testnet. At the request of the Erigon (EL) team, the PR suggested removing the specific activation time for the Dencun upgrade on Holesky. Developers will later set a value for the activation of Dencun on Holesky instead of rewriting the existing value. Busa also raised the question about the 3/6 blob target/max (instead of 2/4 limits) for testing. Regarding this topic, Beiko suggested raising this question again at next week’s ACDC conference call, and Ryan mentioned that recent experiments with larger block sizes will bring new insights.
2. Verkle Trie Transformation
Next, the developers discussed Vitalik Buterin’s proposal to combine Verkle Trie and the State Expiry roadmap to reduce the complexity of Verkle Trie implementation and accelerate the benefits of State Expiry on Ethereum. As background, Verkle Trie or Verkle Tree is a data structure that allows users to easily verify large amounts of data with a single cryptographic proof. They are not much different from the Merkle Patricia Trie (MPT), which is a data structure used for storing Ethereum state. However, the proof efficiency of Verkle Trees is relatively higher than MPT, which is why developers have been working to transition from MPT to Verkle.
State Expiry is a separate plan aimed at addressing the problem of unlimited growth in state. The goal of state expiry is to remove portions of the Ethereum state that have not been accessed by users for a certain period of time (e.g. within 365 days), reducing the state size from over 100 GB to less than 50 GB. Andrew Ashikhmin from the Erigon (EL) client team agreed to bundle these two upgrades together, assuming that the Verkle Trie transformation will be greatly simplified when combined with State Expiry. Guillaume Ballet from the Geth (EL) client team, who has been leading the Verkle Trie project, expressed concerns about the coupling delaying Verkle Tries, as state expiry has been “abandoned” as a research topic in the past two years.
Buterin added more background information on his proposal’s motivation, saying: “With the transition process of [Verkle], the problem is basically converting the more than 50GB Merkle LianGuaitricia Trie into… Verkle Trie in the real-time network, which is quite complex. This has indeed been a concern for the research team for more than a year. I remember last year at Devcon it was basically the theme of the research activities, basically as much development work as the rest of the Verkle roadmap, just how to do the final transition process. In some ways, its complexity can indeed be comparable to merging.”
Buterin continued to explain how State Expiry significantly reduces the complexity of transitioning to Verkle. However, he also mentioned that state expiry has complex prerequisites, such as the need to add more address space to support new “address epochs” “every year. Therefore, although the complexity of implementing Verkle is reduced, developers still need to solve problems in order to simultaneously execute both. In addition, if Verkle Tries are implemented before State Expiry, the urgency of State Expiry will be reduced, so developers should consider using Verkle for the transition or wait a few years to introduce State Expiry after Verkle. Developers are unsure of the additional value that bundling these two upgrades together will bring and agree to continue discussing this topic asynchronously on Discord and Verkle Trie Implementors’ Call.
3. SSZ Serialization
Then, Etan Kissling, a developer of the Nimbus (CL) client, presented the latest progress on upgrading Ethereum’s data structures to the SSZ serialization format. For more background information on this issue, please read the previous Ethereum Developer call records here. Kissling emphasized a new approach to updating Ethereum’s data serialization using the format based on SSZ “LianGuairtialContainer”. In his comments under this week’s conference agenda, Kissling wrote, “This [format] essentially combines all the advantages of [previous formats] and can also be reused for other purposes, thereby eliminating the currently unused SSZ Union and SSZ Optional types.” (Translator’s note: Simple Serialize (SSZ) is the serialization method used on the beacon chain. This method replaces the recursive length prefix serialization used in various execution layers throughout the consensus layer, except for the peer discovery protocol. Simple Serialization is designed to be deterministic and can also be efficiently merkelized.)
After the update, Beiko quickly praised the newly created EL reference implementation in Python (called 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 Ethereum execution clients, focusing on readability and clarity. EELS aims to be the spiritual successor to the Yellow Paper, more friendly to programmers, and stays in sync with the post-merge fork. EELS can fill and execute state tests, follow the mainnet, and is a good place to build new EIP prototypes.”
Some developers have been using EELS to reimplement their EIPs, and the Ethereum Foundation has offered a grant to anyone interested in updating the Yellow Paper to include the missing pre-merge network upgrades such as London and Paris, in addition to EELS.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
