Ethereum adoption has been booming, and the developers working behind the scenes on the network are brewing up another major upgrade.

From scalability to censorship resistance to improving the overall experience, this will be the second in this years timeline for improvements to the decentralized blockchain.

Another Milestone For The Network

The core development team behind the second-largest cryptocurrency by market cap has scheduled the mainnet launch for the Fusaka upgrade, aimed at further improving the network and increasing scalability for early November.

The next Devnet (Devnet-3) is scheduled to launch in two days, and upgrades for Glamsterdam, the upgrade following Fusaka, are set to be decided upon in the coming weeks.

To complete the testing at a faster pace, one Ethereum Improvement Proposal (EIP) was removed 7907, which suggested changes to the size limits of code for smart contracts.

If all goes as planned, this upgrade will arrive just six months after the release of Pectra, showcasing the rapid expansion and development of the network.

Comparatively, Dencun went live in March 2024, boosting the performance of Layer-2 solutions, and Pectra, which brought wallet improvements and increased the validator limit, followed over a year later.

Before we can expect to see Fusaka live, two public test nets will be launched in September and October.

Source: Paragraph Protocol support member Nixo shared his concerns about the current release timeline for Fusaka, citing tight deadlines and the desire for launch by the time Devconnect 2025 starts.

Devconnect is an event showcasing Ethereum apps, which will be hosted in Buenos Aires, Argentina, at the end of November, shortly after Fusaka is meant to go live.

What Can We Expect In The Upgrade?

A plethora of proposals are scheduled to be included in the upcoming Fusaka upgrade later this year.

To note only a part of the list, we can begin with EIP-7594: PeerDAS Peer Data Availability Sampling.

DAS is a method of scaling data availability beyond the levels of EIP-4844, by not requiring all nodes to download all data while still ensuring that all of the information has been made available.

Further, EIP-7825: Transaction Gas Limit Cap, which, as the name suggests, aims to introduce a cap for the gas that can be used in each transaction, whilst also acting as a security improvement for the network.

It would also be worthwhile to mention EIP-7934: RLP Execution Block Size Limit, which proposes introducing a maximum RLP-encoded block size and a margin for the beacon block size, thereby reducing the likelihood of DoS attacks.