A Comprehensive Guide to Understanding zk-Snark

In the world where the internet is evolving around Blockchain and Social Media, user privacy has become a major concern due to increased awareness regarding control over personal data. With the passage of a revolutionary regulation in the European Union named General Data Protection Regulation popularly known as GDPR, each online service provider is trying to find ways to comply with the regulation.

Also Read: How to Become GDPR compliant with Private Blockchains  

What is zk-Snark?

One such concept which is popularly applied to achieve user privacy in the world of Blockchain is Zero-Knowledge Succinct Non-Interactive Argument of Knowledge popularly termed as zk-SNARK.

zk-SNARK is a process for construction of proof (secret key for example) wherein one can prove that they are in the possession of something without actually revealing it. Sounds crazy, right? If you are scratching your head right now, don’t worry I did that too when I read about it the first time.

Let’s dig deeper into the part where it says, “proving that they are in possession of something without revealing." So the principle of zk-SNARK’s is summed up in the word “prove." So to prove that we have the possession of the secret, we just need to produce the required cryptographic proof generated from zk-SNARK.

Let’s take an example to see how the principle of zk-SNARK can be applied to prevent user’s privacy. Suppose Alice needs to transfer some funds from her account, so she calls the Bank’s customer center. Let’s see how the conversation plays as of today:

• Customer Representative: “ Hello, I’m Bob, How may I help you today?”
• Alice: “Hello Bob, I need to transfer x amount to the yz account number.”
• Bob: “I’m happy to help you with this Alice. However, first I need you to answer some questions so as to validate that I’m actually speaking with Alice.”
• Alice: “Sure Bob.”
• Bob: “Please tell me your middle name and SSN number?”
  ** Bob asks all the personal information from Alice and crosschecks with the bank records to confirm Alice’s identity.
• Alice  : *Alice provides all the necessary information*

The fundamental problem in the above setup is that she was asked to prove her identity. Alice needs to provide all her personal information to Bob which now lies with the sole discretion of Bob as to how he uses it.

If we see, the need to share personal data arise because one needs to validate their identity. So what if we deduce some other way wherein we do not need to share our personal information, instead we share some cryptographic proof of our information.

Let’s consider the below example and analyze how we can validate the identity of Alice without having to ask for her personal information.

There are four key actors in our example:

• Alice: The prover.
• Bank: The verifier.
• Bob: Bank’s Customer Service Representative.
• Digital Identity Information Data Provider.

In this case, The Bank and The Digital Identity Information Data Provider will be the trusted third party setup required to setup and verification of zk-SNARK program.

Let us assume that Alice has already registered with the Digital Identity Information Data Provider which stores all the private information of Alice in a cryptographic form and, in return, the application generates a secret key (PIN) and provides it back to Alice.

• Alice opens the bank application and navigates to contact us section.
• Instead of directly connecting the call to a Customer Representative (Bob), to establish the identity of Alice and to validate Alice’s claim, she is redirected to Digital Identity Information Data Provider, wherein she’s asked to enter her SSN, DOB, etc., and finally while submitting the information she’s asked to enter the PIN which she received during registration. The application then matches the information with the cryptographic proof and if it is correct, it sends the response to the bank, validating Alice’s identity.
• After getting a positive response to Alice’s identity the call is connected to Bob.

So if you see the above scenario, there was no exchange of personal information between Alice and Bob yet the identity of Alice was proven without any sensitive information being passed to Bob.

The above example just presents the overview, typically a use case where zk-SNARK’s can be applied. For practical information, the trusted setup parties would be created over a Blockchain based network so as to incur transparency.

The concept described in this blog will allow the user to have a full control over their data and minimize data leakage without hindering the smooth transaction process that is already in place.

A key area where zk-SNARK can still be improved is by removing the need of a third party required for generating Zero Knowledge Proof. There is still a lot of research going on in zero-knowledge cryptography and once such concept that has come out is zk-STARKS.

In the next blog, we will dig into the technical aspects of zk-SNARK. We’ll see what properties a zk-SNARK proof constitutes and we’ll also see the process involved in the generation of zk-SNARK proof.