In earlier articles in this Interop series, we covered OIF (the intent framework) and EIL (the interoperability layer). OIF standardizes cross-chain intents (so the network can understand what you want to do), while EIL provides execution rails (so funds can move in a standardized way).
But to deliver a truly seamless “single-chain” experience, you still have to balance speed and trust. Today, interoperability often means choosing between slow finality (for example, Optimistic Rollups may require a 7-day challenge period) or weaker decentralization (by relying on the trust assumptions of multisig bridges).
To break this trilemma. Ethereum needs a core capability that links the Interop roadmap’s Acceleration track with finality: real-time proofs powered by ZK technology. (Further reading: Ethereum Interop Roadmap: Solving the Last Mile to Mass Adoption)
And in the Fusaka upgrade that just went live, an unassuming proposal—EIP-7825—clears the biggest engineering obstacle on the road to that endgame.
1. The underrated EIP-7825 in the Fusaka upgrade
On December 4, Ethereum’s Fusaka upgrade went live on mainnet. Unlike the Dencun upgrade, it drew less fanfare, and most attention stayed on Blob scaling and PeerDAS, especially the prospect of even lower L2 data costs.
But beyond the spotlight, EIP-7825 removes the biggest obstacle to bringing L1 zkEVM and real-time proofs to Ethereum—quietly paving the way for Interop’s endgame.
In Fusaka, most attention has been on scaling: Blob capacity increases 8×, and with PeerDAS sampling-based verification, the cost of the DA (data availability) layer becomes far less of a bottleneck.
Lower L2 costs are important, but for Ethereum’s long-term ZK roadmap, EIP-7825 is more consequential: it sets a per-transaction gas cap of about 16.78 million gas.
This year, Ethereum’s block gas limit has risen to 60 million. Even so, in theory, someone willing to pay a very high gas price could submit a highly complex mega-transaction that fills the entire block—effectively clogging it.
This was previously allowed, but EIP-7825 adds a new rule:
- no matter how large a block is, a single transaction cannot exceed ~16.78 million gas.
Why the per-transaction cap matters
For most users, this change has no impact on simple transfers. But for ZK provers (proof generators), it’s a make-or-break constraint—because of how ZK proofs are produced.
For example, before EIP-7825, if a block included a 60-million-gas mega-transaction, a ZK prover had to run that transaction end-to-end in sequence—no splitting and no parallelism. It’s like a single-lane highway with a slow, oversized truck up front: every other car (the remaining transactions) gets stuck behind it.
That makes real-time proving effectively impossible, because proving time becomes unpredictable—potentially tens of minutes, or longer.
After EIP-7825, even if blocks expand to 100 million gas, each transaction is capped at ~16.78 million gas. Blocks become predictable, bounded units that can be processed in parallel. In effect, proving shifts from a hard systems constraint to a pure money problem:
With enough parallel compute, we can process these smaller units quickly and generate ZK proofs for large blocks in a short time.
As Brevis co-founder and CEO Michael has noted, EIP-7825 is an underrated upgrade for Ethereum’s ZK path and “100×” scaling. It turns real-time proving from “theoretically impossible” into “engineering-schedulable.” With sufficient parallel compute, even 200 million gas blocks could be proven in seconds—providing the foundation for EIL to achieve second-level cross-chain settlement.
This upgrade may not look like the main event, but it’s a major step forward for Ethereum’s ZK roadmap—and for scaling ahead of 2026.
2. L1 zkEVM: The “trust anchor” for Ethereum interoperability
EIP-7825 makes real-time proving physically feasible by enabling parallelism. But the bigger question is: how will Ethereum mainnet use that capability?
That brings us to one of the most technically ambitious parts of Ethereum’s roadmap: L1 zkEVM.
zkEVM has long been seen as a “holy grail” for scaling—not just because it improves performance, but because it reshapes the trust model by giving Ethereum mainnet the ability to generate and verify ZK proofs.
Put differently, after each block executes, Ethereum could produce a verifiable proof so other nodes—especially light clients and L2s—can confirm correctness without re-executing everything. If this capability is built into L1, proposers can publish blocks with proofs, and validators can verify the small proof instead of replaying all transactions.
What L1 zkEVM unlocks for Interop
In an Interop context, L1 zkEVM matters far beyond scaling. It can serve as a trust anchor for every L2—unlocking two major changes:
- Eliminate challenge periods: confirmations can shrink from “7 days (optimistic)” to “seconds (ZK).”
- Decentralize connectivity: cross-chain no longer relies on third-party multisig bridges, but on Ethereum mainnet’s verifiable proofs.
This is also the foundational prerequisite for EIL (the interoperability layer) to work as intended: without real-time finality on L1, L2-to-L2 interoperability can’t fully escape latency.
The goal is clear (L1 zkEVM), and the key constraint has been addressed (EIP-7825). The next question is: what’s the practical implementation path?
This leads to a subtle shift in the ZK stack: moving from zkEVM toward zkVM.
3. Fusaka & EIP-7825: The Interop roadmap breaks free
If EIP-7825 creates parallel-friendly conditions for ZK by capping transaction size, then the ZK stack’s evolution is about finding a more efficient software architecture. The distinction matters—and it maps to two stages of ZK development. (Further reading: ZK Dawn: Is Ethereum’s Endgame Accelerating?)
The first stage is zkEVM, which focuses on compatibility.
The goal is to mirror EVM behavior so developers can deploy Solidity with minimal changes—lowering migration cost and friction.
In short, zkEVM’s biggest advantage is compatibility with existing Ethereum apps, allowing teams to reuse much of today’s tooling—clients, explorers, debuggers, and more.
The downside is that the EVM wasn’t designed to be ZK-friendly. To stay compatible, zkEVM proving efficiency often hits a ceiling—proofs are slower, and the design constraints add overhead.
By contrast, zkVM takes a more radical approach: it uses a ZK-friendly VM (for example, RISC-V or WASM) to speed up proving and improve execution performance.
The trade-off is reduced compatibility with some EVM features and less access to certain existing tools (such as low-level debuggers). Even so, a clear trend is emerging:
- more L2s are optimizing proving speed and cost aggressively and exploring zkVM-based designs.
So why is Fusaka a key enabler?
Before EIP-7825, both zkEVM and zkVM could see proving time spike when a block included a mega-transaction—because the work couldn’t be split.
Now, EIP-7825 forces transactions into predictable units and enables parallel processing. That lets efficient architectures like zkVM perform at their best—so even complex blocks, backed by parallel compute, can move toward real-time proving.
What does this mean for interoperability?
As zkVM adoption grows alongside EIP-7825, proof costs can drop sharply. When cross-chain proofs become cheap and fast enough to feel instant, traditional “bridges” may fade into the background—replaced by general-purpose messaging at the protocol layer.
In closing
Interop’s end goal isn’t only moving assets across chains. It goes beyond “asset bridges” to a broader set of system capabilities—covering:
- cross-chain data communication
- cross-chain logic execution
- cross-chain user experience
- cross-chain security and consensus
From this view, Interop is a common language across future Ethereum protocols—about sharing logic, not just transferring value. ZK’s role is to guarantee correct execution and enable real-time state verification, so cross-domain calls are both safe and practical. Without real-time ZK proofs, truly usable Interop UX is hard to achieve.
With EIP-7825 now live in Fusaka—and L1 zkEVM moving closer to reality—we’re approaching that end state: execution, settlement, and proving are fully abstracted in the background, and users barely notice the chain at all.
That’s the Interop end state many of us are working toward.