Here is a great example of a multi-billion-dollar problem in Web2 that Web3 can solve.
The status quo is that personal sensitive information such as National Identification Numbers (which are SSNs in the US and NINs in the UK) travels all around various institutions, making the institutions a luring target for hackers. These institutions spend billions of dollars to – at best weakly – protect that data treasure. Once they get hacked, they spend another fortune to mollify their customers, pay regulatory fines and apply marketing bandaids on the large brand-image wounds.
Web3 has a solution to this problem. The idea is to avoid sharing such sensitive information across various institutions, but to to share attestations of your sensitive information, without sharing the information itself using zero-knowledge proofs (ZKPs). Read on to see how that exactly works.
Before we proceed, let’s recall the power of ZKPs. They provide two powers – privacy and succinctness. In our case, we will mainly use the privacy power. Specifically, ZKPs allow us to prove that we know something without revealing it. The idea here will be to prove what the institutions need to know while keeping the sensitive information private.
To describe further, let’s consider a the following example involving banks. For almost every task that involves a bank, one needs to share their National Identification Numbers with the bank. Let’s say, you are trying to obtain a loan from the bank. In the Web2 world, the bank needs your National Identification Numbers to check with the credit bureaus about your creditworthiness. An important aspect to note is that you cannot simply obtain your credit score (a measure of creditworthiness that exists in many other countries) from a credit bureau and create some proof of the receipt. This is because of how Web2, specifically the TLS protocol, is designed; the server does not sign the HTTP response and hence a third party cannot verify the integrity/provenance of the data.
Let’s see how we avoid sharing National Identification Numbers with the bank in the Web3 world.
A special feature of the zkApps platform (which will soon be active) on Mina called \emph{zkOracles}, is designed to solve this very problem. In the running example, the bank would deploy a zkOracles smart contract that can verify the data sent by clients (by verifying ZKPs). The client generates the ZKP as follows.
Recall that the main requirement is that, when a client obtains data from a server, we somehow need to make that data authenticated so that the zkOracle can verify it. To this end, there would be one or more “notaries” who would oversee the communication between the client and the server. However, the notaries would not learn anything about the data exchanged between client and server. (In fact, one may even choose to hide the server identity from the notaries.) The notaries would then sign (i.e., notarize) the transcript. Then, the client can create a ZKP that proves that the encrypted data came from the correct server (by verifying the certificate used in the TLS protocol), some predicate about the encrypted data (in the transcript) and that the encrypted data was notarized.
Reverting to the running example, once the bank deploys the smart contract, a client can obtain her credit score from a credit bureau through an HTTP connection. Then, without revealing the sensitive information the client can prove that she obtained a credit score $x$ from the bureau.
As mentioned above, using zkOracles, one may execute tasks without revealing sensitive information to various entities and thereby counter identity thefts due to large database hacks.
If this interests you, Follow the O(1) Labs blog & Mina Protocol newsletter to not miss any updates.
zkOracles will be available in the coming months as part of the Mina zkApp CLI. You can start familiarizing yourself by reading the zkApps docs for a gentle introduction, and join the discussion in #zkapps-developers on Mina’s Discord!