Ethereum Fusaka Hard Fork in Late 2025: Controversial EVM Upgrade Looms

Big changes are coming to the Ethereum network. The next major upgrade, known as the Ethereum Fusaka hard fork, is tentatively scheduled for late 2025. This update is expected to bring significant shifts, most notably the potential inclusion of the highly debated EVM upgrade introducing the EVM Object Format (EOF).

When is the Ethereum Fusaka Hard Fork Expected?

According to an official from the Ethereum Foundation, the Fusaka hard fork is currently targeted for the third or fourth quarter of 2025. Ethereum Foundation co-executive director Tomasz Kajetan Stańczak shared this timeline, emphasizing that the exact schedule is still subject to change. This upcoming hard fork follows previous major network upgrades aimed at improving efficiency and functionality.

Understanding the EVM Object Format (EOF)

The core of the expected EVM upgrade in Fusaka is the implementation of the EVM Object Format (EOF). The Ethereum Virtual Machine (EVM) is the runtime environment for Ethereum smart contracts. EOF aims to fundamentally change how the bytecode of these contracts is structured and validated.

Instead of the current free-form bytecode, EOF introduces a structured, versioned container format. Think of it like giving smart contract code a standardized wrapper with clear sections. This structure is verified once at deployment, separating code from data for improved efficiency and lower processing overhead during execution. Key components of an EOF object include:

• A header with a version number for future compatibility.
• A section table providing metadata about the code and data sections.
• Actual content sections, including at least one code section and potentially data sections.

This standardization is intended to create a cleaner environment for developers and make deployed smart contracts easier to understand and work with.

How Does EOF Impact Ethereum Smart Contracts and Jumps?

One significant change brought by EOF relates to control flow within Ethereum smart contracts, specifically addressing the use of JUMP and JUMPI instructions. These instructions allow code execution to jump to arbitrary locations, which can lead to hard-to-find bugs and make it easier to hide malicious code within data sections.

EIP-4200, part of the EOF proposals, introduces alternatives like RJUMP and RJUMPI. These require jump destinations to be hardcoded within the bytecode itself, making the execution flow more predictable and secure. Furthermore, EIP-4750 proposes disallowing dynamic JUMP/JUMPI entirely within EOF contracts in later phases. For developers still using JUMP/JUMPI in EOF contracts, deploy-time validation (using rules from EIP-3670 and EIP-3690) will ensure jumps are only to valid code destinations, preventing jumps into data or the middle of instructions. Legacy pre-EOF contracts would remain unaffected by these specific jump restrictions.

Why is the EOF EVM Upgrade Controversial?

Despite the intended benefits, the proposed EVM upgrade via EOF is not universally supported within the Ethereum community. EOF involves implementing 12 Ethereum Improvement Proposals (EIPs), leading to significant changes in the EVM’s semantics and opcodes.

Supporters highlight the efficiency gains, improved security through structured code and restricted jumps, and easier future upgrades. However, detractors raise concerns:

• **Complexity:** Some developers, like Pascal Caversaccio, argue EOF is overly complex, adding new semantics and significantly altering opcodes, making the system harder to grasp.
• **Necessity:** Critics question if the benefits justify the complexity, suggesting the same improvements could be achieved through less invasive, piecemeal updates.
• **Maintenance:** Implementing EOF means the legacy EVM will likely need continued maintenance alongside the new format.
• **Tooling & Risk:** EOF requires extensive tooling upgrades, which increases the attack surface and risk of introducing new vulnerabilities.
• **Contract Size:** EOF adds headers to contracts, increasing minimum contract size compared to current empty contracts.

There’s also a broader philosophical debate about whether major EVM changes are desirable, with some arguing that a stable VM fosters better tooling and application development confidence. A poll on ETHPulse shows significant opposition, with a large amount of staked Ether voting against the upgrade compared to minimal support.

What Does This Mean for Ethereum Developers and Users?

If the Ethereum Fusaka hard fork proceeds with EOF as planned, developers will need to adapt their tooling and practices to the new bytecode format. While legacy contracts will still function, new contracts aiming for the benefits and future compatibility of EOF will need to follow the new structure and potentially adopt new instructions like RJUMP.

For users, the changes are primarily under the hood, aiming for a more efficient and potentially more secure network in the long run, particularly concerning smart contract execution and preventing certain types of exploits related to dynamic jumps. However, the debate highlights the inherent challenges and disagreements in evolving a complex, decentralized system like Ethereum.

Conclusion: The Road to Ethereum Fusaka

The planned Ethereum Fusaka hard fork in late 2025, featuring the debated EOF EVM upgrade, represents a significant step in the network’s evolution. While proponents see it as a necessary move towards a more efficient and secure future for Ethereum smart contracts, critics point to its complexity and potential disruption. The coming months will likely see continued discussion and refinement of the proposals as the community navigates the path towards this major network alteration.