How can I prove that I know a secret without actually revealing the secret?
When I first came across Zero-Knowledge Proofs (ZKPs), this was the idea that caught my attention.
How can someone prove that they know something without actually revealing that thing?
At first, it sounds almost impossible.
If I ask you to prove that you know my password, the obvious solution would be to tell me the password.
But then I've revealed it.
So what if you could prove:
"I know the password."
without telling me:
"The password is X."
That's the basic idea behind Zero-Knowledge Proofs.
A Zero-Knowledge Proof allows one party to prove to another party that a statement is true without revealing the underlying secret or information that makes the statement true.
This simple idea has become extremely important in cryptography and, more recently, in blockchain.
Let's break it down.
What Is a Zero-Knowledge Proof?
Let's start with a simple example.
Suppose I tell you:
"I know a number
xsuch thatx² = 144."
You might immediately ask:
"What is
x?"
I could simply tell you:
x = 12
Now you know the answer.
But what if I want to prove that I know x without revealing x itself?
That's where a Zero-Knowledge Proof comes in.
I can construct a cryptographic proof that convinces you:
I know x such that:
x² = 144
without directly revealing:
x = 12
The important distinction is:
I'm proving that I know the secret rather than revealing the secret.
That is the basic idea behind Zero-Knowledge Proofs.
The Three Properties of a Zero-Knowledge Proof
There are three important properties behind a Zero-Knowledge Proof:
- Completeness
- Soundness
- Zero-Knowledge
Let's understand each one.
1. Completeness
If the statement is true and the prover is honest, the verifier should accept the proof.
In simple terms:
If I actually know the secret, I should be able to prove it.
2. Soundness
If the statement is false, a dishonest prover shouldn't be able to convince the verifier that it is true, except with a very small probability.
In simple terms:
I shouldn't be able to fake knowledge that I don't have.
3. Zero-Knowledge
The verifier should not learn the secret itself from the proof.
The verifier learns that the statement is true, but doesn't learn the underlying secret.
In simple terms:
The proof proves the claim without exposing the secret.
So we can think about the three properties like this:
Completeness
↓
True statements can be proven
Soundness
↓
False statements cannot easily be proven
Zero-Knowledge
↓
The secret remains hidden
These three properties form the foundation of Zero-Knowledge Proofs.
The Ali Baba Cave Example
One of the most famous examples used to explain Zero-Knowledge Proofs is the Ali Baba cave.
This example helped me understand the idea much more intuitively.
Imagine a cave shaped like a circle.
There are two paths and a locked door inside:
A
/ \
/ \
/ \
/ 🔒 \
/ \
B-----------C
There are two entrances, A and B.
The door in the middle can only be opened using a secret password.
Alice claims:
"I know the password."
Bob doesn't believe her.
But Alice doesn't want to tell Bob the password.
So they perform a test.
Step 1
Alice enters the cave.
She randomly chooses one of the two paths:
A → Door → B
or:
B → Door → A
Bob doesn't know which path she chose.
Step 2
Bob enters the cave and randomly asks:
"Come out from A."
or:
"Come out from B."
Step 3
If Alice actually knows the password, she can open the door and come out from whichever side Bob requests.
But if she doesn't know the password, she can only succeed when Bob happens to ask for the side she originally entered.
So without knowing the password, Alice has a:
1/2
chance of successfully cheating in one round.
But Bob can repeat the experiment.
After 10 rounds:
(1/2)^10 = 1/1024
After 20 rounds:
(1/2)^20 = 1/1,048,576
The probability of Alice successfully cheating becomes extremely small.
Bob can therefore become highly confident that Alice actually knows the password.
But the important part is:
Bob never learns the password.
That's the basic intuition behind Zero-Knowledge.
Prover and Verifier
There are two important roles in a ZK system.
Prover
The Prover is the person or system trying to prove something.
In our example:
Alice = Prover
Alice knows the secret and wants to prove that she knows it.
Verifier
The Verifier is the person or system checking the proof.
In our example:
Bob = Verifier
Bob doesn't know the password, but wants to become convinced that Alice does.
The basic flow looks like this:
SECRET
│
▼
┌─────────┐
│ PROVER │
└────┬────┘
│
│ Proof
▼
┌─────────┐
│VERIFIER │
└────┬────┘
│
┌────┴────┐
▼ ▼
VALID INVALID
The Prover has the secret.
The Prover generates a proof.
The Verifier checks the proof.
What Is a Witness?
Now we can introduce another important term:
Witness.
A witness is the information that allows the prover to demonstrate that a statement is true.
Let's return to our example:
x² = 144
Suppose:
x = 12
Then conceptually:
Public statement:
x² = 144
Private witness:
x = 12
The prover uses the witness when generating the proof.
The verifier doesn't necessarily need to see the witness.
This concept becomes particularly important when we start talking about ZK circuits.
Public Inputs vs Private Inputs
Another important distinction is between public inputs and private inputs.
Suppose I want to prove:
hash(secret) = H
I have:
secret
and:
H
I want H to be public.
But I want secret to remain private.
So:
PUBLIC INPUT
H
PRIVATE INPUT
secret
The prover knows:
secret
The verifier knows:
H
The prover wants to prove:
Hash(secret) == H
without revealing:
secret
This is one of the fundamental patterns behind many ZK applications.
Statement → Witness → Proof → Verification
At this point, we can put the pieces together.
A simplified ZK system looks something like this:
PUBLIC INPUT
│
▼
┌─────────┐
│ CIRCUIT │
└────┬────┘
▲
│
PRIVATE INPUT
/ WITNESS
/
▼
┌──────────┐
│ PROVER │
└────┬─────┘
│
│ Cryptographic Proof
▼
┌──────────┐
│ VERIFIER │
└────┬─────┘
│
▼
✓ Valid
✗ Invalid
The prover uses the witness and the rules defined by the circuit to generate a proof.
The verifier checks that proof.
So What Is a ZK Circuit?
This is where things start becoming more interesting from a developer's perspective.
I've often seen people say:
"We need to write a ZK circuit."
But what exactly is a circuit?
At a high level, I think of a ZK circuit as a mathematical description of the conditions that must be satisfied.
Suppose we want to prove:
a + b = c
We can express that as:
a + b - c = 0
Now suppose:
a = 5
b = 7
c = 12
Then:
5 + 7 - 12 = 0
The condition is satisfied.
But if:
a = 5
b = 7
c = 13
then:
5 + 7 - 13 = -1
The condition isn't satisfied.
So, at a basic level:
A ZK circuit defines the conditions that a valid witness must satisfy.
There is much more to circuits, but this is a useful mental model when starting out.
A Circuit Isn't Just a Normal Program
This is an important distinction.
In normal programming, I might write:
function calculate(a, b) {
return a + b;
}
The program tells the computer to take a and b, add them, and return the result.
With ZK, I'm interested in describing the computation in terms of conditions that need to be satisfied.
For example:
c = a + b
can be represented as:
a + b - c = 0
The question becomes:
What conditions must be true for this computation to be valid?
This is one of the biggest conceptual shifts when moving from normal programming toward ZK programming.
A Tiny Example
Let's take an even simpler example.
Suppose I want to prove:
I know a number whose square is 25.
My private input is:
x = 5
My public input is:
y = 25
The condition is:
x² = y
or:
x² - y = 0
The prover knows:
x = 5
The verifier knows:
y = 25
The prover generates a proof showing that there exists some x such that:
x² = 25
The verifier checks the proof.
If the proof is valid:
✓ Proof accepted
The verifier doesn't need to receive x directly.
There is also a small but interesting detail here.
Both:
5² = 25
and:
(-5)² = 25
are true.
So what I'm actually proving is:
I know a valid
xsuch thatx² = 25.
Not necessarily:
I know that
x = 5.
This gives us an important lesson:
The circuit defines exactly what is being proven.
Where Do SNARKs and STARKs Fit?
Two terms that come up almost immediately when learning ZK are:
SNARKs
STARKs
The easiest way I currently think about them is:
Zero-Knowledge Proofs are the broader concept.
SNARKs and STARKs are different families of cryptographic proof systems that can be used to create succinct proofs.
So, very roughly:
ZERO-KNOWLEDGE PROOFS
│
┌─────────┴─────────┐
│ │
SNARK STARK
There are many differences between them, but those differences aren't necessary to understand the basic idea of ZK.
For now, the important thing is simply knowing where these terms fit.
Why Is ZK Important for Blockchain?
This is where Zero-Knowledge Proofs become especially interesting for me as someone coming from blockchain development.
Blockchains have a scalability problem.
As the number of transactions and computations increases, verifying everything can become expensive.
ZK proofs provide another possibility.
Instead of requiring everyone to reproduce a large computation, a prover can perform the computation and generate a proof showing that the computation was performed correctly.
Conceptually:
Large computation
│
▼
Prover
│
▼
Proof
│
▼
Blockchain
│
▼
Verify
The blockchain can then verify the proof instead of necessarily reproducing the entire computation itself.
This is one of the key ideas behind ZK-based scaling systems.
What Is a ZK-Rollup?
A ZK-rollup is a Layer-2 scaling system that processes transactions away from the Ethereum mainnet and uses cryptographic proofs to demonstrate that the resulting state transition is valid.
Imagine there are many transactions:
Transaction 1
Transaction 2
Transaction 3
...
Transaction 1000
The rollup can process those transactions and generate a proof about the resulting computation.
Conceptually:
Transactions
│
▼
Rollup execution
│
▼
Prover
│
▼
Proof
│
▼
Ethereum
│
▼
Verify
The important idea is:
The proof provides cryptographic evidence that the computation was performed correctly.
This allows the Ethereum mainnet to verify the result without having to perform all of the underlying computation itself.
ZK Doesn't Necessarily Mean Privacy
This was an important distinction for me.
It is easy to assume:
Zero-Knowledge = Privacy
But that's not necessarily true.
Zero-Knowledge Proofs can absolutely be used for privacy.
But they can also be used for:
- Scalability
- Verifiable computation
- Identity
- Authentication
- Blockchain state verification
For example, a ZK system could prove:
These 10,000 transactions
were executed correctly.
The transactions themselves don't necessarily have to be hidden.
So I think it's better to view ZK as a proof technology rather than simply a privacy technology.
Where Do Circom, Noir and Cairo Fit?
If you've looked into ZK development, you've probably come across:
Circom
Noir
Cairo
These aren't different types of Zero-Knowledge Proofs.
They are languages or environments used to express computations that can be proven using ZK proving systems.
At a very simplified level:
ZK Application
│
▼
ZK Program
│
┌───────┼───────┐
▼ ▼ ▼
Circom Noir Cairo
Each has its own design and ecosystem.
For a beginner, the important thing is simply to understand that ZK is the broader concept, while these tools provide ways for developers to build programs or circuits that can be proven.
Putting Everything Together
Let's take our simple example again.
We have:
Public input:
H
Private input:
secret
Our condition is:
Hash(secret) == H
The private information acts as the witness.
The circuit describes the condition that must be satisfied.
The prover uses the witness to generate a cryptographic proof.
The verifier receives the public information and proof.
Then the verifier checks whether the proof is valid.
Conceptually:
APPLICATION
│
▼
ZK PROGRAM
│
▼
CIRCUIT
│
┌───────┴───────┐
│ │
▼ ▼
PUBLIC INPUT WITNESS
│ │
│ ▼
│ PROVER
│ │
│ ▼
│ PROOF
│ │
└───────┬───────┘
▼
VERIFIER
│
▼
✓ VERIFIED
This is the basic mental model I use when thinking about Zero-Knowledge Proofs.
Final Thoughts
Zero-Knowledge Proofs initially sound almost magical:
"Prove that you know something without telling me what you know."
But there isn't any magic involved.
At its core, it's mathematics, cryptography and computation coming together to create a way of proving statements without revealing certain information.
The simplest way I understand it is:
I have a secret.
↓
My secret satisfies certain conditions.
↓
I generate a cryptographic proof.
↓
You verify the proof.
↓
You become convinced the conditions are true.
↓
My secret remains hidden.
That's the basic idea behind Zero-Knowledge Proofs.
And once this mental model is clear, terms like witness, circuit, prover, verifier, SNARK, STARK and ZK-rollup start making a lot more sense.
This is just the surface of Zero-Knowledge Proofs, but it's a good place to start.
Welcome to ZK. 🚀
Top comments (0)