Image credit: https://www.bbva.com/en/zero-knowledge-proof-how-to-maintain-privacy-in-a-data-based-world/
Ok starting from this part the concepts might start to get complex based on your level of understanding. I have tried to keep the first two parts simple, I will try as much as possible to keep this one simple.
Before we start, I wrote about Tornado cash in my last article as they have been banned by OFAC. You can also read more about it in this post from our group
Ok now back to ZKP, a ban on Tornado cash is not a ban on creativity and building. Let us keep doing what we should do and build something better and meaner.
Let us begin this part by talking about the types of ZK Proofs that are out there. You will be surprised to know there are so many but the most prominent ones are, SNARK, STARK, Bulletproof, Plonk and HALO.
What is a SNARK - Succinct Non-Interactive ARgument of Knowledge
What is a STARK - Scalable Transparent ARgument of Knowledge
What is a PLONK - Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge
What is a Bulletproof - Bulletproofs are short non-interactive zero-knowledge proofs that do not require a trusted setup.
What is a HALO - A HALO is a ZK SNARK without a trusted setup. HALO is a recursive proof ZK setup.
We went through what a Zero Knowledge means in article1 and article 2
It is time we go a little deep into each of these ZKP’s.
How do we know which proof is more efficient?, this table from matter labs GitHub on ZKP gives us an overview
Another table from Elena Nadolinski which is also a good reference.
Below is a reference from Vitalik’s blog on PLONK. STARK is still faster among all from an overall perspective but SNARK is the smallest in terms of proof size. But SNARK and PLONK have a catch they need a trusted setup.
Source: Vitalik’s blog
Now a final reference table from Vitalik on how HALO fares in comparison to SNARK, STARK and Bulletproof. Please note FRI here refers to STARK, IPA refers to bulletproof and KZG refers to regular SNARK’s. The final one in bold is HALO(enhanced zkSNARK)
Source: Vitalik’s blog
There are three key attributes that we need to look at when choosing a Zero-knowledge proof for our problem.
Is your app good to work with a ZKP that has a trusted setup or do you need a non-trusted setup?
Is your app in need of a faster verification time, are you ok to have a delay in the proof verification (as the computation needed is high and takes a bit of time)?
Do you have any proof size verification limitations?
What is a trusted setup - A trusted setup is an agreement or a rule created and agreed upon between the prover and verifier, it is a one-time setup to generate the private keys needed to validate the proofs that are generated. zkSNARK will use this as the basis to prove the validity of the transactions. Any agreed rule/parameter should be destroyed. Please read the Zcash link provided below, there is a ceremony to do this and avoid the secret being leaked and misused by anyone.
Zcash explains this whole process very well. You can refer to this link zcash. I should also say that they were one of the inspirations for me to pursue ZKP even further.
zkSTARK uses hash function security and as a result, leaner cryptography and does not need a trusted setup, they have a transparent hash function to prove the proof. They are also secure and cannot be broken with quantum computing (to me this is an irrelevant argument as the cost involved is high and there are ways to still tweak the SNARK by other means).
How do we calculate proof verification time? - Unlike SNARK’s STARK’s are not as succinct arguments of knowledge. Their proof sizes are bigger than SNARK’s and this can result in time delays.
Proof size verification - As explained above STARK’s have a bigger proof size. Both SNARK and STARK use polynomials to convert the questions into a circuit which can then be used to generate a proof and verify the circuits. In the case of STARK the proof size is larger and makes it costlier to verify.
On the other hand, PLONK seems to be a better version of a SNARK, it needs a trusted setup but a minimal trusted setup and the cryptography used is not as complex as a SNARK. A PLONK is still slower than a SNARK in terms of proof verification time.
Finally, on the HALO, Zcash has moved from zkSNARK to HALO2 mainly to avoid the trusted setup issue.
So much has been written about STARK, SNARK, PLONK so I will not go into the details here. But let me provide some links for you in case you want to dive deep into it.
Our beloved Vitalik’s blogs on all the four ZKP’s
ZKROLLUP
Finally, let us close this article by highlighting what a ZK rollup is all about and why people are going crazy over it.
In his report “A complete guide to rollups” Jon Charbonneau writes beautifully that any L1 chain makes money from L2 rollups through gas fees and it needs that to survive economically and security-wise. But when L2’s are constrained by themselves the gas fees go up and this becomes unsustainable. See the below picture for a beautiful overview of what it means.
I will quote his words in my own understanding, Ethereum rollup fees are derived from three components,
L1 execution & Settlement
Settlement from Rollups
Data availability from rollups
So what is a rollup?. When the layer2 blockchains post their blocks to a layer1 blockchain and inherit the consensus and data availability from the L1 chain it can be called a rollup. Rollups are nothing but scaling solutions that manage the computation off-chain and thereby reducing the load on the Layer 1 chain.
What actually happens in a ZK rollup is that transactions are bundled in batches and once they are computed off-chain a summary of the changes is submitted to the main layer. The layer 2 chain produces a validity proof to the layer 1 to prove that the changes are correct. This validity proof is the cryptographic assurance that the changes are valid and the main chain can accept them to be added to the block.
There is another called as an optimistic rollup but the main difference and advantage of a ZK rollup over an optimistic rollup are that only a reference to the change that has been made needs to be provided instead of posting all the transactions as an optimistic rollup does. The L1 chain has to maintain all the transactions on the chain but in the case of a ZK rollup that is managed by the layer 2 chain. This helps avoid time delays and waiting time can be much lesser and resulting in faster execution cycles.
There are different types of rollups, What I have shown below is a pictorial representation of smart contact rollups.
Source: Jon Charbonneau
We have many teams trying to provide rollup solutions for Ethereum,
If not a complete list we have a good rollup matrix created by ZKdaily depicting the most prominent ZK projects,
Source: ZKDaily
There any many layer 2 solutions leveraging Zero Knowledge, as you see in the above table. Some of Our Australian Defi community work with StarkNet. We have some awesome layer 3 solutions like TradeFlows (https://www.tradeflows.io) being built on top of StarkNet. I will try to write about TradeFlows and what they do in one of the later articles. Meanwhile here is a reference to the StarkNet project ecosystem.
Source:Astralytica
We have an upcoming meet-up on zkrollups later today in Sydney - so do sign up to learn more.
Meetup link is here to watch in person
Or checkout this link for the online event
I will do a writeup post the event.
Till then happy hashing folks….