Author: Christine Kim / Source: https://www.galaxy.com/insights/research/ethereum-all-core-d
Translation: Huohuo / Plain Language Blockchain
On August 31, 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 development and testing progress of the following aspects:
1) Cancun/Deneb upgrade
- Reassessing Layer2 and Rollup from the risk rating indicators of L2BEAT
- LianGuai Morning Post | US SEC accuses Hawaiian man of implementing a false cryptocurrency pump and dump scheme
- Weekly Announcement | Connext will airdrop its native token Next on September 5th; ImmutableX (IMX) unlocks tokens worth nearly tens of millions of dollars.
2) Verkle Trie transformation
3) SSZ serialization update
1. Cancun Upgrade
Devnet #8 was launched on August 16, two weeks ago. Barnabas Busa, a DevOps engineer at the Ethereum Foundation, said that the developer-centric Cancun upgrade testnet seems to be running well. Busa mentioned that there seem to be some issues with nodes running the Nethermind (EL) client software. Lukasz Rozmej, a developer of 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.)
Regarding EIP 4788, developers briefly reaffirmed 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 to the contract address before the upgrade is activated. The next testnet for the Cancun upgrade, Devnet #9, will follow this workflow and ensure that 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 have confidence in Devnet #9 than to say, we hope these things work out…. I’d rather address the known issues. Otherwise, if we hit hard issues in Devnet #9, then we’re definitely going to have a Devnet #10, and I’m not saying we shouldn’t have a Devnet #10. We should have a meaningful number of development networks. I think we can try to make Devnet #9 truly reliable at this point,” said Danny Ryan, a researcher at the Ethereum Foundation and chair of the ACDC conference call.
Others on the conference 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. As for the testnet deployment strategy, Beiko suggested the following order:
1) Devnet #9: Another Devnet with the Dencun specification frozen. Stress test the network and assume developers are satisfied, then move to the public testnet. Otherwise, launch Devnet #10.
2) Holesky: Holesky, a new fork, has launched its testnet and deployed the Dencun upgrade on it.
3) Goerli: Then, the Dencun upgrade was deployed on Goerli. As the second-to-last 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 activation. 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, and Deneb is the name of the protocol layer upgrade. Therefore, the combined upgrade of Cancun and Deneb is called Dencun upgrade.)
4) Sepolia: Finally, the Dencun upgrade was deployed on Sepolia to achieve good results.
There were no objections to Beiko’s proposal to release the 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 named Ephemery is under development. Ephemery is an Ethereum testnet aimed at validator node operators and will be reset to genesis state in one or two weeks. For more information about the Ephemery network, please read 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 proposed canceling the specific activation time for the Dencun upgrade on Holesky. The developers will later set a value for the activation of Dencun on Holesky instead of overwriting the existing value. Busa also raised the issue of testing the 3/6 blob target/max value (instead of the 2/4 limit). On this topic, Beiko suggested bringing up this question again in next week’s ACDC conference call, and Ryan mentioned that recent experiments on large block sizes will bring new insights.
2. Verkle Trie Conversion
Next, the developers discussed Vitalik Buterin’s proposal to combine Verkle Trie and the State Expiry roadmap to reduce the complexity of implementing Verkle Trie 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 a large amount of data with a single cryptographic proof. They are not much different from Merkle Patricia Trie (MPT), which is a data structure used to store the 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 expiry is a separate plan aimed at addressing the issue of unlimited growth of the state. The goal of state expiry is to delete parts 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 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, expressed concerns that coupling would delay Verkle Tries as state expiry has been “abandoned” as a research topic in the past two years.
Buterin provided more background information on his proposal motivation, saying, “With the transition of [Verkle], the problem is essentially converting over 50 GB of Merkle Patricia Tries into… Verkle Tries in a real-time network is quite complex. This has been a source of frustration for the research team for over a year. I remember last year at Devcon, it was basically the theme of the research activities, essentially as much development work as the rest of the Verkle roadmap put together, just how to go about the final transition process. In some ways, its complexity can indeed rival that of the merge.”
Buterin continued to discuss 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 periods” each year. Therefore, while the complexity of implementing Verkle would be reduced, developers still need to address the challenges of implementing both simultaneously. Additionally, if Verkle Tries are implemented before State Expiry, the urgency of State Expiry would be reduced, so developers should consider transitioning with Verkle or wait a few years to introduce State Expiry after Verkle. Developers are not clear on the additional value that bundling these two upgrades together would bring and agree to continue discussing this topic asynchronously on Discord and Verkle Trie Implementors’ Call.
3. SSZ Serialization
Next, Etan Kissling, a developer of the Nimbus (CL) client, provided updates on the latest progress of upgrading Ethereum data structures to the SSZ serialization format. For more background information on this issue, please read the previous Ethereum developer call notes here. Kissling emphasized a new approach to updating Ethereum data serialization using a format based on SSZ “LianGuairtialContainer.” In his comments during 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, thus eliminating the currently unused SSZ Union and SSZ Optional types.”
After the update, Beiko quickly commended 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 Ethereum execution client core components, focusing on readability and clarity. EELS aims to be the spiritual successor to the Yellow Paper, more programmer-friendly, and 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 already been using EELS to reimplement their EIPs, and the Ethereum Foundation is offering a grant to anyone interested in updating the Yellow Paper, including missing pre-merge network upgrades like London and Paris, to complement 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!
