Zero-Knowledge Proofs in Blockchain: A Developer’s Guide

This concept was introduced in late 1985 to improve user experience and enhance privacy of users hence improving the security of the transactions carried out on-chain on mostly layer-1s. 

What is a Zero-Knowledge Proof?

A Zero-knowledge proof is a mechanism that works on a specific algorithm between two parties where a particular party, the prover, sends proof regarding secret information, and the second party known as the verifier confirms the claims made by the prover without revealing the secret information. 

Gwen and David are to play a game to find a particular dice where there are two blue dice, two red dice and another dice with four color combinations on it.

In this game, both friends are to find the dice with the four color combinations. 

David and Gwen keep searching in a basket until Gwen claims to find the dice with the four color combinations. 

Gwen is asked to prove that she has access to the dice. 

David on the other hand keeps on asking questions to Gwen to confirm that she has access to the proof until the claim is confirmed.

In this case study, David can be identified as the verifier in a zero-Knowledge computation and Gwen is identified as a prover of a claim – “witness”. Irrespective of the use case where zero-knowledge can be applied in the blockchain space, there are two main actors in the process of zero-knowledge proving 

• Prover
• Verifier

The Prover

A prover can be a user, or an identity at one end whose information is supposed to be kept private, and in this process, the user sends out a piece of information/statement for computation to generate a witness.

This is the secret information to the proof and from the knowledge of the prover’s assumed knowledge of the  witness, a random set of questions are generated, answered by the prover, and sent to the verifier. 

The Verifier

This is an identity on the other end of the transaction that confirms the claims made by the prover without revealing the secret information.
The verifier now picks up one of the generated questions and passes it to the prover to answer.

This is the challenge phase in the process of zero-knowledge computation, the prover in return calculates the answer and sends it back to the verifier for confirmation.

This confirmation can be carried out in two formats: in an interactive format and a non-interactive format.
In essence, confirmation of the response is done to make sure the prover has access to the witness. 

Interactive and Non-interactive Zero-Knowledge Proofs

During the process of Zero-knowledge proof, the verifier and the prover run rounds of asking questions and answering to reach a point of higher conviction that the prover has access to the witness.

These questions are generated as an assumption of the prover’s knowledge of the witness and the questions are asked.

This process happens only for interactive zero-knowledge backed-up protocols.
For ZK protocols that work without an interactive process, there is only one round of communication between the verifier and the prover by passing secret information for the algorithm to compute a zero-knowledge proof. 

A Table showing the difference between Non-Interactive ZK-Proofs and Interactive ZK Proofs:

Types of Zero-Knowledge Proofs

Various forms of zero-knowledge mechanisms have been used since its inception and all these have a specific structure that they all support in the enhancement of blockchain development.
This article only outlines three zero-knowledge mechanisms which include: 

• ZK-SNARKS
• ZK-STARKS
• RECURSIVE ZK- SNARKS

ZK-SNARKS

This is a specific mechanism used by various DeFi protocols including, ZKSync, Aztec, and ZKSpace and the mechanism these protocols on which it works can be simply gotten from its acronym “SNARKS”- Succinct Non-interactive ARguments of Knowledge. 

During the process of transactions with protocols using SNARKS, the zero-knowledge proof generated by the algorithm is smaller than the witness hence transactions can be carried out much faster as this backs up the term “succinct” in its acronym bringing a better enhancement for the Layer-1 blockchain Ethereum in terms of scalability and a better user experience.

The ZK-SNARKS maintains a non-interactive method of deriving a proof which is generated in the form of a shared key. This is obtained through multi-party computation to generate public parameters(which make up the shared key).

ZK-STARKS

This is a zero-knowledge proof which completes the acronym, Zero-Knowledge Scalable Transparent ARgument of Knowledge.

 Protocols using this specific type of zero-knowledge for blockchain security enhancement make sure that the main objective for the technology is abided by the term – “Zero-Knowledge” which is the same as that of SNARKS.

• Scalable – The Zk-Starks proof brings enhancement to layer 1 whereby the proof can be smaller than the witness and as well the layer which ZK-STARKS works with makes it possible to expand irrespective of the size of the proof and the witness.
• Transparent: With ZK-STARKs when a shared key is to be generated, there is a publicly verifiable process that takes place.

Recursive ZK-SNARKS

This is a sub-type of the ZK-SNARKS that generates proofs in a parallel format where other SNARK-oriented transactions are compiled and aggregated into one block and recorded into the main blockchain.

Through recursive ZK-SNARKS, more transactions can be stored into one block hence there is less congestion of blocks in the mempool of Layer-1.

Comparison between the different types of Zero-Knowledge proofs

ZK-SNARKS, ZK-STARKS, and recursive ZK-SNARKS have their upends and loopholes which some protocols may decide to adopt one over the other.

In as much as these proofs are relevant to certain use cases such as secure transactions, scalability to a certain degree, and also causing an effect on the throughput on layer-1s.The upends and the loopholes can be filtered and compared based on these:

Security

When using ZK-SNARKS, during the process of generating the shared key to reduce the risk while generating the public parameters, a trusted setup is required where multiple parties participate and each person in the multiple party participation randomly contributes to create the common reference string (CRS).

However with this method, decentralization can be breached as these trusted setup methods can bring a loophole if one of the contributing parties leaks the information used to create the CRS, and with future occurrences, a malicious actor can use these to verify proofs.

This is quite different for ZK-STARKS as no external/trusted setup is required for CRS generation hence decentralization and security are ensured at a 100% cost.

Scalability Proof Size-Witness size ratio

This is a core factor influenced by the proof size ratio to the size of the witness.

Protocols using the ZK-SNARKS work faster when the proof size is quite smaller than the witness size but as proof sizes then increase, scalability lags due to the low data verification overheads but this gives an upper hand for protocols using ZK-STARKS

ZK-STARKS increases linearly with the proof size to witness size ratio and the scalability never becomes a factor. This verification improves the cost of gas when using both platforms for verification.

Maximum Throughput

With various transactions being carried out on layer-1s, unlike ZK-STARKS on SNARKS, transactions can be wrapped into one block and sent in for recording and this lowers cost in terms of gas fees for users as there’ll be no need for spending fees for every computational proof as one block can aggregate these proofs and recorded into one transaction.

Conclusion

The concept of zero-knowledge is a bedrock foundation for the enhancement of user experience, to bring greater adoption of web3, and to improve the blockchain ecosystem.

In this process, ZK-rollups even help to speed up the development and soon the problem of off-chain computation for achieving a greater throughput would be solved entirely Protocols are already in development for this such as Starknet, ZKsync, DyDx, Polygon Miden, and Polygon Hermez. Security and privacy are in their early phase and will achieve their optimum purpose in due time.