20,000 Leagues Under the Ⓩ: A Zcash Deep-Dive

Zcash is an open-source cybercoin that offers privacy and selective transparency of transactions. Zcash uses advanced cryptographic techniques, namely zero-knowledge proofs, to guarantee the validity of transactions without revealing additional information about them. The upcoming Sapling network upgrade contains breakthrough cryptographic innovations that result in improvements to performance, security, and usability.

This talk starts with a brief overview of Zcash, outlining the modifications that were made to the Bitcoin design in order to support privacy-preserving "shielded" transactions. From there, we delve into the cryptographic design of shielded transactions themselves, and how zk-SNARKs are leveraged to create privacy in a public block chain. Finally, we examine the Sapling upgrade, stepping through the myriad of academic papers and engineering tricks to understand just how the upcoming performance, security, and usability improvements have been achieved.

Transcript

1. 20,000 Leagues Under the Ⓩ A Zcash Deep-Dive Jack Grigg @str4d 2018-06-21
2. Overview 1) Zcash concepts 2) Zcash structure 3) Sapling improvements
3. 1) A Zcash Scuba Survey Jayme Pastoric [Public domain], via Wikimedia Commons
4. Transparent Transactions
5. Shielded Transactions
6. Zcash Transactions
7. Monetary Pools Mining rewards Transparent Sprout Sapling
8. 2) The Zcash Sub-Structure 1 2 3 4 5 6 Voytek S [CC BY 3.0], via Wikimedia Commons
9. What’s in a Note? • Address pk • Value v • Uniqueness ρ (derived in a deterministic way to prevent attacks) ρ = 7689432... ρ = 1240826...
10. Hiding the Graph • Sender creates private Note • pk, v, ρ • Sender derives public commitment • Pick blinding randomness rcm • cm = SHA-256(pk || v || ρ || rcm) • Sender encrypts Note to recipient • Pick random keypair (esk, epk) • ct = Enc(KDF(DH(esk, pk), ...), v || ρ || rcm || memo)
11. Hiding the Graph • Recipient decrypts Note • v || ρ || rcm || memo = Dec(KDF(DH(sk, epk), ...), ct) • Recipient checks public commitment • cm = SHA-256(pk || v || ρ || rcm) • Recipient derives nullifier when spending • nf = SHA-256(ρ || sk)
12. Hiding the Graph Tx 1 - cm Tx 2 - nf Note data - pk - v - ρ
13. Reality Anchor: Merkle Tree!
14. Shielded Transactions • Private inputs and outputs: • (pk i , v i ), (pk o , v o ) • Public values: • nf i , cm o , ct o • rt – root of Merkle tree containing cm i • Consensus rules: 1) Input notes previously existed 2) Inputs sum to outputs 3) Sender has authority to spend 4) Inputs haven’t been spent
15. Shielded Transactions • Private inputs and outputs: • (pk i , v i ), (pk o , v o ) • Public values: • nf i , cm o , ct o • rt – root of Merkle tree containing cm i • Consensus rules: 1) Paths exist from cm i to rt 2) Σv i = Σv o 3) Sender has authority to spend 4) nf i have never been seen before 5) nf i correctly calculated from (pk i , v i ) 6) cm o correctly calculated from (pk o , v o )
16. Binding the Pieces • We can check 4) publicly. • For the rest, we use a zero-knowledge proof! • Zcash uses zk-SNARKs • zero-knowledge Succinct Non-interactive ARguments of Knowledge • Rely on pairings: e(αg 1 , βg 2 ) = e(g 1 , g 2 )αβ • Short proofs (< 300 bytes) • Relatively quick to verify (< 30ms)
17. Full [PGHR13] protocol ([BCTV14USENIX ] variant)
18. Consensus Rules → Constraints • a 0 := boolean value • a 1 := boolean value • ... • a 7 := boolean value • a := byte value • a 0 * (1 – a 0 ) = 0 • a 1 * (1 – a 1 ) = 0 • ... • a 7 * (1 – a 7 ) = 0 • 1 * (20a 0 + 21a 1 + ... + 27a 7 – a) = 0 Now constrain those numbers to satisfy other equations, like elliptic curve operations or SHA-256.
19. Sprout Circuit Design • One proof handled two inputs & two outputs • Seemed like a common use case • Chain together for more inputs or outputs • Commitment Merkle tree depth of 29 • Would last ~2 years at avg rate of 4 proofs / second
20. Sprout Circuit Problems • Circuit was big and slow. • Proving system was not fast enough. • 45-70s per proof (depending on hardware) • 3GB RAM to generate (later down to 1.7GB) • Chaining proofs together wasted one input and one output of each. • Prover had spend authority.
21. 3) Sapling: Bedrock Improvements Deep Water Macroalgal Meadows 2004 Exploration, NOAA-OE
22. Performance: Proving system • Sprout: PHGR13 • Eight field elements in each proof • Seven pairing checks to verify proofs • ~27 ms • Sapling: Groth16 • Three field elements in each proof • Three pairing checks to verify proofs • ~8 ms [PHGR13] https://eprint.iacr.org/2013/279.pdf [Groth16] https://eprint.iacr.org/2016/260.pdf (More papers etc. at https://zkp.science)
23. Performance & Security: Curve • Sprout: BN254 • q ≈ 2254, order r ≈ q • Lower security level, increasing q hurts performance • Really inefficient to implement elliptic curve ops in circuit • Sapling: BLS12-381 • q ≈ 2384, order r ≈ 2256 • Targets 128-bit security level and pairing performance • Has an embedded twisted Edwards curve (named Jubjub) • Amenable to tricks
24. Performance: Jubjub • Constructed over scalar field of BLS12-381 • Complete affine addition in six constraints: • Birationally equivalent to a Montgomery curve with incomplete affine addition in three constraints. −u2+v2=1− 10240 10241 u2 v2 A=v 2 ∗u 1 U=(u 1 +v 1 )∗(u 2 +v 2 ) B=u 2 ∗v 1 u 3 ∗(1+C)=(A+B) C= 10240 10241 ∗A∗B v 3 ∗(1−C)=(U −A−B)
25. Performance: Pedersen hashes • Pedersen commitment: [x] G + [r] H • Computationally binding under discrete log assumption • Pedersen hash: • PH(x) = [x 1 ] G 1 + [x 2 ] G 2 + ... + [x i ] G i • Collision-resistant under discrete log assumption • G i are independent bases (Nothing Up My Sleeves) • x i are chunks of the bit-string x encoded as scalars • G i are fixed, so we use a 2-bit-plus-negation windowed encoding
26. Performance: PRF • Sprout: SHA-256 • Just the compression function, no length padding • 25,840 constraints • Used 68 times • Sapling: BLAKE2s • One full block • 21,518 constraints • Used 4 times in equivalent use-case
27. Performance: Merkle tree • Sprout: SHA-256 • Depth 29 • 25,840 * 29 = 749,360 constraints • Sapling: Pedersen • Depth 32 • 1369 constraints per level • 43,808 constraints
28. Usability: Key Components
29. Hiding the Graph, v2 • Sender creates private Note • (g d , pk d ), v • Sender derives public commitment • Pick blinding randomness rcm • cm = PedersenHash(v || g d || pk d ) + [rcm] H • Recipient derives ρ and nullifier when spending • ρ = cm + [pos] J • nf = BLAKE2s-256(“Zcash_nf”, nk || ρ)
30. Performance: Value balance v o1 , cm o1 cv o1 = [v o1 ] V + [rcv o1 ] R v o2 , cm o2 cv o2 = [v o2 ] V + [rcv o2 ] R v i1 , cm i1 cv i1 = [v i1 ] V + [rcv i1 ] R v i2 , cm i2 cv i2 = [v i2 ] V + [rcv i2 ] R [valueBalance] V + [rcv T ] R = (cv i1 + cv i2 ) - (cv o1 + cv o2 ) valueBalance ..... .....
31. Performance: Circuit size • Sprout: • Almost 221 constraints • Sapling: • Spend circuit: 98777 • < 217 • Output circuit: 7827 • < 213 • Total of 213,208 constraints for equivalent use-case • < 218
32. Constraints → R1CS w ∙ A * w ∙ B = w ∙ C 1 5 1 1 1 0 x 1 x 0 x 0 ~out 0 ~out 0 ~out 1 sym 1 0 sym 1 0 sym 1 0 y 1 y 0 y 0 (5 + x + y) * 1 = ~out
33. R1CS → QAP A B C 0 0 5 0 0 1 0 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0
34. R1CS → QAP A B C 0 0 5 0 0 1 0 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 ↓ ↓ ↓ a 11 x2 + a 12 x + a 13 = y a1 b 11 x2 + b 12 x + b 13 = y b1 c 11 x2 + c 12 x + c 13 = y c1 a 21 x2 + a 22 x + a 23 = y a2 b 21 x2 + b 22 x + b 23 = y b2 c 21 x2 + c 22 x + c 23 = y c2 a 31 x2 + a 32 x + a 33 = y a3 b 31 x2 + b 32 x + b 33 = y b3 c 31 x2 + c 32 x + c 33 = y c3 a 41 x2 + a 42 x + a 43 = y a4 b 41 x2 + b 42 x + b 43 = y b4 c 41 x2 + c 42 x + c 43 = y c4 a 51 x2 + a 52 x + a 53 = y a5 b 51 x2 + b 52 x + b 53 = y b5 c 51 x2 + c 52 x + c 53 = y c5
35. Performance: Circuit size
36. Security: MPC • Sprout MPC • 0-of-K-private • 1-of-K-secure • Everyone needs to be accessible throughout • Took six participants two days • Sapling MPC • 0-of-K-private • 1-of-K-secure per round • Two rounds, contributors can be different • 87 contributions to the Powers of Tau round • Sapling round is ongoing; to sign up, email mpc@z.cash! [BGM17] https://eprint.iacr.org/2017/1050
37. Summary • Shielded transactions break the transaction graph using zero-knowledge proofs • Sapling brings major improvements to • Performance (10x less time, 100x less memory) • Security (safer curve, stronger MPC) • Usability (full viewing keys, diversified addresses)
38. Q&A time!