-
Cryptocurrencies
-
Exchanges
-
Media
Cryptocurrencies: 24492
Exchanges: 115
Market Cap: $$2.14T
24h Vol: $51.75B
Dominance: BTC: 58.9% ETH: 9.9%
ETH Gas: 29 Gwei
All languages
Share
The next big shift in Ethereum: from re-executing every transaction to verifying ZK proofs
金色财经_MonoCoin148 day ago
Whether you are a scaling advocate, an independent staker or home validator, or a proponent of personal self-verification ("Don't trust, verify!" on consumer hardware), this is relevant to you. Let me try to explain what's going on, why it matters, and where the development is as of today.
ParadigmShift: from re-execution to ZK proof verification
Today, every Ethereum node that wants to confirm whether a block is valid must re-execute every transaction in it. Each node does the same job independently. It has been so since the creation of the world. This works, but at a cost that grows linearly with the amount of activity on the chain: the more gas used per block, the more work each node has to do, the more state it needs to hold, and the more bandwidth it consumes. Each time you increase the Gas limit, it becomes more difficult to run the node.
But you can also do something fundamentally different: instead of repeating the calculation, verify a cryptographically proof that someone else has done the calculation correctly. A proof. compact. Constant verification time, no matter what happens inside the block. This is what zkEVM proofs enable - a path to significantly scaling L1 execution in the long term.
This idea is not new. But what is new is that it is now being designed into the core protocol of Ethereum - not as a rollup function, but as an optional path in the proof workflow at the consensus layer.
Current work content
The Ethereum Foundation's zkEVM team recently released a specific L1-zkEVM roadmap for 2026.
Thepipelinebeing built looks roughly like this:
An Execution Layer (EL) client generates an ExecutionWitness - essentially a self-contained package that contains all the data needed to validate a block without holding the full state. A standardized guestprogram consumes the witness and verifies the statustransition. A zkVM executes the program, and a certifier generates correct execution proofs. The consensus layer (CL) client then verifies the proof rather than calling the EL client to re-execute it.
The channel
for delivering proofs to the certificatorThe keywords here are optional. The original design—tracked under EIP-8025 (Optional Proof of Execution)—didn’t force anyone to switch. The proposal does not require a protocol upgrade or fork. Nodes can still be re-executed as they are today. But provers who want to verify blocks through attestation verification can do so. These are called zk attesters: CL clients that verify zkEVM attestations rather than running full EL clients.
On the implementation side, EIP-8025 specifies a CL mechanism that makes this possible:
Proofs from different EL client implementations are distributed via dedicated gossip topics on the p2p network. Modify the block handling process so that certificators can verify these proofs instead of calling the EL client. The current working assumption is a threshold of 3/5, which means that a prover once verifies 3 out of 5 independent proofs , the execution of a block will be accepted as valid. This is a preliminary number and may evolve as the design matures. Importantly, it preserves client diversity at the protocol level, which is a meaningful design choice.
Why this is important
zk Certificate Applicants do not need to hold EL status. It does not require synchronization of the complete chain of execution layers. Synchronization is simplified to downloading the proof of the most recent block since the last finalized checkpoint.
This has a direct impact on the cost of running a node. Today, operating a validator means running both the CL client and the EL client, the latter being a particularly resource-intensive part. State storage, block processing time, bandwidth: all of these grow as the gas limit increases. If you can replace re-execution with proof verification, then you will significantly reduce the hardware requirements for participating in consensus.
But the impact goes far beyond the prover . Since zkEVM Proof is essentially stateless, and ProofProper execution and efficient state transitions without requiring validators to hold any state, so it becomes easier to run a node locally again and validate the chain on your own hardware - this is a fundamental promise of a decentralized protocol.
There is one more dependency worth mentioning: ePBS (embeddedproposed builder-builder separation), which targets the upcoming Glamsterdam hard fork. Without ePBS, the proof window is approximately 1-2 seconds, thus too short for real-time proof . Since ePBS provides a form of block pipeline, it is extended to 6-9 seconds so that the certificator is in a slot Intrinsically generated Proof becomes more realistic.
Who is involved
Independent Stakers and family validators may benefit the most. As zk certificators they no longer need to run the full EL and can sync in minutes. Proof Verification replaces re-execution, and hardware requirements are reduced accordingly.
The EL client team gained a new avenue for its implementation. Each client becomes a potential attestation target, and the multi-attestation subnet design means that client diversity is not only preserved, but becomes a structural feature of the protocol.
On the certificate side, the situation is more complicated. Proof bears an activity assumption of 1/N: an honest certificator can keep the chain running. The simplest model is that block builders are certifiers. But this would likely centralize the proofand the fallback question (what happens when the complex builder disappears?) would not be solved. Hardware requirements for distributed proof, attestor networks, garagescale - these are all under active discussion. What is clear is the design goal: Proof should remain viable outside of data center infrastructure.
ZkVM Vendors like ZisK, openVM, RISC Zero, etc. are committed to making Ethereum the largest ZK application in the world. Several of them have already started certifying Ethereum blocks. Standardization efforts provide them with a clear interface to build on.
L2 and rollup teams benefit from the convergence of infrastructure. Once all validators have verified the execution of the Proof, the same Proof can also be EXECUTE PRECOMPILER for Nativerollup. L1 Proof Infrastructure becomes shared infrastructure.
Ultimately, every user will benefit. More validators who can cheaply validate the chain means a more decentralized, censorship-resistant network with higher gas limits.
Current situation
EIP-8025 has entered the consensus-specs feature branch and will eventually be proposed for inclusion. The L1-zkEVM roadmap for 2026 has been announced. This work is divided into six subtopics: Execution witness and Guest Program standardization, zkVM- Guest API standardization, CL Integrate, Proofor infrastructure, benchmarks and metrics, and security with formal verification.
The first L1-zkEVM breakout session is scheduled for February 11, 2026 at 15:00 UTC.
The agenda covers the full scope of the six sub-topics.
This is just the beginning. If you care about Ethereum's ability to scale without sacrificing decentralization, this is a workflow worth paying attention to. Follow the L1-zkEVM team.
