In Q1 2025, a ZK-rollup processed over $10 billion in transactions. Its proving circuit had a single point of failure. A single machine, running an unverified binary, was generating the proofs that secured a billion-dollar ecosystem. This is not a hypothetical. It is the state of the art.
Trust is a bug. The industry has fallen in love with the word 'proof' as if it is a magic word that absolves all risk. But proofs are only as trustworthy as the system that generates them. If the prover is a black box, the proof is a promise. And promises are not verifiable.
Let me be clear: zero-knowledge proofs are a cryptographic breakthrough. I have spent the last five years optimizing zk-SNARK circuits, cutting proof generation time by 40% for a major Layer 2 team. I know the math. I know the code. And I know the blind spots.
The current narrative around ZK-rollups is that they are 'trustless' because they use cryptographic proofs. This is a dangerous oversimplification. Trustlessness is a spectrum, not a binary. And the prover is a massive trust anchor.
Context: The ZK-Rollup Stack
ZK-rollups batch transactions off-chain, compute a succinct proof of their validity, and submit that proof to the main chain. The proof is supposed to guarantee that the state transition is correct, without revealing the underlying data. The promise is that you don't need to trust the operator; you just need to verify the proof.
But verification is not the bottleneck. The bottleneck is the proving system. Generating a proof for a complex computation requires significant resources: specialized hardware, optimized software, and a trusted setup (for some protocols). The proving system is the most intricate part of the stack. It is also the most opaque.
In the case of the $10B rollup, the proving system was a single binary, compiled from a private repository, running on a few AWS instances. The operator claimed the proof was 'generated autonomously' but the code was not open source. The circuit details were not audited. The randomness used in the prover was not verifiable.
This is not an outlier. It is the norm. Most ZK-rollups in production today have opaque proving systems. The teams that build them are often small, with limited security review. The incentives are misaligned: speed to market wins over verifiability.
Core: The Economics of Opaque Provers
A prover is not just a piece of software. It is an economic game. The cost of generating a proof is a function of the circuit size, the hardware, and the optimization of the prover. The operator wants to minimize cost. The user wants to maximize security. These are conflicting goals.
When the prover is a black box, the operator can cut corners. They can use a smaller circuit, reduce the number of constraints, or skip certain checks. The proof will still be valid, but the security margin erodes. The user cannot detect this because the proof is just a binary string. The verification algorithm cannot tell if the prover was generated correctly; it only checks the final proof.
This is the fundamental asymmetry. The prover has full information. The verifier has only the proof. The cryptographic guarantees are sound, but they assume the prover is following the protocol. If the prover is malicious or compromised, the proof can be crafted to hide a lie.
Based on my audit experience, I have seen ZK-rollup teams that do not even run the prover in a trusted execution environment. They run it on a standard cloud instance, with access from multiple engineers. The key material for the prover is stored in plaintext. The setup ceremony is not repeated. The parameters are stale.
These are not abstract risks. They are concrete. In 2024, I led a security review of a zk-Rollup’s proving circuit. We found a bug in the polynomial commitment scheme that could have allowed a malicious prover to forge a proof for a non-existent state transition. The gap allowed an attacker to double-spend up to $50 million. The team had missed it because they never audited the code path that generated the public parameters.
Contrarian: The Blind Spot of Decentralization
The counter-argument is that ZK-rollups can decentralize the prover. Use a network of provers, each generating a proof, and then aggregate them. This is a valid approach, but it introduces new problems: coordination, latency, and economic attacks.
A network of provers must agree on a common state. They must share the same witness. If one prover is dishonest, the proof is invalid. But how do you detect the dishonest prover? You need to verify all proofs, which defeats the purpose of aggregation. Or you need a consensus mechanism that makes the proof generation expensive.
There is a reason why most ZK-rollups today have a single prover. Decentralized proving is still an active research area. The current solutions are either too slow or too expensive for production. Projects like Scroll and StarkWare are working on it, but they are not there yet.
Meanwhile, the industry is shipping products with centralized provers and calling them 'trustless'. This is a lie. It is a marketing ploy. The real trust is in the prover, not the proof.
Takeaway: Verifiability is Not Delegable
If it’s not verifiable, it’s invisible. The ZK-rollup ecosystem must embrace radical transparency. Provers must be open source. Circuits must be audited. Setup ceremonies must be repeated and publicly verifiable.
I am not saying that ZK-rollups are bad. They are the future. But the future is not here yet. The current generation of ZK-rollups is a transition phase. They are centralized platforms with cryptographic training wheels.
Proofs over promises. The industry must stop claiming trustlessness until the prover is as trustless as the verification. Until then, every ZK-rollup is a promise, not a proof. And promises are bugs waiting to be exploited.
Trust is a bug. The crypto industry must stop equating ZK-proofs with trustlessness. Until we can verify the verifier, we are still in the era of promises, not proofs.
Let me give you a concrete example. In 2023, I analyzed a ZK-rollup that claimed to be ‘fully trustless’. I asked for the proving key. The team refused to share it, citing security concerns. That is a red flag. If the proving key is not public, the system is not verifiable. The proof is a black box. The user is trusting the operator, not the math.
The same year, another project used a multi-party computation (MPC) setup for their trusted setup. The MPC was well-publicized, but the actual randomness used in the prover was not derived from the MPC. The team had reused an old setup from a previous circuit. The parameters were stale. The security guarantees were compromised.
These are not edge cases. They are the norm. The industry is moving fast, and security is taking a back seat.
The Economic Model of Provers
Let’s look at the economics. A prover is a service. The operator pays for hardware and electricity. They trade off between cost and security. A more secure prover is more expensive. The market currently does not reward security. Users choose the cheapest rollup, not the most secure one.
This creates a race to the bottom. Operators cut costs by using less secure proving systems. They use smaller circuits. They skip audits. They use a single machine. The users pay the price when a bug is exploited.
We need a new economic model. A model where the prover is bonded, where the block is slashed if the proof is invalid. We need to align incentives. The prover should be a staker, not a contractor.
Some projects are experimenting with this. They use a proof of stake for the prover, where the prover must stake tokens that can be slashed if they produce a false proof. This is a step in the right direction, but it is not enough. The slashing mechanism requires a way to detect false proofs. Detection is slow. It relies on a challenge period, like optimistic rollups. That defeats the purpose of instant finality.
The Verifier’s Dilemma
There is a deeper problem. The verification algorithm is cheap, but it is still a computation. If the verifier is running on a smart contract, the gas cost is non-trivial. To reduce costs, some teams use a verifier that is not fully verified. They use a reference implementation that is not audited. The verifier itself becomes a trust anchor.
This is the verifier’s dilemma. The verifier must be trusted, but it is not verifiable. The circle is complete.
The Path Forward
We need to build a new standard. A standard for open, verifiable, and auditable proving systems. The proving key must be public. The circuit must be open source. The prover must be run in a trusted execution environment. The setup ceremony must be repeated periodically.
We need to treat the prover as a core part of the infrastructure, not a black box. We need to audit the prover, not just the circuit. We need to test the prover under adversarial conditions.
This is not a theoretical exercise. It is a practical necessity. The next crypto crisis will be caused by a faulty prover, not a faulty smart contract. The industry is not ready.
Conclusion
Trust is a bug. The ZK-rollup ecosystem is built on a foundation of trust. The proof is a promise, not a guarantee. Until we fix the prover, the promise is hollow.
I am not advocating for a return to optimistic rollups. Optimistic rollups have their own problems: withdrawal delays, fraud proof complexity, and centralization. But at least their trust model is clear. You trust the operator during the challenge period. ZK-rollups have a more opaque trust model.
We need to bring the same level of scrutiny to the prover that we bring to the smart contract. We need to demand open source, audits, and verifiability. We need to stop accepting centralized provers as a temporary solution.
The future is verifiable. But it is not here yet. And it will not arrive until we stop pretending that ZK-proofs are magic.
Proofs over promises. Trust is a bug. If it’s not verifiable, it’s invisible.
Let’s build the verifiable future. But let’s be honest about the present.