*Note: unless you have familiarity with zero-knowledge proofs or ZK-SNARKs, I would suggest reading **Part 1** and **Part 2 **of this blog series.*

Now that we covered ZK-SNARKs, let’s expand into some of the issues with ZK-SNARKs, and discuss recent innovations in zero-knowledge cryptography: ZK-STARKs (Zero-Knowledge Scalable Transparent ARguments of Knowledge).

ZK-SNARKs have a few underlying issues that will lead to reduced adoption for leveraging zero-knowledge cryptography in blockchains and other potential implementations as well:

- The trusted setup phase can be compromised (there is an underlying assumption that when using a ZK-SNARK system, the trusted setup phase is secure)
- Scalability of ZK-SNARKs can be improved, as run-time increases, the time needed to generate and especially verify proofs needs to be improved
- ZK-SNARK cryptography is vulnerable to attacks from quantum computers

Let’s breakdown each of the above issues and compare to the up and coming ZK-STARKs.

**Trusted Setup Phase**

What if a government or powerful entity tried to incentivize parties involved with the setup of the ZK-SNARK system to share the setup parameters? If that powerful entity was successful, they would be able to generate false proofs in a system widely known to be trusted. If for example, a Presidential vote for a country took place on a blockchain that was using ZK-SNARKs for proving votes, there could be significant incentives for the entity to discover the setup parameters and thus change the outcome of the election. The entity could tilt the election in their intended direction by creating false proofs for votes taking place.

The biggest problem with the ZK-SNARK approach is that users need to implicitly trust in the setup phase and the parties involved to setup the system honestly. Users of the system will never actually know if the setup phase was compromised at the point of setup, or at some point in the future. So, if this is the case, the door remains open for a system where users do not implicitly need to trust the parties involved in the system’s setup to be honest. When a system is used where the incentives are high to circumvent the system, there will be those who will look to find a way to circumvent it.

In ZK-STARKs, there is no external trusted setup phase and the randomness used is public information. Public randomness utilization is exceptionally important for the public to trust zero-knowledge proof systems, otherwise a powerful entity could exert their influence to obtain the setup parameters and generate false proofs. Given there is no third party trusted setup phase and publicly verifiable randomness is used instead, ZK-STARK systems create verifiable trust.

**Scalability**

For those who pay attention to ongoing technical challenges in the blockchain space, the scalability discussion is center stage. Although outside the scope of this blog post, there are numerous ways to scale blockchains, all with their associated tradeoffs. For ZK (zero-knowledge) proof systems, scalability of the system is paramount to achieving widespread and sustained adoption. ZK-STARKs exhibit much higher scalability than ZK-SNARKs. Let’s breakdown the associated complexity of the ZK-STARK vs. the ZK-SNARK calculations into four different categories relative to scalability (results leveraged from ZK-STARK whitepaper):

1. Arithmetic circuit complexity (an arithmetic circuit is a standard way to compute polynomials where addition and multiplication can be computed): In ZK-SNARK and ZK-STARK systems, the code to create ZK programs are written in such a way for them to be broken down into circuits, and then computed — effectively the simplicity of the circuits complexity is relative to its computational efficiency. In the below chart illustrations, the arithmetic complexity basically equates to the size and intricacy of the underlying computation used to generate the proof. (*Complexity charts below are based on overall complexity of system with primary focus on multiplication gates; for parameter setup, see page 11 of **ZK-STARK whitepaper**.)*

2. Communication complexity (typically defined as the amount of communication needed to solve a problem distributed among two of more parties): As the size of the computation grows, so does the communication complexity of the ZK-SNARK in a linear fashion, as opposed to the ZK-STARK which grows only slightly as computation size grows — a large advantage of ZK-STARKs vs. ZK-SNARKs when it comes to the one-time setup. After the setup phase, SNARKs currently have less communication complexity than STARKs when verifying proofs.

