Zero-Knowledge Proofs Without the Magic: What the Prover and Verifier Actually Do

Zero-knowledge proofs are often described with a sentence that sounds almost impossible:

Prove that you know something without revealing what you know.

That description is correct, but it hides the part developers actually need to understand.

A zero-knowledge proof is not encryption. The prover does not simply hide some data and send it to the verifier.

Instead, the prover constructs a proof that a computation is valid, while revealing only the information that the protocol allows the verifier to see.

This distinction becomes important when ZK proofs are used in blockchain systems, where computation can be performed privately off-chain and verified cheaply on-chain.

Start With a Simple Problem

Suppose Alice knows a secret value x.

There is a public value derived from it:

y = hash(x)

Alice wants to prove:

“I know a value x such that hash(x) = y.”

But she does not want to reveal x.

A traditional solution would require Alice to reveal the secret:

Alice
  |
  | x
  v
Verifier
  |
  | hash(x) == y ?
  v
Valid

A zero-knowledge protocol changes the interaction:

             secret x
                |
                v
Alice       Prover
                |
                | proof
                v
           Verifier
                |
                v
        "The statement is valid"

The verifier learns that Alice knows a valid x, but does not learn x itself.

The interesting part is how the proof is constructed.

The Three Things You Need to Separate

When working with ZK systems, three concepts are easy to mix together:

1. The witness

The witness is the private information known by the prover.

In our example:

witness = x

The witness never needs to be exposed to the verifier.

2. The public inputs

These are values that the verifier is allowed to know.

public input = y

3. The statement

The statement defines what must be proven.

For example:

hash(x) == y

So the prover is effectively proving:

I know x
such that
hash(x) == y

without sending x.

That separation between witness, public inputs, and computation is one of the most useful mental models for understanding ZK systems.

A ZK Proof Is Really a Proof of Computation

This is where ZK becomes more interesting for blockchain developers.

Instead of thinking:

“I want to hide a value.”

Think:

“I want someone to verify that a computation was executed correctly without giving them all of the computation's private inputs.”

For example:

Private inputs
     |
     v
+-----------+
| Computation|
+-----------+
     |
     v
   Result
     |
     v
   Proof
     |
     v
+-----------+
| Verifier  |
+-----------+

The verifier does not need to reproduce the entire computation.

It only needs to verify the proof.

This is why ZK proofs are useful for blockchain scaling and privacy.

Where the Blockchain Fits

Blockchains are good at verification, but expensive as general-purpose computation environments.

Imagine a computation that requires millions of operations.

Executing all of them directly on-chain can be expensive.

A ZK-based architecture can move the expensive computation off-chain:

                 Off-chain
              ┌──────────────┐
              │   Prover     │
              │              │
Input ────────>│ Computation  │
              │              │
              │ Generate ZK  │
              │    Proof     │
              └──────┬───────┘
                     │
                     │ proof
                     v
              ┌──────────────┐
              │ Blockchain   │
              │              │
              │   Verifier   │
              └──────────────┘

The blockchain does not need to trust the prover.

It only needs to verify the proof.

This creates an important engineering trade-off:

Move computation off-chain, but preserve verifiability on-chain.

Why This Is Different From Encryption

A common misunderstanding is that ZK proofs are simply another form of encryption.

They solve different problems.

Encryption:

“Only authorized parties should be able to read this data.”

Zero-knowledge proof:

“You should be able to verify that this statement is true without learning my private information.”

You can also combine both techniques in the same system.

For example, sensitive application data can remain encrypted while a ZK proof demonstrates that the data satisfies a particular condition.

From Simple Examples to Real ZK Circuits

Real ZK systems don't usually express the computation as:

hash(x) == y

and stop there.

The computation is represented as a set of constraints.

Conceptually:

x ──> Constraint 1
 │
 ├──> Constraint 2
 │
 └──> Constraint 3
          |
          v
      Valid / Invalid

The proving system then transforms those constraints into a proof that can be verified without exposing the private witness.

Depending on the system, this can involve polynomial commitments, elliptic-curve operations, finite fields, and sophisticated proving algorithms.

