Ethereum’s Fusaka Hard Fork is expected to take place in the third or fourth quarter of this year, according to officials at the Ethereum Foundation.
On the X-Post on April 28th, Tomasz Kajetan Stańczak, co-executive director of the Ethereum Foundation, said the organization is aiming to roll out the Fusaka Ethereum Network upgrade in 2025.
Comments come amid a controversy over future implementations of Ethereum Virtual Machine (EVM) EVM object format (EOF) upgrades. As Stańczak pointed out, EOF is expected to be part of the Fusaka network upgrade.
EVM is software that runs Ethereum smart contracts. EOF implements a series of protocol changes known as the Ethereum Improvement Proposal (EIPS) that have a major impact on their behavior. EOF introduces an extensible version container format for smart contract bytecode, which is validated once during deployment and isolates data for increased efficiency.
Related: Researchers propose scaling Ethereum gas limits by 100 times over four years
Send one wrap and stamp
ByteCode is a low-level, compact set of instructions. Solidity Smart Contract must be compiled to Bytecode before the EVM can run.
EOF defines a container module for smart contract bytecodes and replaces today’s freeform bytecode blobs with a more clearly defined structure. These objects consist of:
0XEF00 A header starting with the HEXADECIMAL value followed by a 1-byte version number to ensure upgradeability.
A section table that provides metadata about the contents of the container. Each entry consists of one byte setting for the entry type and two bytes in the size of the entry.
Sections with real content with at least one code section and required data sections – more types of sections can be added through future EIPs.
This structure streamlines EVM operation, increases efficiency and lowers overhead. This upgrade will result in a cleaner developer environment and easy to understand deployed smart contracts.
Don’t jump, rjump instead!
One of the EOF EIPs, the EIP-4200 provides an alternative to jumping and jumping instructions. This allows the program to move execution to any byte offset. This kind of execution chain can lead to difficult bugs when spots (in some cases it may not be easy to predict that the jump value is wrong), allowing you to easily hide data blob malware and move the execution pointer there.
This practice is known as dynamic jumps, and the EIP-4750 (in review) proposes allowing dynamic jumps/jumps within EOF smart contracts and rejecting them entirely in the later stages of EOF deployment. In its current form, this EIP replaces them with a calling function (callf) and calls the frommince from function (retf) function call. These new instructions ensure that destinations are hardcoded into Bytecode, but legacy pre-smart contracts are not affected.
Developers who choose to use jumps or jumps after an upgrade will perform deployment time validation on bytecode to ensure that they cannot jump in the middle of data or other instructions. This verification is done through EIP-3670’s code validation rules and jump table (EIP-3690), so all destinations are checked.
As an alternative to these functions, EOF implements rjump and rjumpi instead. Instead, you need to hardcode the destination with bytecode. Still, not everyone is taking part in the EOF implementation.
Related: Ethereum Community Members Propose a New Pricing Structure for the App Tier
EOF has hatred
EOF is an implementation of 12 EIPs that have a major impact on how smart contract developers work. Its supporters claim it is efficient, more elegant and allows for easier upgrades to the line.
Still, the detractors claim it is overdesigned, bringing even more complexity to already complex systems like Ethereum. Ethereum developer Pascal Caversacio lamented in a post on March 13th in Ethereum Magicians, saying, “EOF is extremely complicated.” He also insisted that it was not necessary.
He said all benefits can be introduced with “more fragmented and less invasive updates.” He added that legacy EVMs should also be maintained “probably indefinitely.”
Caversaccio also explained that EOF requires an upgrade of the tool. This risks introducing new vulnerabilities due to the large attack surface. He also said that “EVM contracts will be much more complicated due to the header,” but now the empty contract weighs only 15 bytes. Another developer has raised another point in the thread:
“Perhaps on the meta point is there are disagreements about whether major EVM changes are generally desirable.
Caversacio appears to be in good opposition to EOF. A dedicated poll on the Ethereum Polling Platform Ethpulse shows that 39 voters, holding a total of 17,745 ethers (ETH), are opposed to the upgrade. Only seven holders of ETH below 300 voted in favor.
Magazine: Ethereum is destroying competition in the 16.1T Tradfi tokenized race