3. Prover complexity: ZK-STARKs are ~10x faster than ZK-SNARKs as computation size increases, another advantage of ZK-STARKs vs. ZK-SNARKs.

4. Verifier complexity: As computation size grows, ZK-STARKs grow only slightly vs. ZK-SNARKS, which tend to grow in a linear fashion, a significant advantage of ZK-STARKs vs. ZK-SNARKs when it comes to the one-time setup.After the setup phase, SNARKs currently need less time to verify proofs than STARKs, e.g. STARKs may take 50–100ms to verify, while SNARKs need ~10ms to verify.

The below is a simpler view of a benchmarking analysis completed between ZK-STARKS vs. ZK-SNARKs in the ZK-STARK whitepaper.

*Charts Data Source: **ZK-STARK white paper**; Note charts are reproduced from whitepaper — they are simplified for comparison of a ZK-SNARK to a ZK-STARK.*

In proof systems, there is a statement that the prover wants to assert as true to anyone who would like to verify the statement. For example:

Prover statement: Alice wants to prove she is the owner of a bank account with Acme Bank.

Effectively, when you slice up the above statement (statement broken up in code logic in post #2) above into pieces for the zero-knowledge circuit to calculate and then generate a proof, the verifier mathematically checks the proof for correctness along with the associated verifier key. This process (especially the verification process) has been substantially sped up by using a newer algorithm called the Fast Reed-Solomon Interactive Oracle Proof of Proximity. For more detail on the new algorithm utilized to increase the scalability of the ZK-STARK, I suggest reading Vitalik Buterin blog posts for an in-depth breakdown.

- STARKs, Part I: Proofs with Polynomials
- STARKs, Part II: Thank Goodness It’s FRI-day
- STARKs, Part 3: Into the Weeds

**Quantum Computing**

More recently, quantum computing has become a topic of interest, and to some degree in the blockchain world too (Qubit Protocol is an interesting blockchain start-up). IBM and Intel are both working on developing quantum computers however, current estimates point to quantum computing being years away from wide-spread adoption. Quantum computing does pose a risk to blockchain systems. Let’s dig into why quantum computers pose a risk to some aspects of blockchain cryptography.

Classical computers (the computers we utilize today) operate with bits, which store one of two states, 0 or 1. Quantum computers operate with qubits, ( similar to bits) which store state in either 0 or 1 however, through a principle called superposition also exist simultaneously between 0 and 1 when not being measured (an example of a qubit can be a photon, nucleus, or an electron). Due to the unique properties of qubits, they can be leveraged to do some interesting things that cannot be achieved with classical computers and bits.

Quantum computers will be designed to describe all correlations between qubits, i.e. effectively exponentially increasing computational throughput by 2^n (n = correlation per qubit in each system) for specific operations. For example, 2 qubits = 4 classical bits, 3 qubits = 8 bits, and 20 qubits = 1,048,576 bits. Considering quantum computers can process data in parallel vs. in serial (like classical computers) for specific operations, they can significantly speed up certain computations, such as database searches or finding the private key from a public key.

**Implications of Quantum Computing for Blockchains**

Quantum computers are not good at everything, only specific types of calculations that specific algorithms could exploit. For example, there is an algorithm called Shor’s algorithm that can be run on a quantum computer and will have the capability to run very fast integer factorization calculations in parallel (integer factorization is a process to decompose a composite number into the product of small integers, which can be used to find a private key from a public key; a private key and public key are basically very large numbers), thereby finding the prime factors of any given integer.

Many of today’s current encryption schemes will not be resistant to quantum computing attacks, such as RSA and ECDSA (Elliptic Curve Cryptography).Bitcoin and Ethereum use ECDSA for generation of private keys and public keys. For example, below is a basic depiction of the process that Bitcoin uses to generate the private key, public key, and public address.

The private key is generated from a number with an added level of entropy (randomness), the public key is generated from the private key, and the public address is generated from the hash of the public key. Quantum computers could utilize Shor’s algorithm to derive the private key from the public key, and then leverage the private key to forge transactions or steal a user’s balance (Bitcoin/Ethereum).

Shor’s algorithm is primarily an issue for re-used addresses. For addresses that have not been used, quantum computers could leverage Grover’salgorithms to solve for SHA-256 or SHA3–256 to find the public key from the public key hash, however quantum computers would only be able to find the public key in half the time vs. classical computers of today. Even at half the time, the key would not be found within anyone’s lifetime currently on Earth. Additionally, merkle-tree hashing is not currently susceptible to quantum computing attacks.

There are currently algorithms being developed that will be difficult to break with quantum computers, such as Lattice-based cryptography or multivariate cryptography, which may be candidates for replacement of ECDSA in the future for blockchains such as Bitcoin and Ethereum.

ZK-STARKS do not rely on private-public key pairings (such as ECDSA), but rely on collision resistant hashing for interactive solutions (which Grover’s algorithm does not meaningfully break), and a random oracle model (a model that is typically used instead of general cryptographic hash functions where strong randomness assumptions are required for the oracle output) for non-interactive proofs (zk-nSTARK, n = non-interactive), therefore ZK-STARKs are currently resistant to quantum computer attacks.

Quantum computers are still years away (estimates point to 2026–2035), so there is little need to worry about their capabilities today. Also, I utilize the term quantum resistance in this post as quantum resistance and quantum proof are two terms to reflect on. Like a watch that is resistant to water to a certain depth, and a watch that is impervious to water (water proof), until the true capabilities of quantum computers are known, it is hard to say if an algorithm may be found that leverages quantum computers to circumvent current potential quantum resistant encryption algorithms today. Hence, we may not see changes to encryption algorithms used in Bitcoin or Ethereum until mainstream quantum computing is closer to becoming a reality.

An additional video that can be helpful l in understanding the difference between classical computers and quantum computers: https://www.youtube.com/watch?v=JhHMJCUmq28

**Current State and Final Thoughts**

Currently, ZK-SNARKs are available in the cryptocurrency Zcash, as well as the library libSNARK to build ZK-SNARK programs that can be leveraged in blockchains. ZK-STARKs are a newer technology, and not deployed in production capacity as of 6/2018. There is a new company called StarkWare Industries that is looking to solve some of the challenges with leveraging ZK-STARKs (one being the size of the proof) and also commercialize the technology, which can be leveraged across multiple industries, including blockchain implementations.

ZK-STARKs are scalable, transparent, have universal application, and currently quantum resistant. This allows for the creation of trust in the technology, as it is verifiable. There are many areas that can be enhanced by using a technology such as ZK-STARKs where trust is required and there are large incentives to cheat, such as:

- Voting systems
- Running a computation and verifying its results, such as a blockchain’s past transactions
- Secure verification of information, such as for proving identity or credentials

My current thinking is we will see Zcash adopt ZK-nSTARKs (n standing for non-interactive) technology into its blockchain in the future. Additionally, Ethereum may leverage ZK-STARKS in verifiable computation and potentially secure/anonymous transactions, as well as Dapps where privacy is important such as Brave’s web browser that leverages the Basic Attention Token.

ZK-STARKs is an exciting technology that will enable trust to be achieved in computing systems that has not been achieved previously, as the trust created is verifiable and public. This idea is especially important, as entities that have significant incentives to falsify information will not be able to do so when using a ZK-STARK proof system. It will take time for this type of technology to be adopted however, the benefits will be significant and create something truly unique: verifiable trust in a system where there could be very high incentives to try and falsify information processed by the system.

Please let me know if you have any questions or have thoughts on the above below, look forward to discussing!

]]>Welcome back! Let’s dig deeper into zk-SNARKs.

