Chainfeeds Summary:
The L1-zkEVM roadmap for 2026 has been released. The related work has been broken down into six sub-directions: execution witness and standardization procedures, zkVM and execution procedure API standardization, consensus layer integration, proof infrastructure, performance testing and metrics system, and security and formal verification.
Article source:
https://x.com/ladislaus0x/status/2020874834855514278
Article Author:
ladislaus.eth
Opinion:
ladislaus.eth: The Ethereum Foundation's zkEVM team recently released its 2026 L1-zkEVM roadmap. The process being built is roughly as follows: The execution layer client generates an ExecutionWitness, a self-contained data packet containing all the information needed to validate a block, without holding the full state. A standardized procedure reads this witness and verifies the correctness of the state transition. Subsequently, a zkVM executes this procedure, and a prover generates a proof of execution correctness. Finally, the consensus layer client confirms the block by verifying this proof, instead of calling the execution layer client to re-execute the transaction. The key word here is "optional." The initial design does not force everyone to switch, nor does it require a hard fork upgrade. Nodes can still re-execute transactions as they are now. However, validators who wish to confirm blocks by verifying proofs can choose to do so; these nodes are called zkAttesters: they confirm blocks by verifying zkEVM proofs, instead of running the full execution layer client. zkAttesters do not need to hold the execution layer state or synchronize the full execution layer chain data. The synchronization process can be simplified to downloading the proof of the most recent block. This will directly reduce the cost of running nodes. Currently, running a validator requires running both a consensus layer client and an execution layer client simultaneously, the latter being extremely resource-intensive. State storage, block processing time, and bandwidth requirements all increase with the gas cap. Replacing repetitive execution with proof verification significantly lowers the hardware barrier to participation in consensus. The impact extends beyond validators. Since zkEVM proofs are "stateless," they can prove the correctness of execution and the legitimacy of state transitions without holding the complete state, making it easier for individuals to run nodes on local hardware again and independently verify the entire chain. This is one of the core promises of decentralized protocols. There is also an important dependency here: ePBS (proposer-builder separation within the protocol), which is expected to be introduced in the future Glamsterdam hard fork. Without ePBS, the time window for proof generation is only 1-2 seconds, making real-time proofs almost impossible. With the block pipeline mechanism, this window can be extended to 6-9 seconds, making it more realistic to generate proofs within a single slot. Independent stakers and family validators are likely to be the most direct beneficiaries. As zkAttesters, they no longer need to run a full execution layer client; synchronization can be completed in minutes. Proof verification replaces repetitive execution, significantly reducing hardware requirements. Execution layer client teams also gain new development paths. Each client can become a proof target, and the design of multiple proof subnets ensures that client diversity is not only preserved but also becomes part of the protocol structure. The situation on the proof side is more complex. Proofs rely on a "1-of-N" liveness assumption: as long as there is one honest prover in the world, the chain can continue to operate. The simplest model is to have block builders simultaneously assume the proof role, but this could lead to the centralization of proof capabilities. What if high-end builders withdraw? Issues such as distributed proof networks and home-grade hardware proof capabilities are still under discussion. The clear design goal is that proof capabilities should not only exist in data centers. zkVM vendors (such as ZisK, openVM, RISC Zero, etc.) will also benefit from this, as they are driving Ethereum to become one of the world's largest zero-knowledge application scenarios. In fact, teams are already generating proofs for Ethereum blocks. The advancement of standardized interfaces provides them with clear development goals.
Content source 
