What are Zero Knowledge Proofs?
What if I tell you I know a solution to a problem, without revealing the solution? You'll say it's impossible, but it is possible with Zero Knowledge proofs.
At a high level, Zero Knowledge Proofs or ZKPs are math magic that allows you to prove you have certain information without revealing the actual information.
It is one of the best topic which i personally am very interested in, I am reading a lot about it and will be posting on this site about my learning.
Why do we need ZKPs?
ZKPs are one of the most important things for the mass adoption of Blockchains. Blockchains, by default, are open; their nature focuses on transparency; however, we don't want everything to be transparent, right?
Thus, the introduction of ZKPs into the blockchain systems will do wonders. Imagine sending crypto from your wallet to another wallet without anyone knowing who the sender is and who the receiver is; it's a part of privacy.
Blockchains like StarkNet, ZCash, Monero etc uses ZK Proofs as their base to overcome this part of the blockchains.
Another area where ZKPs are useful is the scalability of blockchains, which is another thing required for the mass adoption of this technology.
If we can compute a very complex problem off-chain and present a proof on to the network, it will be amazing since all the heavy lifting is done by off-chain computation, and on-chain will have much more space to breathe.
There are many ways ZKPs are usefull above were few of the examples we will cover more in this series and this blog.
Principles of ZKPs
These are the terminologies used in ZKPs, although some people may use other words to explain the same thing, but the context is the same
Nature of ZKPs
ZKPs are the mathematical proof of a solution that convinces the verifier that the solution is real and valid.
If you know the password of a computer, I must be 100% convinced that you know the password without revealing the actual password what you will do to prove that you will open the computer for me right, but i don't have any way to find the actual password
Hence, for a ZKP to be correct, it must satisfy 3 things
- Completeness: An honest prover can convince a verifier that a true statement is valid.
- Soundness: A false statement cannot convince an honest verifier, except with negligible probability.
- Zero-Knowledge: The verifier learns nothing beyond the validity of the statement, keeping the secret hidden.
Since we are dealing with Verifier and Prover, let's understand what both of them stand for
- Prover: Prover is an entity, it can be a human or a computer system, which wants to prove a statement is true, or it possesses a certain secret ("witness", more on this in upcoming blogs)
- Verifier: Verifier is an entity that is responsible for checking whether the claims/proofs from the prover are correct or not
Types of ZKPs
There are mainly 2 types of ZKPs: interactive proofs and non-interactive proofs.
Interactive Zero Knowledge Proofs
In Interactive proofs, there is constant communication between the verifier and prover to determine whether the ZKP is valid or not, which means there is constant communication between the verifier and Prover until the verifier is 100% conviced that the proof is valid.
Examples of Interactive Zero-Knowledge Proofs
1. Ali Baba Cave
Imagine two people: Person P, who is the proverer and Person V, who is the verifier
There is a cave with 2 entrances Entrance A and Entrance B. In the middle of the cave there is a door locked with a password
Person V wants to prove to Person P that he knows the combination of the password, and he doesn't want to reveal that password. Person P says How can I believe that.
V turns his back towards the cave, P enters from A, enters the passcode and exits from B.
V asks how I can be 100% sure that you didn't enter from B and exit from B, and there is 50% chance of that.
So they repeat this process 30 times, and V is now convinced that P indeed know the solution and is valid.
As there are multiple rounds of communications this system is not efficient for a blockchain system where we need to keep track of all these states.
Interactive zero-knowledge proofs are not efficient, and state is not free in blockchain, hence it's expensive and time-consuming, and this can't be the solution for the future right?
Non-Interactive Zero-Knowledge Proofs
We have discussed the problems with Interactive ZKPs, since there are very extensive interactions, so we use Non-Interactive Zero Knowledge proofs for blockchain systems, where there is a trustless verification, so Non-Interactive Zero Knowledge proofs come into the picture
In Non-Interactive ZKP the verifier and prover shares a single round of communication, and that proof can be verified by verifier can be verified independently and it can be verified by multiple parties
Thus, this type of ZKP is suitable for blockchain applications, which we can integrate into smart contracts and blockchain systems
There are different types of Non-Interactive ZKPs, including SNARKs, STARKs, bulletproofs, and all of these are umbrella terms
For example, SNARKs it contains Groth16 and Plonk. We will go through this later
Using Non-Interactive ZKPs, you can prove many things, like off-chain computation, and KYC use cases are endless
Terminologies used in Zero-Knowledge Proofs
These are the terms or keywords used in ZKPs; however, these are the terminologies we are refering everyone doesn't need to use the same terminologies and the same context behind it. There might be slight differences. If you are reading some resources on ZKPs, make sure you keep this in mind
Terminologies
- Claim or Statement: A claim or statement is an assertion that something is true, in ZKPs it refers to a property being proven without revealing its information. This is the claim that the prover is making about the "witness", Example: I am over some age, therefore i can enter this club
- Inputs: In ZKPs inputs can be of two types: Private inputs and Public inputs
- Private Inputs: Private inputs are the inputs to the ZK system where this input is known by the prover but not to the verifier. Example: Private keys, your age for entering the club
- Public Inputs: Public inputs are inputs that are known by both verifier and prover, and it is used to check if the proof is valid or not. Example: Public keys, Minimum age to enter the club
- Constraints: This is a mathematical question that must be satisfied to claim to be valid. These are the rules that inputs must follow. These are the core of constraint systems. Example: For you to enter the club, your age must be greater than or equal to 18, so age >= 18 is your constraint
- Circuit: Circuits is the comination of the constraints, it is the series of mathematical relation and operations the circuit defines how constraints works together to verify the claim, in a circut all the constraints must verify to verify the claim, Example: If the club have maximum age of 40 you must be less than 40 years so the constraints here will be age >= 18 and age <= 40 the combination of both constraints is circuit
- Witness: A Witness is a set of secret values that allows the prover to demonstrate that the claim or statement is valid. The witness must satisfy the contracts of the circuits
- Prover: An entity that generates proof of the computation to demonstrate the knowledge of the witness while satisfying the circuit constraints. The prover does not reveal the secret but proves the statement
- Verifier: Entity that verifies the proof is valid. It uses an algorithm to check whether the proof is valid or not against the input. This can be done off-chain and on-chain
Trusted Setups
Trusted setup is a crucial step in certain ZKP system particullary in SNARKs like GROTH16 and PLONK types of SNARKS
"Trusted setup ceremony is a procedure that is done once to generate some data that must be used every time a cryptographic protocol is run."
Here is the image that will explain the trusted setup, where a secret is converted into cryptographic data, and then the secret is destroyed, thus only data will be remaining, and only that will be used in the system
Once you have the data, it must be used every time in a ZKP system
Once you have the cryptographic data, only that will be used every time for a zero-knowledge proof
There are multiple things to be taken care of for a trusted setup. Here are those:
1. Toxic Waste: While creating Cryptographic data from secret random values, if these random values are leaked, an attacker can forge invalid proofs that will pass verifications
2. Common Reference String (CRS): This are sets of public parameters that both the prover and verifier use in the proof generation and verification process, and this is the output of Step 2, which creates cryptographic data from the secret
3. Structured Reference String (SRS): SRS are speccific type of CRS, but it contains structured data with a specific format, for example, Elliptic curve points where the points are generated from a secret value, and these points are structured in a way that they will plot the particular point on the elliptic curve
4. Multi-Party Computation: In multi-party computation, multiple entities are involved and provided secret information. They add their own randomness and generate the cryptographic data. They must destroy all of their secret information; their data is used to generate the final data. If even one of the parties destroys the secret and all of the others don't, the secret cannot be reconstructed, hence it is secure.
5. Powers of Tau: Points on the elliptical curve are denoted via powers of tau; these are used in the trusted setup in SNARKS
Powers of Tau are the points on an elliptic curve generated using multi-party computation, which is called powers of Tau. Each of these elliptic curve points is generated by some secret times a point
By using MPC, no one needs to know T. For every Elliptic curve point, there is a separate MPC done to generate T. Essentially, every party is contributing its randomness to generate T, which means it is not possible to reconstruct the secret
6. Polynomial Commitment: Polynomial commitment is a cryptographic method that allows you to commit to a polynomial without revealing the coefficients of the polynomial. This allows you to prove properties of this polynomial later. Different proving systems use different commitment schemes
Essentially, it is like telling, I am going to use this polynomial without revealing the coefficients of the polynomial
Examples of Trusted Setups
Here we are going to talk about SNARKs
Trusted setups can be either Circuit-specific, meaning the cryptographic parameter/data needs to be regenerated for every circuit, or it can be Universal, where the cryptographic parameter can be reused in different circuits
Groth 16
This is a two-phase setup
Phase 1: Powers of Tau
- Generates a general-purpose SRS for a circuit of a certain size
- This step is not circuit-specific and can be reused
- This is where the SRS containing the encoded powers of tau as elliptical curve points is generated
- These are the gt, gt^2, gt^3, etc elements
Phase 2: circuit-specific
- The parameters of the first phase are combined to circuit specific constraintsd to produce an extended SRS (with its own toxic waste)
- This generates a). Proving key and b). Verification key
PLONK
This is an example of a universal setup
- It uses Universal and updatable SRS
- Multiple circuits can share the same setup as long as they fit within a size constraint
- We use the Powers of tau process to generate the SRS, which is then used for polynomial commitments
- PLONK commonly uses the KZG commitment scheme, where polynomials are committed using powers of Tau and evaluated at a specific challenge point.
To conclude, Trusted setups is a foundational concept of ZKPs, specifically in SNARKS. It introduces the initial trust assumption by introducing MPC and Universal setups, and we can mitigate the risks
Proof of Knowledge and Proof of Computation
Zero-knowledge proofs are not always proving about the knowledge; most often, it is proving the computation you did on a secret proof of correctly computing constraints, therefore knowing the correct inputs
There is a subtle difference between proving the knowledge and proving the computation
The term Zero knowledge refers to a privacy property, where we are revealing nothing beyond the validity of the statement being proven
What exactly are we proving? We assume we are providing information of a secret that we know, but for most instances, we are not actually proving the knowledge, but rather that the computation is performed correctly, and thus we knew the correct inputs
So by creating proof of computation, we indirectly create proof of knowledge of private inputs
Referring back to our example, "I am over 18 years, therefore I can enter the club"
Instead of proving age, we are proving age >= 18, where age is the secret input. Age >= 18 is a circuit if you compute age >= 18; thus, it is proof of computation and indirectly proof of knowledge
Conclusion
Zero Knowledge Proofs are not just a cryptographic curiosity — they are foundational infrastructure for the next generation of blockchain systems.
We covered a lot of ground here: the three core properties every ZKP must satisfy (Completeness, Soundness, and Zero-Knowledge), the shift from Interactive to Non-Interactive proofs, the role of Trusted Setups in SNARK systems like Groth16 and PLONK, and the subtle but important distinction between proof of knowledge and proof of computation.
The key insight to take away: when you generate a ZK proof, you are not directly proving that you know a secret. You are proving that you correctly executed a computation, and that computation being valid implies you had the right inputs. The privacy comes as a consequence of how the math works, not as an afterthought.
This is still just the surface. In the upcoming posts in this series, we will go deeper into:
- How arithmetic circuits and constraint systems actually work
- The internals of Groth16 and PLONK
- Writing circuits in Circom
- How STARKs differ from SNARKs and why it matters
If any of this clicked for you — or if something didn't — drop a comment below. This stuff took me multiple reads to internalise, and I am still learning. That's the point of this series.