Note: unless you have familiarity with zk-SNARKs, I would suggest reading Part 1 of this blog series.

*Quick recap: There are two primary parties in a zk-SNARK, a prover and a verifier. Using a zk-SNARK a prover wants to assure a verifier about a statement of knowledge, without revealing what that exact knowledge is to the verifier.*

**What is a zk-SNARK?**

Prior to walking through a more technical example, let’s walk through what properties a zk-SNARK must satisfy first:

**Completeness**: if the statement is true, and the verifier and prover are honest, the proof is accepted.**Soundness**: if the statement is false, a cheating prover cannot convince an honest verifier that it is true, except with some tiny probability.

In addition to the above, a zk-SNARK (zero-knowledge Succinct Non-Interactive ARgument of Knowledge) needs to be:

**Zero-knowledge:**if the statement is true, a verifier does not learn anything beyond the fact that the statement is true.**Succinct**: The size of the proof needs to be small enough to be verified in a few milliseconds.**Non-Interactive**: Only one set of information is sent to the verifier for verification, therefore there is no back and forth communication between the prover and verifier.**ARgument**: A computationally sound proof: soundness holds against a prover that leverages polynomial-time, i.e. bounded computation.**of Knowledge**: The proof cannot be constructed without access to the witness (the private input needed to prove the statement).

