2. @altoros
The situation
● you need to prove your identity
● you only have your driver’s
license
Driver License
First Name: Dmitry
Last Name: Lavrenov
Date of Birth: 21.08.1995
City: Minsk
3. @altoros
Wouldn’t it be better to have
an option that hides
your private information,
but still keeps
the driver’s license valid?
Driver License
First Name: Dmitry
Last Name: Lavrenov
Date of Birth: 21.08.1995
City: Minsk
7. @altoros
Zero-knowledge proof
03 Goal ?
The Prover has a secret value X
The Goal is to prove it to the Verifier without revealing any
information about X
8. @altoros
ZKP conditions
Completeness
If the statement is true, then the honest verifier — the one that is following the
protocol properly — will be convinced of this fact by an honest prover.
9. @altoros
ZKP conditions
Soundness
If the statement is false, then no cheating prover can convince the honest
verifier that it is true, except for some small probability.
20. @altoros
A non interactive ZKP
● Note that interaction between users is required for general ZKP
● What can be done if interaction between users is not an option?
21. @altoros
The general structure of a non interactive
ZKP
Witness P
Function
“Make a proof”
02
Get the proof
03 Send the proof
01
Send a confidential info
Function
“Check a proof”
05
Get the result
04
Check the proof
V
24. @altoros
zk-SNARK
Noninteractive
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.
26. @altoros
Where can ZKP be applied ?
● Authentication systems
● Ethical behaviour
● Confidentiality
● Checking personal information
● Anonymity
27. @altoros
Zcash
zk-SNARK - based
Bitcoin transactions are fully transparent.
Everyone can use a Bitcoin block explorer to
check transaction that has been sent from
one BTC address to another BTC address.
Bitcoin vs Zcash
Zcash transactions can be private only if the
user chooses z-address. A special view key
can provide selective transparency.
1FeexV6 bAHb8ybZjqQMjJrcCrHGW9sb6uF
5 BTC
nothing to see here
1JCe8z4jJVNXSjohjM4i9Hh813dLCNx2Sy nothing to see here
Sender’s address
??? ZEC
Unknown amount
“shielded ZEC”
Recipient’s address
unkown address
unkown address
28. @altoros
Zcash
Bitcoin, UTXO
● Bitcoin tracks UTXOs to determine what transactions are spendable and
validates it
BUT: All UTXO’s information is open and public.
32. @altoros
Zcash
● the sum of the input values is equal to the sum of the output values for
each shielded transfer
● the sender proves that they have the private spending keys of the input
notes, giving them the authority to spend
33. @altoros
Zcash
● the private spending keys of the input notes are cryptographically
linked to a signature over the whole transaction
● for each input note, a revealed commitment exists
34. @altoros
Zcash
● the nullifiers and note commitments are computed correctly
● it is infeasible for the nullifier of an output note to collide with the
nullifier of any other note
35. @altoros
Ethereum
● zk-SNARK-based solution can potentially increase transaction
processing to 500 tx/sec
● transaction cost is about 600,000 gas
● goal is to reduce the total transaction cost
36. @altoros
Ethereum. AZTEC protocol
● zk-SNARK-based solution on smart-contract level in Ethereum
● confidential Transfer function
● transaction cost is between 800,000-900,000 gas
(a simple transaction cost is about 21,000 gas)
37. @altoros
Identity Mixer (Idemix)
● ZKP-based cryptographic protocol
● Based on Camenisch-Lysyanskaya signature scheme
● Flexible public keys
● Flexible credentials
43. @altoros
Idemix implementation in Go
AttributeNames := [ ]string{"First Name", "Last Name", "Age", "City"}
data := [ ]string{"Dmitry00000000000000000000000000",
"Lavrenov000000000000000000000000",
"23000000000000000000000000000000",
"Minsk000000000000000000000000000"}
44. @altoros
Idemix implementation in Go.
//1. The prover creates keys and credential request to the issuer.
sk := idemix.RandModOrder(rng)
ni := idemix.RandModOrder(rng)
m := idemix.NewCredRequest(sk, idemix.BigToBytes(ni), key.Ipk, rng)
45. @altoros
Idemix implementation in Go.
//2. The issuer creates credentials for the prover.
cred, err := idemix.NewCredential(key, m, attrs, rng)
46. @altoros
Idemix implementation in Go.
// 3. The prover signs the credentials without disclosure Age and City.
disclosure = [ ]byte{1, 1, 0, 0}
sig, err = idemix.NewSignature(cred, sk, Nym, RandNym, key.Ipk,
disclosure, msg, rhindex, cri, rng)
attrs[2] = FP256BN.NewBIGint(0)
attrs[3] = FP256BN.NewBIGint(1)
47. @altoros
Idemix implementation in Go.
// 4. The verifier checks the signature using the Issuer’s public key.
err = sig.Ver(disclosure, key.Ipk, msg, attrs, rhindex,
&revocationKey.PublicKey, epoch)
Hello everyone, I’m from Minsk.
I’m a senior blockchain R&D engineer at Altoros and professionally focus on cryptography.
Today I would like to talk about a mechanism that has a close connection to cryptography, called zero-knowledge proof, and its potential within blockchain. From potentially being used in nuclear disarmament to providing anonymous and secure transactions for public blockchain networks, a zero-knowledge proof is a profound example of cryptographic innovation.
Let’s imagine the following situation. You need to prove your identity with First Name and Last Name to 3rd party. But you only have your driver’s license that contains additional personal information.
Wouldn’t it be better to have an option hides your private information, but still keeps the driver’s license valid ?
In this case, Zero-knowledge proof can help us
The first question is what is a zero-knowledge proof ?
There are 2 types of participants: the prover and the verifier
The prover has a secret value X. But The prover wants to prove it to the Verifier without revealing any information about X. The essence of a zero-knowledge proof is that it is trivial to prove that someone possesses knowledge of certain information by simply revealing it. The challenge is to justify such possession without revealing the information itself or any additional information.
Also, zero-knowledge proof protocol must satisfy the following three parameters:
Completeness. If the statement is true, the honest verifier—the one that is following the protocol properly—will be convinced of this fact by an honest prover
Soundness. If the statement is false, no cheating prover can convince the honest verifier that it is true, except for some small probability.
Zero knowledge. If the statement is true, no verifier learns anything, except the fact that the statement is true.
Completeness and soundness are properties of more general interactive proof systems. The addition of zero knowledge is what turns the verification process into a zero-knowledge proof.
Zero-knowledge proofs are not proofs in the mathematical sense of the term, because there is some small probability, the soundness error, that a cheating prover will be able to convince the verifier of a false statement.
In other words, zero-knowledge proofs are probabilistic proofs rather than deterministic ones.
The general structure of a zero-knowledge proof consists of three sequential actions between the prover and the verifier. These actions are called a witness, a challenge, and a response.
The fact that the Prover knows the secret determines the set of the questions, which always can be answered by the Prover correctly. At first, the Prover chooses randomly any question from the set and calculates a proof. Then, the Prover sends the proof to the Verifier.
After that, the Verifier chooses a question from the set and asks the Prover to answer it.
The Prover calculates the answer and sends it back to the Verifier.
The received answer allows the Verifier to check that the Prover really knows the secret.
The procedure can be repeated as many times as you want, until the probability that the Prover makes guesses rather than knows the correct answers becomes low enough.
To illustrate how ZKP works in practice, Wikipedia refers to the Ali Baba cave story. In this example, Peggy acts as the prover and Victor acts as the verifier.
In the story, the cave is shaped like a ring.
The entrance is on the left side, and there’s a magic door blocking the right side.
Peggy wants to prove to Victor that she knows the secret word to open the magic door.
However, she does not want to reveal the secret word.
To prove that Peggy knows the secret word, they mark the left and right paths from the entrance as A and B. Victor waits outside the cave, while Peggy enters. Hidden from Victor, Peggy walks along either path A or B.
Victor then enters the cave and shouts the name of the path—A or B—he wants Peggy to return to.
Peggy can easily do it if she knows the secret key.
In case Peggy doesn’t know the secret word, she would only be able to return from the door to the entrance if Victor called out the path she took after entering.
Since the path Victor chooses in random, the probability that Peggy doesn’t know the keyword is 1/2. If you repeat the process ktimes, then the probability becomes (½)^k.
This way, it’s enough, for example, to repeat the procedure 20 times to prove that Peggy know the keyword.
Note that the interaction between the users is needed for a ZKP. Although the number of interactions is small in single-round and constant protocols, both users must be involved simultaneously.
In this case, we have the following question: “What can be done if interaction between users is not an option ?”
Blum, Feldman, and Micali suggested a noninteractive ZKP, where users have a shared secret key, which is enough to prove that P knows some secret information without simultaneously involving both users and revealing the information itself.
Unlike a regular zero-knowledge proof, a general structure of a noninteractive ZKP consists of just a single action between participants P and V, and this action is a witness.
P creates the proof from the secret key using special function - “Make a proof”. Then P sends the proof to V. After than V can easily check the proof using another function, called “Check a proof”.
Let’s consider one of the most famous noninteractive zero-knowledge proof protocol.
It’s a zero-knowledge succinct noninteractive argument of knowledge protocol or zk-SNARK.
As we can see, It’s a ZKP-based protocol with additional features.
Succinct. It means that The size of the proof is small enough to be verified in a few milliseconds
Noninteractive. It means that 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 of knowledge. It means bounded computation for the prover.
ZKP protocol can be applied for the following actions.
Zcash is the first widespread application of zk-SNARK. In most public blockchains like Bitcoin, Ethereum, Bitshares and etc, transactions are validated by linking the sender address, receiver address, and input and output values. Zcash uses zk-SNARKs to prove that the conditions for a valid transaction have been satisfied without revealing any crucial information about the addresses or values involved.
Let consider differences between Bitcoin and Zcash for better understanding how zk-SNARK protocol enables privacy in Zcash.
Bitcoin tracks unspent transaction outputs (UTXOs) to determine what transactions are spendable and validates it.
In Zcash, the shielded equivalent of a UTXO is called a commitment, and spending a commitment involves revealing a nullifier.
Zcash nodes keep lists of all the commitments that have been created, and all the nullifiers that have been revealed.
Commitments and nullifiers are stored as hashes, to avoid disclosing any information about the commitments, or which nullifiers relate to which commitments.
For each new note created by a shielded payment, a commitment is published which consists of a hash of: the address to which the note was sent, the amount being sent, a number rho which is unique to this note (later this number is used to derive the nullifier), and a random nonce.
When a shielded transaction is spent, the sender uses their spending key to publish a nullifier which is the hash of the secret unique number rho from an existing commitment that has not been spent, and provides a zero-knowledge proof demonstrating that they are authorized to spend it.
The zero-knowledge proof for a shielded transaction verifies that the following assertions are true.
In September 2018 V.Buterin published the article[3] about on-chain scaling to potentially 500 tx/sec. Also It’s a zk-SNARK - based solution.
The main idea is to scale asset transfer transactions on ethereum by using ZK-SNARKs to mass-validate transactions.
In this case, the cost of a ZK-SNARK verification with the latest protocols is about 600,000 gas. The main goal for ZK-SNARK implementation in the Ethereum blockchain is to reduce
the total transaction’s cost.
Today, AZTEC team has implemented zk-SNARK-based solution on smart-contract level in Ethereum blockchain. You can use private transactions in Ethereum with AZTEC smart contract using confidentialTransfer function.
A standard AZTEC zero-knowledge transaction costs between 800,000 - 900,000 gas.
Idemix is the another example of ZKP-based protocol that is suite for privacy-preserving authentication and transfer of certified attributes which is developed by IBM Research.
Identity Mixer works in a similar way as client certificates in a classical public-key infrastructure (PKI), but with two important differences:
Flexible public keys: Rather than being bound to a single public key, users can have many independent public keys for the same secret key, so that they can use a different keys for each verifier or even for each session.
Flexible credentials: The credentials that certify the user’s attributes can be transformed into valid tokens that contain only a subset of the attributes in the original credential.
Hyperledger Fabirc is one of the famous Hyperledger’s frameworks for blockchain technology which also has implemented Idemix.
There is the picture that described Idemix implementation in Hyperledger Fabric.
Idemix crypto package implements basic cryptographic algorithms.
In this way, Hyperledger Fabric with Idemix protocol provides strong authentication as well as privacy-preserving features such as anonymity, the ability to transact without revealing the identity of the transactor, and unlinkability, the ability of a single identity to send multiple transactions without revealing that the transactions were sent by the same identity.
Hyperledger Indy also uses Idemix. Indy provides a software ecosystem for private, secure, and powerful identity.
Indy-anoncreds is the main cryptographical part of Hyperledger Indy which provides privacy of identity’s credentials. It’s ZKP-based upon the Idemix protocol.
There are the main steps which describe the main anoncreds workflow.
Firstly, the prover creates master key. Master key is used to guarantee that a credential uniquely applies to the prover.
Then the Prover creates credentials which is signed by the Issuer’s private key and stores it in the wallet.
Finally, the Prover can create the proof to the Verifier.
Identity Mixer crypto package was implemented firstly in Golang in Hyperledger Fabric v1.2. There is the example in Go which represents essence of Idemix.
There are just high-level pictures which illustrate how it can be implemented in Go.
The goal is to prove identity without disclosing Age and City.
Firstly, 1. The prover creates keys and credential request to the issuer.
After that, The issuer creates credentials for the prover.
Then The prover signs the credentials without disclosure Age and City.
Finally, The verifier checks the signature using the Issuer’s public key.