Ethereum’s L1 zkEVM is moving from roadmap to reality

The week the roadmap got real

Two timelines converged this month. In July, the Ethereum Foundation published a plan to ship a Layer 1 zero-knowledge Ethereum Virtual Machine, or zkEVM, starting as an optional verification path for validators and growing into the default once it proves itself in the wild. That proposal defined what real time actually means for proofs and laid out a path that does not require risky big-bang changes on day one. You can read the research post that kicked this off as a plan to ship an L1 zkEVM. In October, several independent proving teams reported live performance that hits or nears those targets on current mainnet blocks. Suddenly, an idea that sat on slides for years feels like operational engineering.

If the plan holds, the next year on Ethereum will look different. Validators will get the option to verify a small set of succinct proofs rather than re-executing every transaction in every block. As confidence grows, the network can raise gas limits, harden censorship resistance with more participants proving from home, and give rollups a cheaper and safer base to build on. The implications travel all the way up the stack, from how Layer 2s do sequencing to what wallets feel like in 2026.

This piece breaks down how the rollout could happen, why home proving is not a side quest, and what to build before Devconnect Argentina in November 2025.

What optional L1 verification actually looks like

Today an Ethereum node receives a block, checks signatures, and fully replays every transaction to verify the result. That is secure but expensive. The zkEVM path introduces a second option. A validator can choose a zk client that verifies multiple independent proofs of the block’s execution instead of replaying it. Think of it like checking three receipts from different calculators rather than doing the long division by hand. The defense in depth comes from diversity: different zk virtual machines implement the same Ethereum rules in different codebases.

There is no forced switch on day one. The Foundation’s current plan starts as an opt in for a small subset of validators. The first hard fork that matters here, nicknamed Glamsterdam in working notes, introduces pipelining at the protocol level to give provers a few more seconds without touching consensus rules. An EF engineer is also building a prototype attester client that assumes real-time proofs exist and uses them to perform validator duties. The EF summarized that path in August as a zkEVM attester client, with the goal of rolling out optional verification to a small group over the next year while audits, bounties, and formal specs mature.

Three other design pillars matter:

A standard for real-time proving. With a 12 second slot and roughly 1.5 seconds of network propagation, proofs should land in under 10 seconds for at least 99 percent of blocks. Proofs should be small, under a few hundred kilobytes, and meet strong cryptographic security targets.
Client diversity at the proof layer. Validators verify multiple proofs from different zk virtual machines. That mirrors the current diversity of execution clients like Geth, Nethermind, and Erigon.
A graceful migration lever. As more stake runs zk clients and confidence climbs, the gas limit can increase to a level where proof verification is the practical path for standard hardware, while re-execution remains a fallback.

Put differently: Ethereum keeps its safety net while adding a jet engine.

Why home proving matters more than it sounds

The July plan does not only optimize for cloud clusters. It calls out home proving with real constraints: under about 10 kilowatts of power and a capital budget on the order of a well equipped gaming rig farm rather than a data center. That is a big design choice, not a marketing phrase.

Here is why it matters:

Censorship resistance needs many independent hands on the wheel. If only a handful of cloud providers can produce proofs, the system narrows. If thousands of solo stakers can run provers in living rooms and garages, the network gains a last line of defense. Even if inclusion lists land before proofs become mandatory, home provers make censorship harder to sustain.
Decentralized liveness. Real-time proving is a race against the clock. The more distributed the proving set is, the harder it is for an attacker to stall the system.
Market pressure on costs. When proofs can be produced at home on commodity gear, vendors compete on efficiency and ergonomics, not just on exclusive access to rare accelerators.

The punchline is simple: home proving is not just a feel good goal. It is a concrete constraint that pushes the ecosystem to ship provers that run in the same homes that already host solo validators.

Faster proofs, higher gas limits, cheaper rollups

What actually changes when proofs arrive on time? Three levers move in tandem.

