ZKPs Prove the Maths, But Who Proves the Input?

Introduction

In my experience, articles about Zero Knowledge Proofs (ZKPs) tend to assume you are fully on board with their use cases and quickly dive into implementation details of circuits, provers and verifiers.

I think it is worthwhile to start from the business case and work the other way. This way we can learn what use cases there really are.

Imagine you are pitching a carbon-emissions product to a large company. The company wants to prove its emissions are below some threshold. Regulators, investors and customers want confidence in the reported figure. At the same time, the company does not want to expose sensitive internal data such as fleet sizes, routes, fuel usage, warehouse activity, supplier relationships, or anything else that reveals too much about how the business actually operates.

At first glance, ZKP looks perfect for this. You can pitch it in one neat sentence: “we can prove your emissions number is correct without revealing the underlying business data”.

This sounds super! It sounds privacy-preserving, technically sophisticated, exactly the sort of thing people want modern cryptography to do. The company keeps its secrets, outsiders get assurance, maths gets verified and everyone goes home happy.

Except that, if we look carefully, the interesting question was never really whether the maths was done correctly. The interesting question was where the input data came from, and why anyone should trust it.

That is the trust boundary, and that is where, in my view, some ZKP business cases start to wobble.

The carbon-emissions story

Let’s make the example more concrete.

Suppose a company claims it operated 5 trucks over some reporting period. From that, together with whatever other private operational inputs it uses, it calculates total emissions are 100 tons. It then produces a zero knowledge proof showing that this figure really does follow from the underlying calculation.

That sounds impressive, and in one narrow sense it is. The proof verifies, the output is consistent with the supplied input and the report gets a nice cryptographic sheen around it.

But now imagine the truth is that the company actually operated 6 trucks, not 5, but wilfully or accidentally entered 5 trucks into the emmissions calculation.

The ZKP has not proved that the company really operated 5 trucks. It has only proved that if the input was 5 trucks, then 100 tons is the correct result of the calculation. That is a much weaker statement than people might think they are buying.

In other words, the proof may be perfectly valid while the business claim is still false. If the trust problem lives upstream in the raw data, then the ZKP has not removed that trust. It has just wrapped the output in something that looks much more authoritative.

Now, because it can be fun to get AI to generate images of complex situations, let’s look at it pictorially:

ZKP shows the 100 tons emissions is correct from 5 trucks, but really there were 6 trucks. The 6th truck is out emitting carbon, and real total emissions are 120 tons.

This use case is useful as a thought experiment, because it exposes the trust boundary very clearly. The proof is not fake, the maths is not wrong, the problem is that one thing people care about is whether the hidden input reflects reality. The ZKP on its own does not answer that.

Why this pitch still sounds so compelling

Companies often do want to prove something about their operations without revealing all the operational detail underneath. A logistics firm may not want to reveal route-level data. A manufacturer may not want to expose supplier-level information. A trading firm may not want to show position-level detail. None of that is unreasonable.

The mistake is assuming that ZKP solves the separate problem of whether the hidden data is true in the first place, because it does not.

What the proof is actually proving

This is the stage where it helps to get slightly more technical.

A ZKP lets one party prove that a statement is true without revealing the private data that makes it true. In practice, we can think of four actors here, highlighted in bold: a ZKP allows us to prove that some input data X, when passed through some computation Y, produces some result Z, without necessarily revealing X itself ¹.

So in the carbon-emissions example:

• X is the private operational data, such as truck counts and fuel usage.
• Y is the carbon-emissions calculation, perhaps some ISO standard.
• Z is the reported output, such as 100 tons.
• the ZKP shows that Y(X) = Z without revealing X.

The ZKP proves that the output was correctly computed from the supplied input, but it does not prove that X is true in the real world.

I find it helpful to compare direct verification with a ZKP:

Proof Type	Explanation
Direct verification	Reveal input X, let others run computation Y, and check that the result is Z. Easy peasy.
Zero Knowledge Proof (ZKP)	Keep input X hidden, but use a ZKP to prove that applying computation Y to valid input X gives result Z.

There is one more subtlety here. Zero knowledge is about what the verifier learns. Whether that verification is also fast depends on the proving system being used ². In many real-world systems, especially blockchain ones, fast verification is a major part of the appeal.

