Ethereum's founding bargain is that nobody has to trust anybody: every rule can be checked. Zero-knowledge proofs extend that bargain to computation itself: one machine does the expensive work, everyone verifies it cheaply. But the bargain has developed an asymmetry. Verification is staying cheap, universal and trustless. Production is becoming expensive, specialized and concentrated. Ethereum removed trust from checking the work, and is quietly re-importing it into doing the work.
Yet proof generation is becoming an industrial business. Modern proving relies on powerful hardware, highly specialised software and deep cryptographic expertise. With demand on the rise, production is concentrating among a small group of operators able to fund and optimise those systems.
The verification process still rejects invalid state transitions. The problem is dependence, where a rollup can end up relying on a prover few outsiders can inspect, reproduce or replace quickly, leaving a trustless protocol exposed to a critical chokepoint in proof production.
A trustless system can still acquire chokepoints
L2BEAT recognised this issue in 2026 when it changed its Stage 1 requirements to require publication of prover source code. Its rationale centred on user sovereignty, where participants need a viable route to produce state transitions if the regular prover fails. Prover availability therefore belongs inside any serious account of decentralisation.
Recent failures show why. Scroll suffered a proving failure in August 2025 after a bug in its EuclidV2 prover guest program. Finality slowed and withdrawals were delayed until an emergency upgrade restored normal operation. In January 2026, inconsistent handling between Starknet’s sequencer and prover contributed to roughly four hours of downtime and an 18-minute reorganisation. Note the shape of both incidents. No invalid state was accepted; safety held. Users simply could not finalize or exit until a single implementation was patched — liveness failed. And both were single-implementation bugs: exactly the failure class that diversity, not verification, exists to absorb.
Want to accept crypto payments on your website?
This concentration emerged for understandable reasons. High-performance proving is brutally difficult engineering. Teams need cryptographers, systems engineers and hardware specialists, alongside the capital required to run expensive machines at high utilisation.
Rollup teams therefore turned to specialist providers. Economically, the model makes sense. Specialists spread hardware and engineering costs across many customers while individual rollups avoid rebuilding the same capability from scratch.
Permissionless prover markets offer part of the answer. Succinct operates a distributed prover network, Brevis has launched an on-chain proving marketplace, and RISC Zero replaced Bonsai with the permissionless Boundless protocol. These systems widen access to proof production and reduce reliance on a single hosted provider. Yet market access and implementation access remain separate issues. Many operators can compete for jobs while the fastest proving methods remain concentrated inside a few engineering teams.
FPGA changes the economics
Specialised hardware changes this calculus because it opens another route to competitive proving.
On June 26, Cysic released Venus, which we describe as the first complete open-source FPGA acceleration backend for a full zkVM. Built on the open-source ZisK system, Venus exposes the main proving components through an FPGA backend and carries Apache 2.0 and MIT licences. Researchers, rollup teams and hardware engineers can inspect the code, modify it and port it to other devices.
FPGAs occupy the useful middle of ZK hardware: more specialized than a GPU, more revisable than an ASIC. That matters because proving is still a moving target — proof systems, field choices and hash functions keep changing. An ASIC freezes today's assumptions into silicon; an FPGA lets the hardware evolve with the cryptography. In a young field, programmable specialization is the only specialization that survives contact with the roadmap. They offer far more specialisation than general-purpose GPUs while retaining programmability as proving systems evolve. During an early market, adaptability carries enormous value because cryptographic systems and implementation techniques continue to change.
Open acceleration widens the pool of people able to improve the machinery. A university team can study the same implementation as a commercial prover. A rollup can assess whether to operate part of its own proving capacity. Another hardware company can adapt the design to different devices. Improvements can accumulate across organisations instead of remaining inside one company.
Performance still decides whether any implementation earns production use. Open source makes performance claims easier to inspect and challenge. Our earlier analysis treated FPGA acceleration as an architectural validation rather than a universal victory over modern GPUs. Public code gives researchers the ability to reproduce results, identify weak points and improve them.
Entrenchment arrives early
The next few years will decide how open proving remains.
Prover economics reward early leaders. Large operators gain production data, tune kernels against real workloads, improve scheduling and spread fixed costs across more proofs. Each advantage can lower marginal costs and help win more business.
Customer dependence compounds the effect. A rollup adapts to a provider’s interfaces, latency profile and proving architecture. Over time, switching becomes expensive engineering work. Incumbency then gains protection from integration costs as well as raw performance.
ZK remains young enough for the ecosystem to set a different norm. Open provers, reproducible pipelines, multiple hardware backends and strong documentation can make provider portability an expectation from the start.
Public protocols such as TCP/IP and HTTP allowed companies, universities and networks to build independently while remaining interoperable. The Internet Society describes open standards as a foundation for competition and innovation across independently operated networks.
ZK proving now faces a similar fork. Proprietary acceleration can produce exceptional products and strong businesses. Trouble begins once one implementation becomes deeply entrenched. Users may retain proof verification while competitive proof production concentrates among a small group.
Open source has to become operational
Publishing code starts the work, but real resilience requires maintained implementations, active contributors and operators willing to run them.
Researchers need end-to-end visibility across execution, proof generation and verification, hardware companies need reasons to support alternative implementations, and rollup teams need tested recovery routes and enough internal knowledge to change providers when required.
Ethereum has already run this experiment on itself. The ecosystem spent years pushing validators off a supermajority client, because one implementation with one bug is a systemic failure point no matter how well-engineered it is. Proving today looks like the client ecosystem before that push: excellent engineering, dangerously few implementations. Prover diversity is client diversity's unfinished half.
A resilient proving market needs more than one viable way to do the work. Rollups should be able to change providers without rebuilding large parts of their systems, researchers should be able to inspect code securing billions of dollars, and hardware advances should travel beyond the teams that developed them.
The future depends on whether rollups, researchers, hardware makers and prover networks treat openness as a requirement when they choose, build and govern these systems.
Early standards have a habit of sticking. Once proprietary providers become deeply embedded, replacing them becomes far more costly.
