Improve Privacy on Blockchain with Zero-Knowledge Proof
•Download as PPTX, PDF•
5 likes•29,169 views
These slides explore how zero-knowledge proof enables blockchain transactions to be verified, while maintaining user anonymity.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Improve Privacy on Blockchain with Zero-Knowledge Proof
Similar to Improve Privacy on Blockchain with Zero-Knowledge Proof (20)
More from Altoros
More from Altoros (20)
Recently uploaded
Recently uploaded (20)
Improve Privacy on Blockchain with Zero-Knowledge Proof
- 1. A Zero-Knowledge Proof: Improving Privacy on a Blockchain Dmitry Lavrenov Senior Blockchain R&D Engineer ALTOROS @altoros
- 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
- 5. @altoros Zero-knowledge proof 01 What is it ? Cryptographic protocol
- 6. @altoros Zero-knowledge proof 02 Participants ? The Prover The Verifier
- 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.
- 10. @altoros ZKP conditions Zero knowledge If the statement is true, then no verifier learns anything, except the fact that the statements is true.
- 11. @altoros ZKP Zero knowledge proof is probabilistic rather than deterministic.
- 12. @altoros The general structure of a ZKP ● witness ● challenge ● response
- 13. @altoros The general structure of a ZKP Witness Proof P V Questions 02 Calculate a proof 03 Send the proof to V 01 Choose a question
- 14. @altoros The general structure of a ZKP Challenge 02 Please, give the answer for the question 01 Choose a question P V Questions
- 15. @altoros The general structure of a ZKP Response Send the answer for the questionP V
- 16. @altoros Ali Baba cave example ● Peggy acts as the Prover ● Victor acts as the Verifier
- 17. @altoros Ali Baba cave example A B
- 18. @altoros Ali Baba cave example A A B
- 19. @altoros Ali Baba cave example Ok
- 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
- 22. @altoros zk-SNARK Zero-knowledge succinct noninteractive argument of knowledge
- 23. @altoros zk-SNARK Succinct The size of the proof is small enough to be verified in a few milliseconds.
- 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.
- 25. @altoros zk-SNARK Argument of knowledge A computationally sound proof: soundness holds against a prover that leverages polynomial-time, i.e. bounded computation.
- 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
- 38. @altoros Idemix and Hyperledger Fabric Identity Mixer MSP Implementation Peer Identity Mixer crypto package KeyGen Presentation Issuance Verification Revocation Audit Fabric-CA Implementation Sign/Verify Enroll/Register/Revoke Sign/Verify Transaction (MSP interface) Issue/Revoke ECert
- 39. @altoros Idemix and Hyperledger Indy Indy-anoncreds. ZKP-based on the Idemix protocol.
- 40. @altoros Idemix and Hyperledger Indy Issuer Issuer’s wallet Prover Prover’s wallet Verifier Ledger 01 Create master key create master key store master key
- 41. @altoros Idemix and Hyperledger Indy Issuer Issuer’s wallet Prover Prover’s wallet Verifier Ledger 02 Create, request and issue credentials get master secret return master secret send credential offer send signed credential request send credential store credential
- 42. @altoros Idemix and Hyperledger Indy Issuer Issuer’s wallet Prover Prover’s wallet Verifier Ledger 03 Present credential to 3rd Party create proof send proof request return proof send proof verify proof
- 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)
- 48. THANK YOU! @altoros website blog
Editor's Notes
- 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.
- That’s all I wanted to say. Any questions ?