Given the above conditions, let’s walk through an example of a zk-SNARK and also incorporate how it would be used in combination with a blockchain. Using the first example between Bob and Alice in post #1: Alice wants to transfer money from one of her bank accounts to another and needs Bob to initiate the transfer — let’s describe how that scenario can be implemented using zk-SNARKs and a blockchain.

*Note: The below example is not scalable, but provides a good overview of how a zk-SNARK can be approached.*

Four actors in our scenario:

1.

Alice – Prover

2.

3.

4.

**1. Create a smart-contract enabled blockchain, for this example let’s use an Ethereum instance.**

**2. A program is created that returns a ‘1’ if the program evaluates to true (program example at end of blog post).**

2a**.** The inputs include public inputs that are used by multiple parties (Alice, (Self-Sovereign Identity Solution), and Acme Bank), and private inputs (the secrets, aka witness) that only the prover (Alice) provides.

2a_i. Public: Name, Phone Number, Blockchain Digital Identity Address, Bank attestation of Alice being a current bank account owner — completed recently; timeout of 1 hour (to be described further below)

2a_ii. Private (Alice or Self-Sovereign Identity Solution): Social Security Number (SSN), Date of Birth (DOB)

2a_iii. Private (Alice only): Secret Pin

b. Setup the zk-SNARK parameters and generate prover and verifier keys.

2b. Use multi-party computation (MPC) between Self-Sovereign Identity Solutionand Acme Bank to generate the public parameters to setup the zk-SNARK. MPC allows for multiple parties to participate in the trusted setup phase to generate the parameters for the zk-SNARK — this minimizes risk vs. one party creating the keys. If one of the users who participates in the trusted setup phase is not compromised, the parameters generated are secure. If all of the users who participated in the setup are compromised, the parameters can be used to generate false proofs, and thus eliminates the value of the zk-SNARK process.

2c. Verifier keys and the verifier program are embedded in a smart contract that is instantiated in the Ethereum blockchain instance.

**3. Alice open up Acme bank’s app, uses her fingerprint to authenticate her identity to the app, and then enters the app.**

3a. She goes to the ‘Contact Us’ area in the app and taps on the ‘Call Acme with Prior Authentication’ button.

3a_i. After Alice taps on the ‘Call Acme with Prior Authentication’ button, behind the scenes: 1) A request is sent from Alice’s Acme bank app to Acme Bank asking if Alice is still a bank customer. 2) Acme Bank then sends a transaction to the blockchain stating that Alice is still a current customer.

3a_ii. Alice is asked the following questions in the mobile app (some of these questions (social security number and date of birth) can be answered via a digital identity application providing the data to the Bank app, like Self-Sovereign Identity Solution):

