What Are zk-SNARKs and How Do They Make Privacy on Blockchains Possible?

What Are zk-SNARKs?

zk-SNARKs are cryptographic proofs that let you show that certain information or a computation is correct without revealing privacy-sensitive information. That means a blockchain, for example, can verify that a payment is valid while keeping details like the amount or the recipient hidden. One of the best-known blockchains that uses this technology is Zcash. There, zk-SNARKs are used to verify transactions while keeping details like the amount or the recipient hidden.

The name zk-SNARK is short for zero-knowledge succinct non-interactive argument of knowledge. That sounds complicated, but you can break the parts down pretty easily:

• Zero-knowledge: the proof shows that a statement is true, for example that a transaction is valid, without revealing privacy-sensitive information like the sending address, receiving address, or transaction amount.
• Succinct: the proof is short. That means a node or smart contract can verify it relatively efficiently.
• Non-interactive: after the proof is created, the person making it does not need to go back and forth with the verifier. The proof can be created once and then checked.
• Argument of knowledge: the prover shows that they have the information needed to meet the stated rules, for example the data needed to create a valid transaction. Security here relies on cryptographic assumptions: an attacker with limited computing power cannot realistically create a fake proof that gets accepted as valid. The information used to create the proof is often called the witness. Say you want to prove that you have enough balance for a payment. The witness would include, for example, the data that lets you show you have enough funds and are allowed to spend them. The blockchain does not need to see that data itself, but it can still verify that the matching proof is valid.

Besides the private witness, a zk-SNARK can also include public input. These are pieces of data that are allowed to be visible and that the verifier uses together with the proof to check whether the statement is true.

Important to know: a zk-SNARK is not one fixed protocol, but a general term for different kinds of proof systems with these properties. The exact workings can differ from one system to another. For example, some systems need a trusted setup, while others can work without one.

Key Takeaways

• zk-SNARKs prove that something is true without revealing privacy-sensitive information.
• The private data behind a proof is often called the witness.
• The proofs are short and can be verified relatively efficiently.
• A published proof can be verified without extra contact with the prover.
• zk-SNARKs are a category of proof systems, not one fixed protocol.

How Do zk-SNARKs Work?

With a zk-SNARK, the rules that a transaction or computation has to follow are first turned into checks that a computer can run. That set of checks is called a circuit or constraint system. It spells out exactly what conditions have to be met before something is considered valid.

Take a private payment as an example. The circuit can check, for instance, whether someone has enough balance, whether that balance has not already been spent, and whether they are allowed to use it. The privacy-sensitive data needed for these checks, such as the balance or the data that proves it can be spent, stays hidden from the person verifying the proof.

At a high level, there are three steps:

1. Setup In many classic zk-SNARKs, public parameters are created first. These data are needed to create and verify proofs.

2. Proof generation The prover, meaning the party that wants to prove something, uses the witness and the circuit rules to create a cryptographic proof.

3. Verification The verifier, for example a node or smart contract, checks the proof together with the public input. The verifier does not see the private witness and does not need to rerun the full computation itself.

A good zk-SNARK system tries to guarantee three important properties. First, completeness: if the statement is true and the proof is created correctly, the proof is accepted. Second, soundness: an attacker cannot realistically create a valid proof for a statement that is false. And third, zero-knowledge: the proof does not reveal privacy-sensitive information, except for the fact that the proven statement is true.

Example: Say you need to prove that you are older than 18 without sharing your birth date. In theory, a zk-SNARK can prove that you meet that condition without the verifier seeing your birth date or exact age.

There is an important limit, though. A zk-SNARK only checks the rules that are built into the circuit. If there is a mistake in those rules, a proof can still be technically valid while the system allows something that was not actually intended. Cryptography cannot automatically fix a poorly designed circuit.

What Are zk-SNARKs Used For?

zk-SNARKs are used when someone wants to prove that a computation was done correctly without making all the input or intermediate steps public. That makes the technology interesting for privacy, but also for cases where the verifier does not need to rerun the full computation.

A few well-known uses are:

• private payments;
• applications where input or parts of the computation stay private;
• identity and credential proofs, where you prove a property without sharing all personal data;
• proof-of-reserves, where a party can show that certain reserves exist without making all underlying data public;
• validity rollups, which process many transactions off Ethereum and then post a proof of the correct processing on Ethereum.

Aleo, for example, uses a model where a program is run locally. After that, a zero-knowledge proof is created to show that the execution was correct. Validators then do not need to receive all the private input and intermediate steps, but can verify the proof.

Privacy does not automatically come with anything labeled “ZK.” Which data stays private depends on the protocol and on what the circuit defines as private or public. If certain transaction details are intentionally made public, a zk-SNARK cannot hide them afterward.

How Do zk-SNARKs Support Privacy?

zk-SNARKs support privacy because you can prove that a transaction is valid without revealing its privacy-sensitive details. In a private payment, for example, someone can prove that they have valid funds, are allowed to spend them, and are not double-spending. The sender, recipient, and amount do not have to be public.

Zcash shows well how this kind of design works. It uses a note to privately record a certain amount of ZEC. The blockchain does not store the full contents of that note, but a commitment: a cryptographic commitment to it. You can think of it like a sealed envelope. Everyone can see that the envelope exists, but not what is inside.

The note information is encrypted for the recipient. When a note is spent, a unique nullifier appears on the blockchain. That nullifier does not directly show which note was spent, but nodes can still check whether the same nullifier has been used before. That lets the network prevent double spending without revealing the underlying private data.

So privacy here does not mean there is no trace on the blockchain at all. Commitments and nullifiers remain visible. Also, data like IP addresses, timing, network metadata, and information a user reveals themselves are not automatically hidden by a zk-SNARK.

How Are zk-SNARKs Used for Scalability?

For scalability, zk-SNARKs can be used to summarize a large amount of computation in one compact proof. You can see that, for example, in validity rollups: transactions are processed outside Ethereum, bundled into batches, and then a proof is created that shows the processing was done correctly.

The operator of such a rollup processes the transactions and creates a validity proof that shows the new state was calculated according to the rollup rules. A verifier contract on Ethereum accepts that new state only if the proof is valid. That means Ethereum does not have to rerun all the computations for every single transaction.

With recursion, this can be summarized even further. A new proof can show that multiple earlier proofs are valid. In the end, many separate computations or proofs can be represented by one compact proof.

Scroll uses zk-proofs to show the correct execution of batches of transactions, after which the proof can be checked on Ethereum.

Mina uses recursive zk-SNARKs in a different way. Instead of requiring a participant to verify the full blockchain history from the beginning, the validity of the current blockchain state can be shown with a compact cryptographic proof.

Fast verification does not mean the whole process is cheap. Creating a proof can actually require a lot of computing power and memory. On top of that, a validity proof does not automatically solve other problems, like data availability, censorship by an operator, or risks around bridges between blockchains.

Which Blockchains and Cryptocurrencies Use zk-SNARKs?

Different crypto projects use zk-SNARKs, but often for different goals. So the technology is not only used for private transactions.

• Zcash uses zk-SNARKs for shielded transactions. Within the Orchard protocol, Halo 2 is used to cryptographically prove such transactions.
• Aleo uses zk-SNARKs for private and programmable applications. Programs can be run locally, after which validators check the proof of correct execution without needing to see the private input or intermediate steps.
• Mina uses recursive zk-SNARKs to compactly prove the validity of the blockchain state. The main goal here is compact verification, not automatic transaction privacy.
• Scroll uses zk-SNARKs inside its zkEVM to prove the correct processing of batches of transactions. These proofs can then be checked on Ethereum.
• Ethereum supports verification of certain pairing-based zk-SNARKs through precompiles. That lets smart contracts check zk-SNARK proofs. Ethereum itself does not use zk-SNARKs as a general consensus mechanism.

Note the difference between a zk-SNARK and a zk-STARK. Both are cryptographic proof systems that can support zero-knowledge, but they work differently technically. zk-STARKs usually do not need a trusted setup, but they often produce larger proofs than zk-SNARKs. So a ZK rollup does not necessarily have to use a zk-SNARK.