You do not need to understand every mathematical detail to build a ZK application.

But you do need to understand the engineering boundary:

The circuit defines what is provable.

If the required business logic cannot be represented correctly in the circuit, the rest of the architecture does not matter.

The Cost Is Not Gone. It Has Moved.

This is one of the most important practical considerations.

ZK systems can reduce the amount of computation that needs to happen on-chain, but generating the proof can itself be computationally expensive.

A simplified cost model looks like:

                ZK Application
                      |
          +-----------+-----------+
          |                       |
          v                       v
   Proof Generation          Proof Verification
       expensive                 cheaper
      off-chain                  on-chain

This creates a trade-off between:

• Prover compute
• Proof generation time
• Proof size
• Verification cost
• On-chain gas
• Hardware requirements

The optimal design depends on the application.

A system that minimizes gas consumption may require significantly more off-chain computation.

A system optimized for proof-generation speed may have different hardware or circuit constraints.

There is no universal “ZK is cheaper” rule.

Where ZK Proofs Become Useful

The same architecture can support several classes of applications.

Private identity

A user could prove:

I satisfy eligibility condition X

without revealing every piece of information used to determine eligibility.

Private transactions

A system can prove that a transaction satisfies the required rules without exposing all transaction details publicly.

Scaling

A prover can execute a large amount of computation off-chain and submit a compact proof that the computation was performed correctly.

Verifiable computation

A service can perform computation for a user while providing cryptographic evidence that the result was generated according to a defined computation.

The common pattern is not simply privacy.

It is:

Compute privately or off-chain → generate proof → verify independently.

The Engineering Problems Are Different From Traditional Applications

ZK systems introduce constraints that are easy to underestimate.

Circuit complexity

The way you express an algorithm can have a major impact on proving cost.

An algorithm that is efficient in normal software may be expensive to represent as a ZK circuit.

Prover performance

Proof generation can require significant CPU, memory, or specialized hardware depending on the proving system and workload.

Data availability

In blockchain applications, proving that something is correct is not the same as making the underlying data available.

You still need to design how relevant data is stored, retrieved, and verified.

Smart contract integration

If proofs are verified on-chain, the verifier contract becomes part of the security-critical path.

Its interface, gas consumption, and failure handling need to be treated like any other production smart contract.

Key management

Some proving systems involve trusted setup assumptions or proving/verifying keys.

The security model of those components needs to be understood before deployment.

The Mental Model I Use

When evaluating a ZK architecture, I find it useful to reduce it to four questions:

1. What is private?
        ↓
2. What must be proven?
        ↓
3. Where is the computation executed?
        ↓
4. Where is the proof verified?

For example:

Private:
Customer eligibility data

        ↓

Prove:
Customer satisfies eligibility rules

        ↓

Compute:
Off-chain prover

        ↓

Verify:
Smart contract

If those four answers are clear, the rest of the architecture becomes much easier to reason about.

ZK Is Not a Magic Privacy Layer

Zero-knowledge proofs can provide powerful privacy and verification guarantees, but they do not automatically make an application private or secure.

The application still needs to handle:

• Access control
• Key management
• Smart contract security
• Data availability
• Circuit correctness
• Prover infrastructure
• Client-side security
• Protocol assumptions

A perfectly verified proof can still be part of a badly designed system.

The strongest ZK architectures are therefore not the ones with the most complicated cryptography.

They are the ones where the trust boundary is explicit.

Final Takeaway

The easiest way to understand zero-knowledge proofs is to stop thinking about them as a mechanism for “hiding data.”

Think of them as a way to establish:

“This computation was performed correctly, and I can prove it without revealing everything involved in that computation.”

That model explains why ZK proofs are useful for privacy, blockchain scaling, identity, and verifiable computation.

And it also explains the engineering trade-off: you are not eliminating computation—you are moving it to a place where it can be performed privately and then verified efficiently.

For a broader introduction to Zero-Knowledge Proofs, their privacy applications, and practical challenges, see SotaTek's Zero-Knowledge Proof in Blockchain guide.