This is a segment from the 0xResearch newsletter. To read full editions, subscribe.
Ethereum core developers are tuning the protocol’s execution engine for higher throughput and flexibility ahead of the upcoming Fusaka fork. On the June 19 All Core Devs call, contributors aligned on a batch of EIPs for inclusion in Devnet-2 and tee’d up more aggressive performance upgrades for a prospective Devnet-3 (to be confirmed).
The result is a tightly scoped but technically meaningful upgrade, focused not so much on new features, but optimizations. When we covered Fusaka in April, it was still a somewhat mushy amalgamation of ideas: a tentative gas limit increase, early discussions about blob fee fixes and unresolved questions around contract size limits. Two months later, the fork has hardened into a clear package.
Developers have now committed to a 45 million gas ceiling, capped blob submission per transaction, a streamlined 48 KB contract limit (EIP-7907) plus a brand-new opcode (EIP-7939) in CLZ (for “count leading zeros”). Previously contentious parameters like the blob fee floor (EIP-7918) have been settled, setting the stage for Devnet-2 on Monday.
Let’s start with the gas limit increase, which is already under testing and not strictly part of Fusaka. This change, if successful, could bump Ethereum’s transaction capacity by over 11%, but requires careful benchmarking. Developers flagged the need to keep block propagation within safe latencies as a key variable to monitor.
“All the clients seem to be OK with moving ahead with 45 million once the releases are done,” the EF’s Parithosh Jayanthi (commonly referred to as “Pari”) said on the call.
Alongside the throughput boost, developers are refining how blob data — introduced with EIP-4844 during the Dencun upgrade — will be handled. While 4844 enabled cheaper off-chain data availability, it didn’t limit how many blobs a single transaction could include. EIP-7892 closes that gap, capping per-transaction blob usage to prevent any one rollup or dapp from monopolizing blobspace. Meanwhile, EIP-7918 sets a base fee floor and caps the total number of blobs per block, a move to balance scalability and network safety, explained Ben Adams of the Nethermind client team.
“Putting a lower limit on the max size of blobs means you can include more blobs — paradoxically,” Adams said.
Without a floor, the blob base fee can drop to near-zero during low demand, leading to inefficient use of blockspace.
Another low-level improvement greenlit for Devnet-2 is EIP-7939, which introduces a CLZ opcode to the EVM. This might sound obscure, but it’s the kind of tool that power devs reach for when squeezing performance or doing clever things with randomness or proofs. Most modern VMs already have it, and now Ethereum will too. A niche but handy boon for developer ergonomics, with minimal consensus impact.
Also of note is EIP-7951, the long-awaited precompile for secp256r1 — a type of cryptographic curve used in digital signatures. Its inclusion will unlock native support for keys commonly used in mobile and enterprise platforms — including WebAuthn-based authentication — thus bringing Ethereum one step closer to seamless and secure off-chain integration.
The refined Fusaka scope has drawn pushback from some high-profile stakeholders, notably Paradigm Chief Technology Officer Georgios Konstantopoulos, who resurfaced long-standing frustrations around the “stack too deep” error and the 24 KB bytecode size limit — two of the most cited pain points in Solidity.
The thread sparked a mild rebuttal from client developers, with Prysm developer Potuz noting that EOF had, in fact, aimed to resolve these issues. They had been prioritized until recently, driven in part by Paradigm’s Reth team changing their minds on a prior endorsement.
While Fusaka may lack a headline feature, it targets what many say Ethereum needs most in 2025: better performance without undue risk. It’s shaping up to be a quiet flex by Ethereum’s core devs.
Get the news in your inbox. Explore Blockworks newsletters:
