{"id":128126,"date":"2025-04-28T14:15:36","date_gmt":"2025-04-28T14:15:36","guid":{"rendered":"http:\/\/cryptospotters.net\/?p=128126"},"modified":"2025-04-28T14:15:36","modified_gmt":"2025-04-28T14:15:36","slug":"ethereum-fusaka-scheduled-for-late-2025-evm-upgrade-likely-included","status":"publish","type":"post","link":"http:\/\/cryptospotters.net\/?p=128126","title":{"rendered":"Ethereum Fusaka scheduled for late 2025: EVM upgrade likely included"},"content":{"rendered":"<p>Source: Cointelegraph.com NewsEthereum\u2019s Fusaka hard fork is expected to take place in the third or fourth quarter of this year, according to an Ethereum Foundation official.<br \/>\nIn an April 28 X post, Ethereum Foundation co-executive director Tomasz Kajetan Sta\u0144czak said that the organization is aiming to deploy the Fusaka Ethereum network upgrade in Q3 or Q4 2025. Still, the exact rollout schedule has not been decided yet.<br \/>\nThe comments come amid controversies over the upcoming implementation of the EVM object format (EOF) upgrade for the Ethereum Virtual Machine (EVM). As Sta\u0144czak pointed out, EOF is expected to be a part of the Fusaka network upgrade.<br \/>\nSource: Tomasz Kajetan Sta\u0144czakThe EVM is the software that runs Ethereum smart contracts. EOF would implement a series of protocol changes, known as Ethereum improvement proposals (EIPs), with profound implications for how it operates. EOF introduces an extensible and versioned container format for the smart contract bytecode that is verified once at deployment, separating code and data for efficiency gains.<br \/>\nRelated: Researcher proposes scaling Ethereum gas limit by 100x over 4 years<br \/>\nWrap, stamp once, send<br \/>\nBytecode is a low-level, compact set of instructions. Solidity smart contracts must be compiled into bytecode before the EVM can execute them.<br \/>\nEOF defines a container module for smart contract bytecode, replacing today\u2019s free-form bytecode blobs with a better-defined structure. These objects would be composed of:<\/p>\n<p>A header starting with the 0xEF00 hexadecimal value, followed by a one-byte version number to ensure upgradability.<br \/>\nA section table, providing metadata about the contents of the container. Each entry comprises one byte setting for the kind of entry and two bytes for the entry\u2019s size.<br \/>\nSections with the actual content, with at least one code section and any necessary data sections \u2014 more types of sections could be added through future EIPs.<\/p>\n<p>This structure streamlines EVM operation, allowing for higher efficiency and lower processing overhead. This upgrade would result in a cleaner developer environment and easier-to-understand deployed smart contracts.<br \/>\nDon\u2019t JUMP, RJUMP instead!<br \/>\nEIP-4200, one of the EOF EIPs, provides an alternative to the JUMP and JUMPI instructions, which allow the program to move execution to any arbitrary byte offset. This kind of execution chain leads to hard-to-spot bugs (the JUMP value being wrong in some instances may not be easy to predict) and makes it easy to hide malware in data blobs and move the execution pointer there.<br \/>\nThis practice is known as dynamic jump, and EIP-4750 (under review) proposes disallowing dynamic JUMP\/JUMPI inside EOF smart contracts, rejecting them entirely during a later phase of EOF deployment. In its current form, this EIP replaces them with call function (CALLF) and return from function (RETF) function calls. Those new instructions would ensure that destinations are hardcoded into the bytecode, but legacy pre-EOF smart contracts would be unaffected.<br \/>\nDevelopers who opt to use JUMP or JUMPI after the upgrade will have their bytecode go through deploy-time validation, which ensures that they can never jump into data or the middle of another instruction. This verification would take place via\u00a0EIP-3670\u2019s code-validation rules, plus the jump table (EIP-3690), so every destination is checked.<br \/>\nAs an alternative to those functions, EOF implements RJUMP and RJUMPI instead, which require the destination to be hardcoded in the bytecode. Still, not everyone is on board with EOF implementation.<br \/>\nRelated: Ethereum community members propose new fee structure for the app layer<br \/>\nEOF has its haters<br \/>\nEOF is the implementation of 12 EIPs with profound implications for how smart contract developers work. Its supporters argue that it is efficient, more elegant, and allows for easier upgrades down the line.<br \/>\nStill, its detractors argue that it is over-engineered and introduces further complexity into an already complex system such as Ethereum. Ethereum developer Pascal Caversaccio lamented in a March 13 Ethereum Magicians post that \u201cEOF is extremely complex,\u201d as it adds two new semantics and removes and adds over a dozen opcodes. Also, he argued that it is not necessary.<br \/>\nHe said all the benefits could be introduced in \u201cmore piecemeal, less invasive updates.\u201d He added that the legacy EVM would also need to be maintained, \u201cprobably indefinitely.\u201d<br \/>\nCaversaccio also explained that EOF would require a tooling upgrade, which risks introducing new vulnerabilities due to its large attack surface. Also, he said, \u201cEVM contracts get much more complicated due to headers,\u201d while currently empty contracts weigh just 15 bytes. Another developer raised a separate point in the thread:<br \/>\n\u201cPerhaps as a meta point, there seems to be disagreement about whether major EVM changes are desirable in general. A stable VM, on which people can invest in building up excellent tooling and apps with confidence, is much more valuable.\u201c<br \/>\nCaversaccio appears to be in good company in his opposition to EOF. A dedicated poll on the Ethereum polling platform ETHPulse shows that 39 voters holding a total of nearly 17,745 Ether (ETH) are opposed to the upgrade. Only seven holders of under 300 ETH voted in favor.<br \/>\nEthereum EOF implementation approval pool. Source: ETHPulseMagazine: Ethereum is destroying the competition in the $16.1T TradFi tokenization race<a href=\"https:\/\/cointelegraph.com\/news\/ethereum-fusaka-upgrade-scheduled-for-q3-q4-2025?utm_source=rss_feed&amp;utm_medium=rss&amp;utm_campaign=rss_partner_inbound\" target=\"_blank\" class=\"feedzy-rss-link-icon\" rel=\"noopener\">Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"<p>Source: Cointelegraph.com NewsEthereum\u2019s Fusaka hard fork is expected to take place in the third or fourth quarter of this year, according to an Ethereum Foundation official. In an April 28&hellip; <\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"_links":{"self":[{"href":"http:\/\/cryptospotters.net\/index.php?rest_route=\/wp\/v2\/posts\/128126"}],"collection":[{"href":"http:\/\/cryptospotters.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/cryptospotters.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"http:\/\/cryptospotters.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=128126"}],"version-history":[{"count":0,"href":"http:\/\/cryptospotters.net\/index.php?rest_route=\/wp\/v2\/posts\/128126\/revisions"}],"wp:attachment":[{"href":"http:\/\/cryptospotters.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=128126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/cryptospotters.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=128126"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/cryptospotters.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=128126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}