Chainfeeds Summary:
Without real-time ZK, it's difficult to have a truly usable Interop UX.
Article source:
https://www.techflowpost.com/article/detail_29532.html
Article Author:
imToken Labs
Opinion:
imToken Labs: On December 4th, the Ethereum Fusaka upgrade was officially activated on the mainnet. However, unlike the Dencun upgrade, it wasn't a major event, and the market spotlight was mostly focused on Blob scaling and PeerDAS, with much discussion about the further reduction in L2 data costs. But beyond this noise, there was actually a seemingly insignificant proposal, EIP-7825, that cleared the biggest obstacle for Ethereum to achieve L1 zkEVM and real-time proofs, and could even be said to be quietly paving the way for the endgame of Interop. In this Fusaka upgrade, the focus was almost entirely on scaling: Blob capacity increased by 8 times, coupled with PeerDAS random sampling verification, making the cost narrative of the DA (Data Availability) track completely history. Indeed, cheaper L2 is a good thing, but for Ethereum's long-term ZK roadmap, EIP-7825 is the real game-changer because it sets a gas cap (approximately 16.78 million gas) for a single Ethereum transaction. As we all know, the Ethereum block gas limit has been increased to 60 million this year. However, even with the continuous increase in the limit, theoretically, if someone is willing to pay an extremely high gas price, they can still send a super complex "mega-transaction" that directly fills the entire block's 60 million gas capacity, thus clogging the entire block. So why limit the size of a single transaction? In fact, this change has no impact on ordinary user transfers, but for ZK Prover (proof generator), it is a matter of life and death, which is also closely related to the way the ZK system generates proofs. To give a simple example, before EIP-7825, if a block contains a "mega-transaction" that consumes 60 million gas, the ZK Prover must run this extremely complex transaction sequentially. It cannot be split or parallelized. This is like a single-lane highway with a giant truck driving very slowly in front, and all the smaller cars (other transactions) behind have to wait for it to pass. This would undoubtedly be a death sentence for "real-time proofs"—because the time to generate a proof is completely unpredictable and could take tens of minutes or even longer. After EIP-7825, even if the block size expands to 100 million Gas in the future, because each transaction is forcibly limited to 16.78 million Gas, each block is broken down into predictable, bounded, and parallelizable "small task units." This means that Ethereum's proof generation has transformed from a tricky "logic puzzle" into a pure "money problem": as long as enough parallel computing power is invested, we can process these broken-down small tasks simultaneously in a very short time, thereby generating ZK proofs for huge blocks. However, while EIP-7825 paved the physical path (parallelization) for real-time proofs by limiting the size of a single transaction, this is only one side of the coin. The other side is how the Ethereum mainnet itself utilizes this capability. This involves the most hardcore narrative in the Ethereum roadmap—L1 zkEVM. For a long time, zkEVM has been regarded as the "holy grail" for scaling Ethereum, not only because it can solve performance bottlenecks, but also because it redefines the trust mechanism of blockchain. Its core idea is to enable the Ethereum mainnet to generate and verify ZK proofs. In other words, after each block is executed in the future, it can output a verifiable mathematical proof, so that other nodes (especially light nodes and L2) can confirm the correctness of the result without repeating the calculation. If the ability to generate ZK proofs is directly written into the Ethereum protocol layer (L1), the proposer will package a block and generate a ZK proof each time, and the verifying nodes will no longer need to rerun the transactions, but only need to verify this tiny mathematical proof.
Content source 