3a_ii_1. What is your social security number? Alice enters: 123–45–6789

3a_ii_2. What is your date of birth? Alice enters: 1/1/2000

3a_ii_3. What is your secret pin? Alice enters: 7327; Why a secret pin? This is in case someone gains access to the app somehow and utilizes the digital identity application to populate the answers for the social security number and the date of birth, and then tries to interact with the Bank as Alice while not actually being Alice. The secret pin acts as a last hurdle that cannot be known by an outsider to validate one’s identity.

**4. Alice’s answers (private inputs aka witness) are merged with the public inputs of Alice’s name, phone number, public digital identity address, and bank’s attestation that Alice is a current customer to generate a zero-knowledge proof (zk-SNARK).**

4a. The proof is sent to the verification smart contract in the blockchain.

**5. The smart contract returns ‘true’, which Acme Bank is monitoring and logs the response of ‘true’ in their own internal system.**

**6. A button in Acme’s mobile app is now available for Alice to call Acme Bank. Alice taps on the button, and then is transferred to an Acme Bank call representative, Bob to initiate the bank transfer.**

The above example provides a breakdown of how a zk-SNARK could work when Alice wants to call Acme Bank to initiate a transfer from one of her accounts to another. The above example eliminates Alice sharing sensitive identity information with Bob, and additionally reduces average handle time for Acme bank, thus reducing costs — a win-win for both Alice and Acme Bank.

**Third Party Trust and Proof of Current Customer**

One key element in the above example of a zk-SNARK working in the real world is the bank attestation that Alice has an account with Acme Bank. This is a key element that is often overlooked when providing examples for zk-SNARKs — when there is a third party that needs to be involved with a zk-SNARK process, how is that incorporated? There can be different approaches, however we can incorporate a form of proof of existence, that we will call Proof of Current Customer that allows the above example to become a more realistic implementation.

A Proof of Current Customer could work in the following way for Acme bank:

- When Alice first becomes a customer or is already a customer, the bank would make an attestation that Alice is a customer of the bank by sending a transaction to Alice’s public digital identity address in the relevant blockchain. (The transaction would contain an encrypted data payload that Alice’s Acme Bank mobile app would read to indicate that Alice is a customer of Acme Bank.)
- The issuer identity (Acme Bank) would be validated by checking Acme’s public address. In the blockchain, there would be a public-address registry in a smart contract (the registry would store the public addresses and their associated identities), thus Acme Bank could be identified as the issuer of the original attestation. The registry could only be updated by certain selected owners, or the creator of the contract registry.
- Next, a new transaction is sent from Acme Bank to Alice’s public digital identity address with an encrypted data payload that Alice is a customer of Acme Bank, and she can call Acme Bank without prior authentication for the next 60 minutes.

*Note: There are multiple ways to approach the above. For example, instead of using simple transactions, we could also utilize a document stored in a decentralized storage system that holds the relevant data, which can then be used to verify the underlying customer data and digital signature of Acme Bank.*

In the above example, Alice was able to communicate with Bob at Acme Bank without sharing information about herself and authorize the transfer of money from one of her bank accounts to another. zk-SNARKs and blockchains can work really well together: bridging privacy, security, and transparency to exchange and verify information.

In addition to the above scenario, zk-SNARKs can be used in a wide array of areas, for example:

1. Verification of computation (centralized, decentralized)

2. Anonymous cryptocurrencies or cryptocurrencies that can enable use of zk-SNARKs in smart contracts, example: Zcash, Ethereum (protects user privacy)

3. Proof of provenance between public/private blockchains (a. Instead of recording all data of a transaction that occurs in a private blockchain onto a public blockchain, a proof can be stored on a public blockchain. This enables companies to keep their sensitive data secure, while proving provenance of a specific transaction.)

4. Authentication without passwords (as shown above in Alice and Bob example)