Gas limit headroom. Verifying a succinct proof is far cheaper than replaying an entire block. Once zk verification is the default for most validators, the network can lift gas limits more safely. More gas per block means more transactions per second and more room for applications that do not compress well into Layer 2s. It also buys space for precompiles and future cryptography without choking the network. This could also support institutions experimenting with treasuries on chain, as seen in UK tokenised funds momentum.
Censorship resistance hardening. A larger validating set that includes home provers improves participation. A prover that is not beholden to a builder or to a centralized cloud can help keep the block race honest.
Layer 2 cost compression. Today rollups inherit security from Ethereum but still pay heavy data costs and sometimes rely on governance-controlled bridges. With an L1 zkEVM, the same proofs that validators already check can be exposed through a standard precompile so that rollups can become more native. If the base layer is already verifying Ethereum semantics with strong proofs, rollups can reuse those semantics and proofs rather than reinventing them. That lowers verification costs and attack surface.

Consider a concrete example. A rollup running a popular game posts blobs with 1 million small state updates every hour. With cheap verification on L1, that rollup can batch more updates per blob without bloating validator work, because validators will not replay them. On the same hardware, verification cost barely moves while application throughput climbs.

The proving race in October, in plain English

In May, Succinct introduced a new version of its zero-knowledge virtual machine called SP1 Hypercube and reported that it could prove most Ethereum blocks within the slot time on a large cluster of graphics cards. In October, Brevis unveiled its Pico Prism architecture and reported that it can prove nearly all current mainnet blocks within 12 seconds and the vast majority within 10 seconds on a significantly smaller cluster of newer cards. The details vary across teams, but the directional story is the same: proofs are getting not only faster but more power efficient and cheaper.

If you are not deep in the weeds, think of block proving like baking bread. The recipe is fixed by protocol rules. The challenge is kneading and baking fast enough to ship a loaf before the delivery truck leaves every 12 seconds. This month’s results say that modern ovens and better dough handling are starting to hit that schedule most of the time, and at a cost that no longer requires a bakery the size of an airplane hangar.

What this means for rollup design

Native rollups become practical. When the base layer exposes a standard way to verify Ethereum-style proofs, rollups can implement less custom logic and rely more directly on Layer 1 for finality. That improves bridge safety by reducing governance or multisignature dependencies.
Shared sequencing gets easier to coordinate. If proofs arrive fast and deterministically, it is simpler for multiple rollups to agree on a shared ordering of transactions without long waiting windows. That opens the door to better cross rollup atomicity.
EVM equivalence becomes less of a tax. A rollup that is already close to Ethereum semantics can lean on the same proof gadgets the base layer uses. That reduces the burden of maintaining bespoke opcodes or translators.
Data availability strategies can specialize. With more headroom at Layer 1, some rollups will push more data on chain to reduce reliance on off chain data availability committees. Others will stay data light but take advantage of cheaper proof verification for more frequent settlement.

What this means for MEV and inclusion

Maximal extractable value is a coordination game among proposers, builders, and searchers. Proofs do not make MEV disappear. They change the timing, the participants, and the margins.

Faster settlement narrows some cross domain arbitrage windows. If rollups can finalize more frequently and with stronger guarantees, the profit from latency games may shrink. That can redirect effort toward building better routing and shared sequencing rather than sniping. For a related view on market structure, see onshore prediction markets deals.
Inclusion lists and censorship resistance gain a backstop. The Foundation’s plan assumes stronger inclusion mechanics land before proof verification becomes mandatory. Add home proving to that, and the cost of sustained censorship rises again.
Builder markets adapt. If verifying a proof is cheap, validators can accept larger blocks with more bundled intent flows without raising re-execution costs. That rewards builders who can pack more useful transactions per slot rather than just spending on brute force search.

For teams building order flow tools, the next year is a chance to prototype designs that assume proofs land in about 10 seconds and that inclusion lists are enforced. That combination changes both strategy and safety assumptions.

Privacy defaults that feel normal

A zkEVM at Layer 1 does not add anonymity by itself. It changes what is practical. Client side proving and standard proof verification primitives lower the cost of privacy features that feel normal to mainstream users. As consumer wallets advance, including moves like Galaxy Wallet goes crypto-native, flows that feel normal will matter.

