Ethereum Fusaka hard fork scheduled for late 2025

According to an official from the Ethereum Foundation, Ethereum’s Fusaka hard fork is expected to take place in the third or fourth quarter of 2025.

In an X post on April 28, Tomasz Kajetan Stańczak, co-executive director of the Ethereum Foundation, said that the organization plans to deploy the Fusaka Ethereum network upgrade in the third or fourth quarter of 2025. However, the specific timeline for the rollout has not yet been determined.

Stańczak mentioned that the controversial implementation of the EVM Object Format (EOF) upgrade was expected to be part of the Fusaka network upgrade, but Ethereum core developer Tim Beiko subsequently ruled out this possibility.

“EOF has been removed from the Fusaka network upgrade today,” Beiko said in the X post on April 28, noting in a GitHub post that Ethereum developers decided that there was technical uncertainty about its impact, which could delay the rollout of Fusaka.

Package, stamp once, send

Bytecode is a set of low-level, compact instructions. Solidity smart contracts must be compiled into bytecode before they can be executed by the Ethereum Virtual Machine (EVM).

EOF (Ethereum Improvement Proposal) defines a container module for smart contract bytecode, replacing the current free-form bytecode blocks with a more explicit structure. These objects will consist of the following parts:

Header: Starts with the 0xEF00 hex value, followed by a one-byte version number to ensure upgradeability.

Section table: Provides metadata about the contents of the container. Each entry consists of a one-byte entry type setting and two bytes for the entry size.

Sections for the actual content: Contains at least a code section and any necessary data sections - future EIPs may add more types of sections.

This structure simplifies the operation of the EVM, improves efficiency and reduces processing overhead. This upgrade will lead to a clearer developer environment and more understandable deployed smart contracts.

RJUMP instead of JUMP

EIP-4200 is one of the EOF EIPs and provides an alternative to the JUMP and JUMPI instructions, which allow programs to move execution to any arbitrary byte offset. This chaining of executions can lead to hard-to-find bugs (in some cases, JUMP value errors may not be easy to predict), and makes it easy to hide malware in data blocks and move the execution pointer there.

This practice is called dynamic jumps, and EIP-4750 (under review) proposes to prohibit dynamic JUMP/JUMPI in EOF smart contracts, rejecting them completely in the later stages of EOF deployment. In its current form, this EIP replaces them with Call Function (CALLF) and Return from Function (RETF). These new instructions will ensure that the target is hardcoded in the bytecode, but legacy pre-EOF smart contracts will be unaffected.

Developers who choose to use JUMP or JUMPI after the upgrade will have their bytecode verified at deployment time, ensuring that they cannot jump into the middle of data or other instructions. This verification will be checked by the code validation rules of EIP-3670 as well as the jump table (EIP-3690), so every target will be checked.

As an alternative to these functions, EOF implements RJUMP and RJUMPI, requiring the target to be hard-coded in the bytecode. However, not everyone supports EOF's implementation.

Opponents of EOF

EOF is an implementation of 12 Ethereum Improvement Proposals (EIPs) that have a profound impact on the way smart contract developers work. Its supporters believe that EOF is more efficient, more elegant, and allows for easier future upgrades.

Opponents, however, believe that it is overly complex and introduces more complexity to the already complex Ethereum system. Ethereum developer Pascal Caversaccio said in a March 13 Ethereum Magicians post that "EOF is extremely complex" because it adds two new semantics and removes more than a dozen opcodes. He also believes that it is not necessary.

He pointed out that all the benefits could be achieved through "more detailed and less intrusive updates." He added that the legacy EVM will also need maintenance, "probably indefinitely."

Caversaccio also explained that EOF will require tool upgrades, which may introduce new vulnerabilities due to its larger attack surface. “EVM contracts become more complex because of the headers,” he said, while the current empty contract size is just 15 bytes. Another developer in the discussion offered a different view: “As a meta-view, there seems to be disagreement on whether major EVM changes are needed. A stable virtual machine that allows people to confidently invest in building great tools and applications is more valuable.”

Caversaccio does not appear to be alone in his opposition to EOF. A dedicated poll on Ethereum voting platform ETHPulse showed that 39 voters holding a total of nearly 17,745 Ethereum (ETH) opposed the upgrade. Only seven people holding less than 300 ETH voted in favor.