What Is a Trusted Setup in zk-SNARKs?

A trusted setup is a one-time process in which public parameters are created for some zk-SNARKs that are needed to generate and verify proofs. These parameters are often called a structured reference string (SRS) or common reference string (CRS).

The sensitive part is the secret random information used during such a setup. This is also called toxic waste. If someone keeps that information or can later reconstruct it, then in certain systems, such as Groth16, it could theoretically be abused to create fake proofs that are still accepted as valid.

That is why projects sometimes use a multi-party computation ceremony. Multiple participants each add their own secret randomness. As long as at least one participant acts honestly and actually destroys their secret contribution, the full secret setup information cannot be reconstructed.

That lowers the risk a lot, but it still means you are trusting that at least one participant was not compromised and really deleted their secret contribution.

Not every zk-SNARK needs a trusted setup. Zcash used Groth16 for its older Sprout and Sapling circuits, which did require such a trusted setup. The later Orchard protocol uses Halo 2 and does not need a trusted setup with toxic waste.

What Are the Benefits of zk-SNARKs?

The big advantage of zk-SNARKs is that privacy and verifiability can go together. You can prove that you meet certain rules without making the privacy-sensitive data behind that proof public.

The main benefits at a glance:

• Privacy with verification: sensitive data can stay hidden while nodes can still check whether a transaction or computation is valid.
• Short proofs: the proofs are compact compared with the computation they represent.
• Fast verification: a node or smart contract does not need to rerun the full computation.
• Public verification: a proof can be published and then checked independently.
• Summarizing many computations: with recursive proofs, multiple transactions, batches, or earlier proofs can eventually be summarized into one compact new proof.

On Ethereum, certain pairing-based zk-SNARKs can also be checked in smart contracts. That lets applications, for example, have proofs of offchain computations or privacy-focused checks verified on Ethereum.

One important thing, though: “short” and “efficient” mainly say something about the size of the proof and how it is verified. For the prover, creating such a proof can actually require a lot of computing power and memory.

What Are the Limitations and Risks of zk-SNARKs?

zk-SNARKs are powerful, but they are not a solution for every privacy or scalability problem. Security depends on the cryptography used, the circuit, and how the system is built into a blockchain or application.

One major risk in systems that depend on a trusted setup is the secret setup information. If the toxic waste from, for example, a Groth16 setup falls into the wrong hands, attackers may be able to create fake proofs that are still accepted as valid. In a private payment setup, that could in the worst case lead to balance being created that should not have existed under the normal rules.

On top of that, a zk-SNARK only proves that the circuit rules were followed. Mistakes in the circuit, the prover code, the verifier code, the parameters used, or the connection to a blockchain can therefore have serious consequences. A cryptographically correct proof does not help if the underlying rules were designed incorrectly.

Privacy also has limits. In shielded Zcash transactions, for example, commitments and nullifiers remain visible on the blockchain, while the note information stays encrypted. In addition, public data, timing, IP addresses, and other network metadata can sometimes still reveal information or make links visible.

With zk-rollups, there is another issue. A validity proof can show that a batch was processed correctly, but it does not automatically stop an operator from delaying transactions or censoring users. Risks around bridges and data availability also remain.

Finally, zero-knowledge does not automatically mean a system is resistant to future quantum attacks. That depends on the specific cryptographic construction. Classic pairing-based zk-SNARKs use different cryptographic assumptions than, for example, transparent STARK systems.

Conclusion

zk-SNARKs make it possible to prove that a transaction or computation is correct without revealing the privacy-sensitive data behind it. That makes them interesting for private payments, privacy-focused applications, and scalability through validity rollups. Zcash is one of the best-known examples of a blockchain that uses zk-SNARKs to make shielded transactions possible.

The core idea is pretty simple: a blockchain or other verifier does not need to see all the underlying data or rerun the full computation, as long as it can check a valid cryptographic proof. How much privacy and security that actually provides depends on the system design. In the end, a zk-SNARK is only as trustworthy as the circuit, the cryptography used, and the integration around it.