Receipts over replays. If wallets can submit transactions with proofs that certain statements are true without exposing raw inputs, common actions like tipping, small donations, or private voting can feel like normal transactions with a privacy toggle.
Selective disclosure by design. Builders can offer auditing keys and proofs of compliance without turning their applications into gated gardens. The proof is the interface.
Less bespoke cryptography per app. If the base layer carries the heavy lifting, application developers can reuse proven circuits, audited libraries, and documented verification paths rather than rolling custom primitives.

A practical checklist for builders before Devconnect Argentina

Devconnect 2025 starts in November. If you want to ship into this moment, here is a concrete list that maps to the plan above.

Choose a proving backend and instrument it. Pick at least two zk virtual machines that can produce proofs for Ethereum semantics. Automate latency and power measurements on real mainnet blocks. Track P95 and P99 latency, proof size, and energy use.
Make your nodes proof aware. Add support for consuming multiple proofs per block in your execution client integration or middleware. Start with a shadow mode that verifies proofs while still re-executing.
Budget for home proving. Design a reference setup that fits under roughly 10 kilowatts and a realistic capital budget. Document the bill of materials and noise mitigation so real users can replicate it.
Plan for inclusion lists. If you run a rollup or a builder, design how you will respect inclusion constraints and expose them to users. Test how this interacts with your sequencing and commitment scheme.
Treat formal verification as a deliverable. If you are building circuits, allocate time and budget for formal specs and third party audits. The EF has been explicit that rigorous review precedes default status.
Prepare for bigger blocks. Profile how your node handles 100 to 150 million gas blocks in dev environments. Fix bottlenecks in state access, disk I/O, and RPC throughput.
Wire up a proof first mode for your rollup. Assume the base layer exposes a standard precompile for proof verification. Prototype your bridge and settlement logic around that model.
Write user facing copy. Wallets and dapps will need to explain what a proof does in plain English. Draft that copy now and test it with non experts.

Ship a thin slice by Devconnect. You do not need to prove every block. A dashboard that tracks real block proving with latency and energy charts on a home rig is already valuable and honest.

Three user experience scenarios for 2026

The instant sync phone. A wallet on a new phone becomes a verifying light client in minutes by downloading headers and a handful of proofs instead of replaying history. The user sends a payment while the device is still syncing, with confidence that the phone is not trusting a random server.
The rollup hop that feels like one chain. A game on one rollup calls a marketplace on another, and the transaction settles in a single Ethereum slot with a shared proof. The user never sees a bridge warning or a timer. Funds just move.
The local privacy switch. A wallet offers a prove, do not reveal option for small payments. The user flips the switch, pays a friend, and sees a normal transaction in the history. The app can later generate a disclosure receipt for taxes without exposing the underlying data on chain.

What to watch next

Proof coverage and tails. The median is not enough. Keep an eye on the slowest 1 percent of blocks and on synthetic denial of service tests. The definition of real time depends on those tails.
Power budgets for home rigs. Performance that requires a noisy space heater farm is not good enough. The best demos over the next months will publish power draw curves and thermal notes.
Client implementations. Optional verification only works if multiple zk clients exist and are easy to run. Look for releases that make proof verification a flag you can turn on and off.
Gas limit experiments. On testnets, measure how state access and disk I/O respond to 100 to 150 million gas targets. If those numbers hold, mainnet can move with confidence when the zk path is ready.
Precompile and standards work. Watch for proposals that expose a clean, audited interface for native rollups to consume the same proofs validators verify.

The bottom line

Ethereum’s move to an optional zkEVM at Layer 1 is not a moonshot that requires a leap of faith. It is a staged migration that piggybacks on two realities that are now measurable. First, proofs for real mainnet blocks are landing within slot times with hardware that looks a lot like the gear in a serious home lab. Second, the protocol path emphasizes optionality and diversity so that risk is absorbed in layers, not in a single cutover.

If you are a builder, the call to action is clear. Instrument your proving stack. Make your nodes proof aware. Design for home rigs. Plan for inclusion lists. By the time Devconnect opens in Buenos Aires, you should be demoing something that proves a block and explains it to a user. The next year will decide who is ready when optional stops being optional.