Zk-Snarks are the new advent in the world of blockchain, especially having been catered to by leading cryptocurrencies of late. The name, acronym to the full version i.e: “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge” is hardly self describing and it is no wonder that we see hesitancy in its adoption by newer, more niche crypto platforms. In this part, however, we will only discuss what the zk-snark proof is and how it functions, regardless to its application in blockchain and cryptocurrencies, which will be briefed about in the corresponding part.
So, lets dig straight into the idea of zero knowledge proofs with a bit of a historical perspective on it. Zero knowledge proofs came about in the 1980s with the work of MIT professors Shafi Goldwasser, Silvio Micali and Charles Rackoff. Their theorem was based on two identities, a prover and a verifier. The mainframe of zk working is based on the proofer convincing the verifier that they have knowledge of a certain proof, without actually declaring what the knowledge is.
How does this work?
It works on the basis of flipping the questions we ask in the current scenario. For example, we question the credibility of the prover trying to prove something and we never ask whether the verifier is the right entity to have the power to verify. So the question zk asks is to how the verifier is credible enough to know some knowledge while also keeping it safe. This can be explained better with the following example:
Suppose you want to login to a website or one of your social accounts by using a password. You will most probably write this password in the required field and send it to the server. The server will subsequently have a stored hash of the password you set in the beginning and it will compare the one you just entered to that hash stored in the system. If the values match up, you will be able to enter the system.
But what flaws are inherent in this system of work?
It is apparent. The safety of all your data on the website is at the mercy of the server, which is the verifier in the zk scenario. If this verifier gets compromised to an attack or any sort of phishing activity, the consequences would be radical. This is where zk proofs become integral and they break this flaw in every sense.
For zero knowledge proofs to work, three different parameters should be met.
- Completeness: An honest verifier can be convinced of a statement that is true by an honest prover.
- Soundness: If the prover is dishonest, they can’t convince the verifier of the soundness of the statement.
- Zero-Knowledge: If the statement is true, even then, the verifier will have no knowledge of the actual statement.
This is explained in an intuitive example as following.
The prover (P) is telling the verifier (V) that it knows the password to the door at the end and it wants to prove it to V without telling them the actual password.
As in the figure, P is going down path B, but it could just have been the other path had it not been plain luck. So what if the prover took path A while the verifier came in later and asked to show path B? This tests the validity of this theorem and the test is done multiple times. If the prover can appear at the correct path every single time, it proves the verifier that the prover verily knows the password, even though the verifier doesn’t know it themselves.
So, the three parameters are fulfilled in this example as:
- Completeness: The honest prover convinced the honest verifier as the statement was true.
- Soundness: The test was done multiple times, so the prover’s luck couldn’t save him all these times to fool the verifier.
- Zero-Knowledge: The verifier approved of the method the prover took to prove the password, while not knowing the actual password at any point during the verification.
This explains (hopefully) the functionality and the need for zero knowledge proof protocol. In the next part, we will look at its use in blockchain and how it affects cryptography mechanisms behind several tokens implementing it, most notably with Zcash and now with Ethereum also implementing a version of its own.