we see ethereum undergoing a quiet, radical transformation. the interesting part is what a validator might eventually need to do before accepting a block.
for years, checking ethereum’s execution has meant doing the work again. take the transactions, run them against the previous state, and check that the result matches. familiar, reliable, and a lot of repeated computation across the network.
now imagine checking a proof that the work was done correctly instead.
that was the idea behind my original post on ethereum’s L1 zkEVM direction. and it is still the part that gets me interested: making verification lighter without turning it into somebody else’s promise.
but stay with me now. proving a block, proving it quickly, and making ethereum depend on that proof are three different milestones. mixing them together makes the roadmap sound more finished than it is.
what are we actually replacing?
the target is repeated execution verification. a prover runs the relevant computation and produces a cryptographic proof. a verifier checks that proof against the expected program and public inputs.
the work has not disappeared. somebody still executes the block and produces the proof. what changes is how many other participants need to repeat the same expensive process to check the result.
think of the difference between doing a long calculation yourself and checking a certificate tied to that exact calculation. the certificate only helps if it covers the right question. in ethereum’s case, that means the right execution rules, starting state, transactions, and resulting state—not just a proof that some program ran successfully.
the ethereum foundation’s August 2025 update described an attester client that could verify execution proofs instead of re-executing transactions. it proposed an optional rollout first, building confidence before wider adoption. [1]
this is narrower than replacing consensus itself. validators still have consensus duties. a proof of execution correctness does not, on its own, decide which competing block becomes canonical or whether the data needed by the network is available.
so yes, this could change a major part of validation. but calling it a complete replacement for consensus skips the part where all these systems still have to work together.
real time means keeping up with the chain
a proof that arrives eventually can be useful. a base layer moving from slot to slot needs something more demanding.
in July 2025, the foundation set a working target: prove at least 99% of mainnet blocks within ten seconds, against a twelve-second slot budget. it also specified limits for hardware cost, power, and proof size, alongside an open-source requirement and a long-term security target. these were engineering goals, not a statement that every validator already used proofs. [2]
the important word here is “99%.” an impressive result on an easy block does not tell us how a prover behaves when the workload gets awkward. a system serving a live chain has to deal with the distribution, not just the screenshot.
this is why real-time proving is a systems problem as much as a cryptography problem. the proof has to be generated, delivered, and checked in a workflow that keeps moving. shaving time from one stage is useful. leaving a bottleneck in the next stage still leaves a bottleneck.
fast is a milestone. secure is the requirement.
the foundation’s December 2025 follow-up moved the emphasis toward mainnet-grade security. it called for stronger security analysis and clearer accounts of how proof systems and their recursive components fit together. [3]
that is a very different conversation from “we proved this block quickly.” and it should be.
if a verifier accepts a proof, the network needs confidence that the claim behind it is sound. a bug in the execution program, proof system, or integration can affect what the verifier actually guarantees. speed cannot compensate for proving the wrong thing correctly.
this is also why open source matters to me beyond the label. people need to be able to inspect the code, reproduce the result, and challenge the assumptions. a performance chart can show progress. the implementation is where that progress has to survive scrutiny.
multiple proofs, fewer single points of confidence
the original L1 proposal included verifying proofs from different zkVMs, proving different EVM implementations. the aim was to bring a form of client diversity into proof-based verification rather than making one proving stack the only line of defense. [2]
that idea matters because independent implementations can fail in different ways. but independence has to be real. three products sharing the same critical bug would not magically become safe because the number is three.
the useful question is what differs underneath: the execution implementation, the proving machinery, the assumptions, and the parts everybody depends on. diversity is something to examine, not just count.
and when the proofs disagree, the system still needs a defined response. that is where protocol design comes in. cryptography gives us powerful tools; it does not remove the need to decide how those tools are used.
where sp1 fits into this
one of the most compelling teams in this story, for me, is succinct.
sp1 is a general-purpose zkVM. succinct’s own repository describes it as proving programs compiled for the RISC-V architecture, with tooling that lets developers write proving programs in Rust. that means the starting point can be familiar software rather than a custom circuit written for every application. [4]
for ethereum execution, the crucial connection is the program running inside the zkVM. sp1 does not become a complete ethereum client just because it can prove computation. the execution logic has to be brought into that environment, and the proof has to be connected to the statement the verifier expects.
this is where practical usability starts to matter. can teams maintain the program as the protocol changes? can they debug failures? can other people reproduce the proving setup? infrastructure has to keep working after the announcement.
the foundation’s second-quarter 2026 allocation update lists support for succinct’s work on on-premise, multi-GPU L1 block proving and operational resilience. [5] that is a concrete sign of work on the problem. it is not the same thing as ethereum choosing one exclusive prover.
my original post called succinct the best zk tech. that is my enthusiasm talking, not a universal benchmark result. the stronger case is the work we can inspect: open code, execution proofs, and the effort to make proving usable outside a controlled demo.
home verification and home proving are different
this distinction is easy to miss. checking a proof and producing it have different resource requirements.
the 2025 proposal’s home-proving target allowed substantial hardware and power budgets: up to $100,000 in equipment and ten kilowatts. [2] so “home proving” should not be read as a promise that any ordinary laptop can prove every ethereum block in real time.
what excites me is the possibility of keeping verification accessible even as the chain does more work. but there is still a decentralization question on the proving side. if producing proofs becomes concentrated, how easily can another operator step in? what happens during an outage? can the network keep progressing?
those are not reasons to dismiss the direction. they are the things that decide whether the direction delivers what we want.
the roadmap is moving. the distinction still matters.
the foundation’s September 2026 priorities describe a progression from execution proofs being available and optional, to expected, and eventually mandatory. the ordering of later milestones was still under review. [6]
so i would not present the original “sooner than expected” line as a delivery date. a proposal can be ambitious without being a completed network-wide migration. a proving breakthrough can be real without answering every deployment question.
what has stayed consistent is the goal: reduce the amount of work required to independently check ethereum while preserving the properties that make checking it worthwhile.
concluding
ethereum’s zk direction makes “don’t trust, verify” more practical if the engineering holds up. the potential is a network that can do more without asking every verifier to repeat everything.
but the standard has to be bigger than speed. prove the right execution. make the proof sound. make it arrive on time. make the system resilient when something goes wrong.
that is why zkVMs like sp1 are interesting to me as infrastructure. the work is moving from an impressive cryptographic idea toward something a live network could depend on.
replace repeated execution with verification.
make proving fast, secure, and accessible.
then prove it, block by block.
still a lot to build. still a direction worth watching. gprove!
sources & editorial notes
expanded from my July 2025 post, with primary-source checks on 21 October 2026. the original point of view remains; roadmap language is dated, and personal enthusiasm is distinguished from technical evidence. this is an explanation of the direction, not a claim that mandatory L1 proof verification has shipped.
- ethereum foundation — protocol update 001: scale L1.
- ethereum foundation — shipping an L1 zkEVM: realtime proving.
- ethereum foundation — the security foundations.
- succinct — SP1 source repository and documentation.
- ethereum foundation — allocation update, Q2 2026.
- ethereum foundation — current and emerging priorities.