5. Sharing information about one’s identity conditionally, for example: Alice is > 21 is true or false? (Age is not revealed), a zk-SNARK can be used to prove that Alice is over 21 while minimizing the trust needed between parties involved (ex: a. Sharing of PII, Health Data, Loan data)

Wider utilization of zk-SNARKs may change how data is stored. Perhaps companies may not need to keep as much data about their customers/users as they currently do. In the future, organizations could interact with blockchains and use zero-knowledge proofs to communicate with current processes, thus alleviating data leaks, further increasing privacy of user data, and reducing risk for organizations. Sharing of confidential data between people can also be further reduced. The applications of zero-knowledge proofs and self-sovereign identity will allow users to more fully protect their data, and further minimize data leakage as organization that own important aspects of one’s identity data will start to decline.

A key area that can be further improved to minimize trust for users of the zk-SNARK is removal of the trusted setup phase. There is ongoing research in zero-knowledge cryptography, with technologies such as zk-STARKS being developed that remove the trusted setup phase, further improving the process of using zero-knowledge cryptography to provide proof of knowledge. In the next post, I will dig into zk-STARKs.

I hope everyone enjoyed reading more about zk-SNARKs. If you have any questions about this post or the previous post in this series, please feel free to reach out to me directly: aluciano@cynapseblockchain.com.

**Deeper Dive of Alice and Bob Call with Prior Authentication Example — zk-SNARK program inputs and outputs only (example used ****ZoKrates****):**

For those of you who would be interested in what a basic zk-SNARK program looks like, I wanted to provide the following example based on the Alice and Bob example above.

- zk-SNARKs work well with numbers, so we would need to convert the string inputs to numbers (used following website to convert the text strings:
*https://cryptii.com/decimal-text*). - Public Name: Alice; Run through a Unicode decimal converter to attain: 65 108 105 99 101, remove all spaces and input:
**6510810599101** - Public Phone Number: (555–666–7777); Run through a Unicode decimal converter to attain: 53 53 53 45 54 54 54 45 55 55 55 55, remove all spaces and input:
**535353455454544555555555** - Public Blockchain Address: 0x4ef377462b03b750d52140c482394a6703d0d338; Run through a Unicode decimal converter to attain: 0 48 120 52 101 102 51 55 55 52 54 50 98 48 51 98 55 53 48 100 53 50 49 52 48 99 52 56 50 51 57 52 97 54 55 48 51 100 48 100 51 51 56, remove all spaces and input:
**0481205210110251555552545098485198555348100535049524899525650515752975455485110048100515156** - Public Bank Attestation Setup and Call:
**a.**Initial Setup: Acme Bank sends a transaction to Alice’s public digital identity address with a data payload indicating that Alice is a customer. This transaction would occur when Alice opens the account, or when Alice authenticates her account on Acme Bank’s mobile app for the first time.**b.**When Alice kicks-off the ‘Call with prior Authentication’ process, the bank would check Alice’s public digital identity account transactions for a transaction from Acme Bank indicating that Alice was a customer of Acme Bank. If found, Acme bank would then send a transaction to Alice’s public digital identity address with an encrypted data payload that indicates that Alice is a current customer of Acme bank. Alice’s phone would watch the blockchain for the new transaction from Acme Bank, and once found, would pull the data payload from the recent transaction, decrypt the data, and hash the data. The hashed data would then be turned into Unicode decimal string for input:**49665667686866675454525052495348527066485368517055505368654852505556654849686554556654525655526953566669697056526565555753665670** - Private Social Security Number: 123–45–6789; entered as for input:
**123456789** - Private Date of Birth:1/1/2000; entered as for input:
**112000** - Private Secret Pin input (this is a secret pin that the user must remember):
**7327** - The public and private inputs will be put into the below program, which will compare the public inputs with what is written in the zk-SNARK program. If they are correct, the program would then multiply the sum of the social security number and date of birth by the secret pin to generate the target number. If that number is the same as what is in the zk-SNARK program (905388517003), the program would return a 1. The code below written in ZoKrates provides an example:

10. After the program executes, a proof is generated that looks like the image below:

11. The above proof is then sent to the verification smart contract along with the public inputs (Alice’s name, phone number, blockchain address, bank attestation hash, and expected output ‘1’). If all of the information is current, the contract would return ‘true’, with the output stored in the smart contract, so a watcher of the contract can see the results (Alice’s mobile app and Acme Bank can see the state change within the contract). The verification contract has the verification key hardcoded inside it, so it can determine from the pubic inputs and the provided proof if the proof evaluates to true.

]]>Our personal data (date of birth, social security number, education credentials, work histories, etc.) helps create a picture of who we are, our identity. In the wake of Facebook’s data being mined [1] by Cambridge Analytica and Equifax’s massive data breach [2] (a company that holds our most personal data, including web usage statistics, financial information as well as medical data), I think there is much to be improved in how our data is handled by any such organization. The concept of a self-sovereign identity [3], where organizations will no longer own or even keep our data is right around the corner. We as the individuals that worked to establish all these important components of our identity will own and manage it. The idea of self-sovereign identity will be discussed in more detail in a future blog post, however there are still ways to fight for our right to privacy even if some of our data has been exposed to hackers and marketers, especially around data that creates our identity.

