Privacy is a lost concept on web2 platforms. There’s virtually no piece of a user’s information that’s not out there somewhere on the internet, without much of a safeguard.
In that regard, blockchain-based decentralized applications (dApps) are often touted by web3 proponents as a means to offer unmatched user data security and privacy. However, blockchain transactions are tied to web3 wallets, which are, at best, pseudonymous.
Today, we have advanced technologies that can run data analysis to easily link off-chain and on-chain identities — thus rendering the blockchain’s pseudonymity ineffective.
Another problem with most blockchains is that they struggle with the scalability trilemma. That is, a blockchain can only maximize on two of its three most important characteristics: scalability, security, and decentralization.
The world’s largest smart contract network Ethereum prioritizes security and decentralization over scalability — but because of this, decentralized applications (dApps) on Ethereum can be slow, deal with high gas prices, and are not ready for mass adoption.
Both of the above problems are major obstacles to mass adoption of web3: users need to have smooth dApp experiences, and they need to have control and security over their data.
Enter zero-knowledge proofs (ZKPs), enabling highly scalable blockchains that do not compromise security or decentralization AND giving users more privacy online.
But what even are zero-knowledge proofs in the first place? Why are they so important? And what use cases do they enable on the blockchain?
In this blog post, we’ll demystify everything you need to know about zero-knowledge proofs (ZKPs). We’ll go over what a zero-knowledge proof is, how it works, what use cases it enables, and how to leverage them in web3.
A zero-knowledge proof (or ZKP) is a technique that allows someone to prove the ownership or validity of a piece of information, without revealing the information itself. Zero-knowledge protocols can simplify privacy and bring trust in systems where two parties do not wish to share private information.
The concept of ZKPs was first introduced in a research paper published in 1985 by mathematicians who wanted to devise a way to prove that a theorem was true without revealing any additional details.
While recent iterations of ZKPs still share the same fundamental logic, they have many applications on the blockchain today — for use cases ranging from identity verification and private transactions to blockchain scalability and data security.
ZCash was the first blockchain to use zero-knowledge proofs in a bid to make blockchain transactions truly private. We have since seen multiple blockchain projects use ZKPs, but before we dive into those use cases, let’s understand how ZKPs work.
The inner working of a zero-knowledge protocol to generate or verify a zk-proof depends on the type of proof we are discussing. And for you to easily understand how those ZKPs work, we will break down the explanation into three parts:
There are two primary participants in a ZKP: a prover and a verifier.
A prover is any person, entity, or software that wishes to prove that they own a certain piece of information or have performed a task they claim to have performed without revealing private details related to that.
A verifier is a person, entity, or software that must verify whether the prover’s claim is true or not without asking for any private information. The verifier may, however, set up multiple challenges for the prover that tend to reduce the chances of the prover getting a false claim verified.
A zero-knowledge protocol must adhere to three key conditions namely completeness, soundness, and zero-knowledge to ensure that the generated ZKP is acceptable.
Completeness in the sense of ZKPs means that a zero-knowledge protocol used by a verifier to challenge the prover’s claim must be able to prove beyond doubt that the claim is actually true.
The condition here is that the verifier must act honestly, i.e. in accordance with the rules of the protocol.
The soundness of a zero-knowledge protocol means that it will only return a true value to the verifier if the claim is actually true. Hence, if a zk-protocol is sound, a cheating prover can never fool an honest verifier into considering a false claim as true.
A verifier in a zero-knowledge protocol must not receive any additional information about a claim apart from whether it is true or false. This also means that the verifier should not be able to reverse engineer the proof to obtain the original information.
While these are the basics of a zk-protocol, how a protocol works depends on the type that we’re discussing.
There exist two fundamental types of ZKPs: interactive ZKPs and non-interaction ZKPs.
Interactive ZKPs are proofs where a verifier must interact with the prover to validate the claims the prover is making.
To do this, the verifier presents the prover with a set of challenges or questions that the prover can only solve or answer correctly if they possess the secret information they claim to own.
The verifier can pose multiple challenges to the prover. And every time a prover returns a true value, the verifier’s confidence in the prover’s honesty increases.
However, a verifier can never validate a claim with 100% certainty, but the possibility of a verifier verifying a false claim reduces significantly with the increasing number of true values returned by the prover.
This type of ZKP is limited in use as it requires participants to regularly interact with each other to validate the proofs.
First introduced in 1988, non-interactive ZKPs replace interactions with cryptographic algorithms built using parameters (a shared key) that the verifier and prover have agreed to use.
The provers in this system feed their information into an algorithm that performs the computation to generate a ZKP. The verifier then takes the ZKP and feeds it into another algorithm that verifies if the proof is correct or not.
This removes the need for provers to communicate with verifiers. However, generating and proving the validity of cryptographic ZKPs is a compute-intensive process and thus highly expensive.
But given the distributed nature of blockchains, where verifiers can be hundreds of nodes, non-interactive ZKPs are still a better alternative than interactive ZKPs.
Currently, there are multiple types of non-interactive ZKPs used across the blockchain ecosystem, each with its own specialties. However, the two main types are: zk-SNARKs and zk-STARKs.
zk-SNARK: Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. Used in zkSync and Polygon zkEVM.
zk-STARK: Zero-Knowledge Scalable Transparent Argument of Knowledge. Used in StarkNet
zk-STARKs are considered more scalable and transparent than zk-SNARKs.
Deploy smart contracts on zkEVMs
ZKPs have a wide range of use cases on the blockchain, but the most important ones include 1) private transactions, 2) blockchain scalability through zkEVM, and 3) decentralized identity and data ownership. Let’s dive into each of these.
Contrary to a somewhat-common belief that blockchain transactions are private, they are not. Blockchain transactions are linked to pseudonymous crypto wallet addresses, which can be traced back to real-world identities.
That is how government authorities have been able to arrest criminals associated with dark net marketplaces like the Silk Road. And catching criminals by tracking their blockchain transactions is legitimate.
The concerning question is, who’s to stop a corrupt government body or a private entity from using information stored on the public ledger to spy on regular crypto users?
ZKPs help users conduct private transactions that only publish the proof of the execution of a transaction. Neither the transaction amount nor the transacting parties are mentioned in the public record.
Here are some companies & projects using ZKPs for private transactions:
The largest smart contract blockchain Ethereum offers a virtual machine setup that computes the state of the network and smart contract computation. And instead of using a centralized server, the Ethereum Virtual Machine (EVM) relies on a distributed network of nodes that individually and independently run these computations.
Keeping both state and contract computation on-chain is crucial for Ethereum to always be certain that all actions and computations were performed within the rules of the EVM.
However, this restricts Ethereum’s ability to scale as every node must perform computations individually and reach a consensus with others.
Zero-knowledge EVMs, which are EVM-compatible virtual machines, propose a mechanism to take computation off-chain. Once a zkEVM process the computations, it creates a ZKP and sends it to Ethereum to prove that the computations happened according to the rules of the EVM.
This means, Ethereum nodes only need to verify a succinct zero-knowledge proof of computation instead of performing the computation itself. As a result, EVM-based applications can enjoy high scalability and faster transactions.💡To learn more about zkEVMs, read our blog What is zkEVM: The Ultimate Ethereum Scaling Solution.
There are also projects that use ZKPs similarly to build scalable blockchains that don’t necessarily depend on or are connected to the Ethereum network.
Some examples of zkEVMs & solutions for blockchain scalability:
Today’s KYC, AML, and other identity verification processes require users to reveal much of their private information to prove their identity. Further, all of this data live on centralized servers of various entities that could be at constant risk of breaches and data thefts.
ZKPs offer a means to create decentralized identities or DIDs stored on a distributed network. Using DIDs would offer users more control over their data and the ability to decide what they want to share with the platforms or organizations they trust.
Also, owners of ZKP-powered DIDs can verify their identity without having to reveal any personally identifiable information.
Some companies using ZKPs for DIDs include Sovrin & Iden3.
Build dApps on ZK-powered networks
Zero-knowledge proofs (or ZKPs) are an essential part of making blockchains scalable without compromising on decentralization or security. Blockchains using ZKPs can perform computation off-chain and publish verifiable ZKPs of the computation on-chain, thus making the network open for high-compute applications.
ZKPs also bring better privacy to blockchain data and are hence used in identity verification, and private financial transactions.
Some blockchains using ZKPs are Polygon zkEVM, zkSync Era, ConsenSys zkEVM, StarkNet, Scroll, and Aleo. While ZKPs enable similar things across these chains, the implementation method of ZKPs varies from one to another.
There are two types of zero-knowledge proofs based on how verifiers verify the information received from the prover: interactive zero-knowledge proofs and non-interactive zero-knowledge proofs.
The latter can be further divided into two main types: zk-SNARKs and zk-STARKs.
Zero-knowledge proofs have become a key technology in enabling privacy-focused internet applications. They are currently also one of the most reliable solutions for scaling blockchain networks. And we’re only just starting to scratch the surface of what’s possible with ZKPs.
The most promising ZK-powered blockchains such as Polygon zkEVM, zkSync Era, and StarkNet have only launched recently. It would be interesting to see the use cases and potential they bring over the next few years.
We hope this blog post has helped you better understand what zero-knowledge proofs are, how they work, and what their use cases are on the blockchain, and how to get started with ZKPs — whether you’re using it for your app, or building on top of an existing blockchain that leverages ZKPs.
If you have any questions, join 33,000+ other builders in our Discord community — or reach out to the team directly for more info on how to build web3 apps using zero-knowledge proofs, or on ZK-powered networks.
And if you want to start building on ZK-powered networks like Polygon zkEVM & zkSync Era, get started with thirdweb’s web3 tools, SDKs, and smart contracts — deployable on any EVM chain.
Source: ThirdWeb