Still, whether verification is fast or private or elegant does not change the central point. If the hidden input X is self-reported and untrusted, then all we have really proved is that the claimant did the maths properly on top of their own hidden numbers. That may be better than nothing. It is not the same as proving the business claim people might have thought they were buying.

Where the trust still lives

Once you see the carbon example in those terms, the broader point becomes fairly simple. If the raw inputs are self-reported and opaque, then the ZKP mainly proves internal consistency. So where does the missing trust still live?

If the input comes from signed sensor feeds, independently audited records, regulated disclosures, tamper-resistant hardware, or some other credible attestation layer, then the story becomes much stronger. In that world, the ZKP is no longer being asked to conjure truth out of thin air. The provenance problem is being handled elsewhere, and the ZKP is doing what it is actually good at, which is preserving privacy while still proving correct computation.

So I would not say carbon emissions is always a bad fit for ZK. I would say it is a conditional fit. It only becomes compelling once the upstream data problem has already been solved by something else.

And that, in turn, creates an awkward business question. If an organisation is already prepared to trust that the hidden input data was captured honestly, then in many situations it may also be prepared to trust the rest of the calculation stack. In those cases, the incremental value of the ZKP may be smaller than a pitch deck suggests.

Where ZK is genuinely strong

Once you separate truthful input from correct computation, then stronger use cases become easier to spot.

1. Passwords, secrets and credentials

Suppose a prover wants to show they know a password, or more generally some secret, without revealing it. They can prove that they know an input which, when hashed, matches a known public value. This is exactly the kind of thing ZKPs are good at.

The important point is not that there is literally only one possible input for a given hash output. That is not true in a strict mathematical sense ³. The point is that, under ordinary cryptographic assumptions, finding any secret that satisfies the check without actually knowing the intended one should be computationally infeasible. So the verifier gets confidence that the prover really does know the secret, without learning what it is.

This wasn’t true in our carbon emissions story, because an output of 100 tons doesn’t guarantee only 5 trucks were present in the real world.

2. EVM transactions and rollups

This is another genuinely strong use case, but for a different reason. Here, the input is typically public. Ethereum transactions are public, the state-transition rules are public and there is nothing especially secret about the underlying computation. So the value of the proof is usually not privacy.

The value is that it lets lots of people verify a large computation cheaply. Processing a large batch of EVM transactions is expensive. Re-executing them all on-chain, or forcing every verifier to do the full work, is labout intensive. A validity proof lets a prover do the heavy computation once, then gives everyone else a much cheaper way to check that the claimed state transition was valid ⁴.

That is why ZK-based rollups are such a strong use case. The proof ties the claimed output state to the batch of inputs and the execution rules, and it gives verifiers a much cheaper check than rerunning the whole computation themselves. Privacy may be absent entirely, the gain is succinct verification and scalability.

Even here, though, it is worth staying precise. A validity proof shows that the computation was correct. It does not, by itself, solve every other problem in the system. If the relevant state data is withheld, users may still have a data-availability problem even though the proof itself is valid ⁵. Again, the trust has to live somewhere.

What ZKPs actually solve

A ZKP can remove the need to reveal private input data. A ZKP can remove the need for every verifier to rerun an expensive computation. A ZKP can preserve privacy while still giving confidence in a derived claim. What it cannot do, on its own, is conjure trustworthy real-world input data out of thin air.

This distinction matters because it separates three different kinds of claim:

• Cryptographic claims. “I know a secret that satisfies this relation”.
• Computation claims. “This output really does follow from these public inputs under these rules”.
• Real-world claims. “These hidden inputs accurately describe reality”.

ZK is excellent at the first two. It is not, on its own, a solution to the third.

Footnotes

1. More formally, ZK systems are often described in terms of a public statement and a private witness satisfying some relation. I am using X, Y, and Z here because I find it easier to read. ↩

2. Strictly speaking, “zero knowledge” and “succinct verification” are different properties. In practice, people often discuss them together because modern SNARK and STARK systems often aim to provide both. ↩

3. Hashes are many-to-one mappings, so collisions exist in principle, but in practice it is not feasible to find out what an input value was for a given hash. ↩

4. In many blockchain settings this is better described as a validity proof for a state transition. The zero knowledge property may be present, but the main win is often cheap verification of a correct computation. ↩

5. This is one reason people distinguish between validity and data availability. A proof can show that a transition was valid without guaranteeing that all underlying data needed by users is available to them. ↩