Ethereum Targets Zero-Knowledge Based Block Verification in 2026

Proof-based block verification could lower validator costs and make solo staking easier without replacing current validation methods.

Block validation on Ethereum is heading toward a major redesign. Current research focuses on verifying blocks at the protocol level and not on adding new user features. The goal is to lower hardware requirements for validators while maintaining security. If successful, the approach could support higher network activity while keeping participation open to smaller operators.

Ethereum Tests Proof-Based Block Validation to Ease Node Requirements

Ethereum currently validates blocks by making every node re-run every transaction in them. All nodes perform the same work to independently verify results. More computing power, storage, and internet bandwidth are required as transaction volume increases. Running a full node becomes harder as usage grows.

https://t.co/TwylcccdzB

— ladislaus.eth (@ladislaus0x) February 9, 2026

With zero-knowledge EVM proofs, nodes would not redo the work. They would verify a single cryptographic proof that the block was processed correctly. Verifying a proof is quick and takes the same time regardless of how many transactions are in the block, making scaling much easier.

Furthermore, zero-knowledge execution proofs have existed for some time, but Ethereum is now working to use them directly inside its core system. The protocol plans to allow some validators to verify cryptographic proofs confirming the work was done correctly. Validation through proofs would sit alongside current methods and not replace them outright.

New Roadmap Targets Proof Verification to Lower Validator Costs

To support this, the Ethereum Foundation’s zkEVM team has outlined a roadmap aiming for 2026. Under the plan, execution clients would package all the data needed to verify a block into a single bundle called an execution witness.

_Image Source: X/_ladislaus.eth

Think of it as a compact bundle that contains everything needed to check a block, without storing Ethereum’s full state. A special program verifies the data, and a zero-knowledge virtual machine generates a proof that the block was processed correctly. Instead of re-running transactions, a consensus layer (CL) client can verify the proof to confirm the block.

Under EIP-8025, nodes are not required to change their operation. Re-execution remains available, and no hard fork is needed. Validators who choose proof-based checking are called zkAttesters. These CL clients verify zkEVM proofs rather than running a full EL client.

Validators that rely on proofs would no longer need to store Ethereum’s execution data or sync the full chain. Instead, syncing could mean downloading recent proofs after each final checkpoint. That change significantly reduces hardware requirements, making validation easier for solo stakers and home operators.

Moreover, stateless proofs allow individuals to verify Ethereum history locally without large storage requirements. Self-verification on consumer hardware becomes more realistic again.

Proof generation speed depends on another upgrade called enshrined proposer-builder separation (ePBS). Without it, there is not enough time to create proofs inside a block slot. ePBS adds block pipelining, giving provers several seconds per slot, which makes live proof generation realistic.

Distributed Proving Emerges as Key Focus in Protocol Research

Execution client teams gain new relevance, as each client becomes a proving source. zkVM providers also benefit from a shared interface. zkVM projects such as ZisK, OpenVM, and RISC Zero also produce Ethereum proofs, giving them a clear target.

Open questions remain around who produces proofs. One honest prover is enough to keep the chain running, but relying on large builders could concentrate power. Work continues on distributed proving and setups that run on smaller hardware.

Meanwhile, EIP-8025 is now part of the protocol’s consensus specifications work. Research covers witness design, zkVM standards, consensus changes, security checks, and performance testing. A first public working call is set for February 11, 2026, marking an early step in this long-term effort.