How Zero Knowledge Proofs Can Change Ethereum Blockchain Applications.
Tags: blockchain, news, zeroknowledgeproofs, programming
Published: 2022-03-06 07:55:08

Zero proof knowledge is a protocol that enables one party, called the **prover**, to convince another, the **verifier**, that a statement is true without revealing any information beyond the veracity of the statement.
In other words, one can say that ZKP is the ability to prove honest computations **without revealing inputs**.

The honest computation can be used for **scalability** and **privacy**.

**ZKPs must satisfy three properties**.

1. **Completeness**: If the statement is true,  an honest Verifier will be convinced by an honest prover.

2. **Soundness**: If the statement is false, no cheating prover can convince the honest verifier.

3. **Zero knowledge**: If the statement is true, no verifier learns anything other than the fact that the statement is true.

**Brief History of ZKPs**
 **1985** paper "The knowledge Complexity of interactive prove systems" Shafi Goldwasseer, Silvio Micali and Charles Rackoff.
 First coined the term Zero-Knowledge Proofs for their interactive protocol.
   
Zk-SNARKs highlights the evolution of the most popular ZKP.
-**2011** - first paper to coin the term ZK-SNARKs(Succinct Non-interactive Arguments of Knowledge ) (Bit+11) (by Nir Bitansky and Ran Canneti)
-**2013**- was the first time ZK-Snarks are made applicable for general computing.
  The "Pinocchio" Paper (PHGR13) (by Bryan Pamo and Craig Gentry)....
-**2016**- made Zk-Snarks really efficient and standard that it is still used today. Groth16(by Jen's Groth)

**Non-interactive ZKPs**
--NIZK are a particular type of zero knowledge proofs in which the prover can generate proof without interaction with the verifier.
--NIZK protocols are very suitable for Ethereum Blockchain application, because they allow a smart contract to act as a verifier. This way, anyone can generate a proof and set it as a part of transaction to the smart contract, which can perform some action depending on whether the proof is valid or not.

**The most preferable Non interactive Zero knowledge proof  is ZK-SNARKs proofs**

**Key differences between SNARKS and STARKS **

**For SNARKs**
1. based on elliptic curves and is not quantum resistant and is vulnerable to quantum attacks.
2. requires a **trusted setup** and if the secrets used to create these keys in the trusted set up event are not destroyed, the secrets could be utilized to forge transactions by false verifications.
3.has the most developer libraries, published code, projects, and developers actively working on the technology.
4.Gas fee is far  cheaper for the end-user and proof size is more smaller.

**For STARKS**
1. the  base technology for STARKs relies on **hash functions**  and it makes it quantum resistant.
2. no trusted set-up is required to begin utilizing STARKs in a network.
3. proof size is more large and verification takes time and it requires more gas.
4. lacks developer documentation and community

**How is the trusted setup process different between Groth16 and PLONK? **
 **Groth16** requires a one time trusted setting because it is actually a proving system with circuit-specific common reference string. That means the proof system can only support a fixed circuit in the setup phase for the prover. That means, when the proof system is used in other applications, we must re-run the setup phase with different parameters. We have two phases , and phase 1 is  the powers of tau and the phase 2 which is dependent on the circuit.
**Why** 

**PLONK** utilizes a trusted setup with an updatable reference string. So with PLONK we have an original reference string that can be used to build proofs with any type of circuit. I'm other words, the reference string is UNIVERSAL, and we do not have to recreate a trusted setup for every circuit created. Secondly, there is a way for multiple parties to participate in the trusted setup such that it is secure as long as any one of them is honest. So the more participants, the more secure a secret is.