Only the lazy haven’t written about privacy in crypto. The topic has become tangled in myths on both sides: some are convinced that crypto means total privacy, while others insist that blockchain transactions are more transparent than any bank transfer. The truth, as always, sits somewhere in the middle — and is a bit more complex than either claim.
To get to the bottom of this and answer whether true privacy in a blockchain actually exists, we suggest taking a proper deep dive into the world of Zero-Knowledge technologies.
How true that is, and what really lies behind those letters, we’ll unpack in this article.
Fair warning: ZK is real “higher maths” in cryptography, and understanding what’s what here isn’t just difficult — it’s seriously difficult. The topic is packed with dry terminology and mathematical formulae, and can sound like a dull university lecture in advanced mathematics. We’ll try to break it down so that even your grandma can grasp the core idea — without losing the technical depth of the subject.
Key Takeaways
- Blockchain privacy is not “by default”. Most networks are transparent, and real confidentiality is achieved via a Zero-Knowledge approach.
- ZKPs let you prove a fact without disclosing data. You can confirm a transaction is valid, that funds exist, or that requirements are met — without revealing the amount, balance, or personal details.
- There are two key technology families: zk-SNARKs and zk-STARKs. They represent different trade-offs between compactness, speed, transparency, and setup requirements.
- zk-SNARKs are about compact proofs and fast on-chain verification, but they often require a trusted setup, which creates risk if the initial ceremony is compromised.
- zk-STARKs are about transparency and scaling, require no trusted setup, and look stronger for long-term security and quantum resistance — but the proofs are usually larger.
- ZK is not only about privacy. ZK rollups and proofs are a foundation for scaling, digital identity, and next-generation fintech in Web3.
Zero-knowledge proofs
Imagine this: you want to prove to a bank that your income is above a certain threshold — but you don’t want to show the exact figure. Or you want to confirm your age on a website without entering your date of birth. Or you want to make a blockchain transaction so that nobody knows the amount or the sender — while everyone can still verify that everything is legitimate.
So what are these proofs?
If you search for information on this topic, you’ll most likely come across different variations of the term:
- zero-knowledge proofs
- zero-disclosure proofs
- zero-revelation proofs
- ZK proofs
Just know: it’s all the same thing.
The birth of the idea
The idea emerged back in the 1980s: in 1985, it was formulated by the scientists Goldwasser, Micali, and Rackoff. But real-world application in cryptography arrived much later.
The concept is as follows. There are two parties: the one who proves (the Prover) and the one who verifies (the Verifier). The Prover wants to convince the Verifier that they know some secret value — without revealing the value itself. In the end, the Verifier either becomes convinced, or not.
A true ZKP requires three conditions:
- Completeness (Completeness). If the statement is true, an honest Prover will always convince the Verifier.
- Soundness (Soundness). If the statement is false, a fraudster won’t be able to convince the Verifier (or only with a negligible probability).
- Zero-knowledge (Zero-Knowledge). The Verifier learns exactly one thing: the statement is true. No other information is revealed.
Ali Baba’s cave
Imagine a circular cave with a secret passage in the centre. The Prover enters one of the tunnels, and the Verifier, standing outside, shouts which tunnel the Prover should exit from. If the Prover really knows the secret, they will exit correctly. If not, they can only guess with a 50% chance. After 20 repetitions, the probability of guessing correctly by chance is less than one in a million — and the secret is still not revealed.
In cryptography, this is implemented in a more complex way, but the principle is the same: mathematical problems that are easy to verify, but impossible to solve without a secret key.
What are zk-SNARKs
![]()
zk-SNARK is an acronym. It stands for Zero-Knowledge Succinct Non-interactive Arguments of Knowledge.
Let’s break it down word by word:
Zero-Knowledge — zero disclosure. You prove you know a secret (for example, a password or a private key) without revealing the secret itself.
Succinct — the proof is small and can be verified quickly, regardless of how complex the original statement is.
Non-interactive — the Prover and Verifier don’t exchange messages back and forth. The Prover generates the proof once, and it can be verified independently.
Arguments of Knowledge — it’s specifically an argument that the Prover knows the secret, not just a statement.
Technical characteristics
Technically, zk-SNARKs are built on elliptic curves and arithmetic circuits: any computation is first represented as a set of mathematical constraints, and then a proof is constructed from that set.
Using zk-SNARKs requires a so-called trusted setup. That is, before the system launches, special parameters must be generated once (sometimes called toxic waste). If someone retains these parameters, they could create fake proofs.
In classic zk-SNARKs, the security of all subsequent proofs depends on how honestly the initial parameter generation was carried out. That’s why multi-party ceremonies are used: each participant contributes their share of randomness — and if at least one participant acted honestly and deleted their data, the system remains secure.
Examples of implementation
zk-SNARKs have concrete real-world implementations, namely: in Zcash, in Ethereum via zkEVM, and in protocols such as Groth16 and PLONK. By the way, Zcash is one of the first practical uses of this technology.
Other examples of zk-SNARK use:
- building privacy-focused cryptocurrencies
- zk-rollups (ZK rollups)
- DeFi protocols
Pros and cons
Pros:
- very small proofs (literally a few hundred bytes)
- fast verification (especially useful for blockchains and on-chain verification)
- well-studied technology, widely used in practice
Cons:
- trusted setup — a potential vulnerability: if the ceremony is handled incorrectly or the secret isn’t destroyed, parameter integrity can be compromised
- classic zk-SNARKs are not considered quantum-resistant
- complex cryptography and reliance on elliptic curves
What are zk-STARKs
![]()
zk-STARK is an acronym that stands for Zero-Knowledge Scalable Transparent Arguments of Knowledge.
They were created by Eli Ben-Sasson and his team at StarkWare around 2018. In essence, STARKs are an attempt to solve the main SNARK problem: removing the trusted setup.
The key words here are Scalable (scalability) — that’s what truly differentiates them — and of course Transparent (transparency).
Scalable — STARKs scale better as computation grows. That’s the key difference between zk-STARKs and zk-SNARKs. If SNARKs verify in roughly constant time, STARK verification time grows logarithmically — slowly, but it does grow.
Transparent means: no secret initialisation. All parameters are public and generated deterministically — from randomness that anyone can verify.
Technical characteristics
Instead of elliptic curves, STARKs use hash functions and field algebra. This matters: hashes are considered quantum-resistant, while elliptic curves are not. In theory, a quantum computer could break a SNARK; breaking a STARK is significantly harder. It’s also worth noting that this technology scales well and processes huge transaction volumes much faster, which makes STARK an ideal solution for launching Layer 2 (L2) systems.
Use cases
STARKs are used primarily in StarkNet and other products within the StarkWare ecosystem. This technology is also actively used in next-generation zk-rollup development.
Notable examples include:
- Rhino.fi — a multi-chain DeFi liquidity aggregator and cross-chain bridge that connects to dozens of blockchains and makes stablecoin transfers/onboarding fast and cheap by using STARKs for quick, low-cost transactions.
- StarkEx — a specialised “engine” for building applications, enabling projects to benefit from STARK proofs without having to build a complex general-purpose network.
- dYdX (v3) — the largest decentralised futures exchange, which ran on StarkEx for a long time, allowing traders to trade with near-instant execution and zero gas.
- Immutable X — a leading L2 network for NFTs and crypto gaming. By implementing STARKs, they enabled minting millions of NFTs almost for free with instant finality.
- Sorare — a fantasy football platform with player cards as NFTs, using StarkEx to process thousands of card trades per second.
Pros and cons
Pros:
- no trusted setup
- high scalability
- stronger long-term security
- quantum resistance
Cons:
- larger proof sizes
- more complex implementation
- higher network load
zk-STARKs vs zk-SNARKs
If someone asks you, “So what’s the difference?” or “Which technology is better?” give the honest answer: it depends on the task.
For comparison, let’s look at the table:
|
Parameter |
zk-SNARKs |
zk-STARKs |
|
Trusted setup |
Required |
Not required |
|
Proof size |
Small |
Larger |
|
Verification speed |
Very fast |
Decreases as computation grows |
|
Security |
Depends on the setup procedure |
More transparent |
|
Quantum resistance |
Weak or absent, though theoretically possible |
Implemented at a high level |
|
Scalability |
Moderate |
Very high |
|
Technology maturity |
More mature, well studied |
Younger, actively developing |
|
Audit complexity |
Higher |
Lower (transparent setup) |
|
Implementation complexity |
Well established |
Harder to implement |
In short:
- SNARKs are about efficiency and compactness
- STARKs are about security and scaling
Need the cheapest possible on-chain verification? Your choice is SNARKs.
Transparency and long-term resistance to quantum attacks matter more? Then it makes sense to look towards STARKs.
In practice, major projects don’t choose strictly “either/or” — they experiment with both. The Ethereum ecosystem includes zkSync (SNARK-based), StarkNet (STARK-based), Polygon zkEVM — and each backs its own approach.
Outlook for fintech and Web3
The most obvious use case is transaction privacy. ZK technologies can prove a user has sufficient funds for a deal without revealing their balance. Or they can confirm compliance with KYC requirements without sharing personal data with a third party.
In DeFi protocols, in cross-chain bridges, in identity verification systems.
The second use case is scalability. ZK rollups (zk-rollups) allow thousands of transactions to be bundled into a single proof and only that proof is written to the blockchain. Less data on the network means lower fees and higher throughput.
As you can see, Zero-Knowledge technologies are not just “about privacy”. They are a foundation for:
- Ethereum scaling
- digital identity
- next-generation financial systems
- Web3 applications
In practice, without ZK technology, mass blockchain adoption looks extremely difficult and uncertain. This technology, which many perceive purely as a privacy tool, is far more significant for the entire Web3 industry and its related services, products, and infrastructure.
Conclusion
ZK proofs are a way to say, “I know the secret” without revealing it. SNARKs do this compactly and quickly, but require trust in the initial setup process. STARKs remove that requirement and look stronger from a quantum-resistance standpoint, but pay for it with larger proof sizes.
It’s likely that in a few years the question “SNARKs or STARKs” will sound a bit like “SQL or NoSQL”: not “which is better”, but “which is better suited to a specific task”.
For now, these are two different tools aimed at the same goal: giving people control over their data without sacrificing the transparency of the system.






















