Protection of data related to the identity of individuals is vitally important and will continuously increase in importance as we share more of our data electronically. Data can primarily be compromised in two ways: when at rest (example: on your hard drive, or in your wallet), or when in motion (example: sending data via an email or pulling out your driver’s license in a crowded restaurant). I would argue that data in motion (sharing with a third party) is riskier than data at rest, as data in motion is available to prying eyes (or snooping algorithms). For example, if my driver’s license is in my wallet, there is much less of a chance that my date of birth will be seen by an unsavory character as opposed to when I remove it from my wallet.

The data that we constantly create about ourselves is up for grabs, however recent innovations in cryptography and blockchains enable a system to be created that can help protect our data and identity, even from organizations that we interact with. How do you really know if you can trust the organizations that you interact with? Two obvious weak links in the chain of trust are the very people we interact with at said organizations, and their unsecured IT systems. These weak links are universal across organizations that we rely on for various products and services, such as our electric company, or internet provider. These weak links could lead to our data being compromised, as there are multiple individuals, organizations and state actors that seek and pay for such breached data. Enter a method called Zero-Knowledge Proofs[4].

Zero Knowledge Proofs enable a way to share validated data with a third party without actually sharing the data itself. This is a fascinating concept, as intuitively it takes a little time to wrap one’s mind around the fact that you can share sensitive information without actually sharing sensitive information. Zero-knowledge proofs work in the following way: If I would like to prove something to someone (let’s say Person A), I generally would need to have a piece of evidence that backs up my claim to Person A, who is trying to verify my claim. Zero-knowledge proofs create an irrefutable way to prove that I have evidence to back up my claim, by sharing a proof instead of the evidence with a verifier that can be used to validate my claim. Using a zero-knowledge proof, I do not actually need to share any information/data, but a cryptographic proof (that does not leak any data) to prove my claim to Person A. Zero-Knowledge Proofs effectively provide a riskless way to share data (assuming we trust the process of setup that creates the proof, more on that later).

There are countless ways that we can use Zero-Knowledge Proofs in the future to protect our data. One way that has not been widely discussed in realistic terms and that solves two big problems is calling into call centers. Suppose Alice needs to call her bank to initiate a transfer from one of her bank accounts to another bank account. Wouldn’t it be great if when Alice called the bank, instead of going through a process of answering questions about herself to verify her identity (account number, social security number, address, mother’s maiden name), Alice could send a cryptographic proof from her mobile phone to the bank that automatically authenticates her identity? That would save time, and increase privacy… Let’s look at how the call would go in this example after Alice authenticates her identity on the phone:

**Example: Bob responds to Alice after Alice authenticates her identity via the current process. (Average time to address the issue Alice called about — 30–60 seconds)**

Bob (Call Representative)

“Good Morning, my name is Bob. Can you please provide me with your full name?”

Alice

“Alice Smith”

Bob (Call Representative)

“Thank you. Can you please provide me with your current address?”

Alice

“12345 Main Street Springfield MA 99999”

Bob (Call Representative)

“Thank you so much for the information. Can you please provide me with the last 4 digits of your social security number?”

Alice

“Sure, 6789”

Bob (Call Representative)

“Thank you so much. Can you please provide me with the amount of your last transaction on your checking account?”

Alice

“I don’t remember”

Bob (Call Representative)

“Thank you so much for your patience. I am really sorry, but we really need this information in order to proceed.

Alice

“let me check…. $123”

Bob (Call Representative)

“Sure, I will start the process immediately. Is there anything else that I can help you with?”

Alice

“No, that is it. Thank you!”

**Example: Bob responds to Alice after Alice authenticates her identity via her mobile phone using a Zero-Knowledge Proof Approach for smart contract enabled blockchains. (Average time to address the issue Alice called about — 5–10 seconds.)**

Bob (Call Representative)

“Good Morning Alice, my name is Bob. How can I help you?”

Alice

“Can you transfer $100 from account 123 to account 456?”

Bob (Call Representative)

“Sure, I will start the process immediately. Is there anything else that I can help you with?”

Alice

“No, that is it. Thank you!”

As you can see in example #2 the identity process supported by our Zero-Knowledge Proof is a lot shorter than if Alice had to prove her identity to Bob, and then ask for the bank transfer. Also, Alice did not risk sharing any information about herself with Bob the call center representative. In example #1, Alice doesn’t know if Bob wrote it down, or if the bank’s systems are secure, etc.

What is a zero-knowledge proof exactly? A Zero-Knowledge Proof enables one party (Alice the prover) to prove to another party (Bob the verifier, the call center agent) that Alice can prove that Bob is speaking with Alice (Alice is looking to prove her identity). All this occurs without revealing any of Alice’s private and sensitive information while proving that Alice is in fact Alice.

Typically, the way Bob would believe that Alice is Alice, is to ask Alice questions about herself to prove to Bob that Alice is in fact Alice (ex: What is your address, social security number, mother’s maiden name, etc.). However, this relies on sharing information, which can be costly as well as become a reputation risk if the data is leaked through the bank’s computer system and shared with unauthorized third parties.

There is a form of a zero-knowledge proof called a zk-SNARK (Zero-Knowledge Succinct Non-Interactive ARgument of Knowledge) that can be used to satisfy the condition of proving Alice is Alice with 100% certainty and without revealing any more information than the cryptographic proof generated from the zk-SNARK. A key element in the zk-SNARK is the non-interactive element: there only needs to be one set of data that is shared with Alice’s Bank, hence there is no interaction between Bob and Alice where they exchange sensitive and private information to prove Alice’s identity. Remember: the cryptographic proof shared cannot be linked to the data that was put into the creation of the proof. This means that if Alice provides her social security number to the Zero-Knowledge Proof program, she can be 100% confident the verifier (Alice’s Bank) will not be able to derive her social security number from the proof Alice provides. Utilization of zk-SNARKs start us on a path where we can retain ownership of our data by simply not sharing sensitive data any longer, thus significantly increasing privacy, and significantly reducing risk for organizations. In a world of Zero-Knowledge Proof usage, I expect to see Equifax, and the type of leaks it allowed to be a thing of the past.

In my next post, I will dive deeper into Zero-Knowledge Proofs by further clarifying what they need to be in order to be considered a true zk-SNARK, as well as further expand the call center example to provide a more realistic way of how it could work in organizations today.

]]>