![2
zkSNARKs
Õ(log(F))
O(1)
F function
x public input
w private witness
Prover
F function
x public input
Veri
fi
er
Õ(F)
I know w s.t. F(x, w) = 1
Zero Knowledge: V learns nothing about w except that F(x, w) = 1
Succinctness: V runs in time much less than |F|
[ ]
Mic94, Groth10, GGPR13, Groth16…
…, GWC19, CHMMVW20, …](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Eos - Efficient Private Delegation of zkSNARK provers
Similar to Eos - Efficient Private Delegation of zkSNARK provers (20)
More from Alex Pruden
More from Alex Pruden (13)
Recently uploaded
Recently uploaded (20)
Eos - Efficient Private Delegation of zkSNARK provers
- 1. EPFL, UC Berkeley EOS: Efficient Private Delegation of zkSNARK provers Alessandro Chiesa Ryan Lehmkuhl MIT Aleo, UPenn Pratyush Mishra Yinuo Zhang UC Berkeley
- 2. 2 zkSNARKs Õ(log(F)) O(1) F function x public input w private witness Prover F function x public input Veri fi er Õ(F) I know w s.t. F(x, w) = 1 Zero Knowledge: V learns nothing about w except that F(x, w) = 1 Succinctness: V runs in time much less than |F| [ ] Mic94, Groth10, GGPR13, Groth16… …, GWC19, CHMMVW20, …
- 3. Many applications of zk! 3 • Anonymous credentials [DFKP16] • Prove existence of security vulnerability [DARPA Sieve, OBW22] • Coercion-resistant voting [MACI] • … Private transactions Private Smart Contracts Decentralized multiplayer games
- 4. Problem: Proving is really slow 4 Hashing 10kB with SHA2 takes 140 seconds with Groth16, but takes just a few milliseconds “natively”
- 5. Potential Solution: Outsource Proving! 5 x public input w private witness π zkSNARK proof
- 6. Potential Solution: Outsource Proving 6 x public input w private witness π zkSNARK proof DIZK [WZCPS, Usenix ’18] Problem: This leaks secrets to the workers!
- 7. Delegation protocol Goal: Outsource Proving with Privacy 7 π zkSNARK proof x public input w private witness Goal 1: E ffi ciency The delegator’s work should be much less than proving Goal 2: Privacy The delegator’s witness should be hidden from the worker Problem: Can’t achieve this without heavyweight tools like FHE
- 8. Delegation protocol 8 x public input w private witness Goal: Outsource Proving with Threshold Privacy
- 9. Delegation protocol 9 x public input w private witness Goal: Outsource Proving with Threshold Privacy
- 10. Delegation protocol 10 π zkSNARK proof x public input w private witness Goal 1: E ffi ciency Goal 2: Privacy The delegator’s work should be much less than proving The delegator’s witness should be hidden from the workers, as long as at least 1 worker is honest Goal: Outsource Proving with Threshold Privacy
- 11. This work: Delegation for zkSNARK Provers 11 We show to delegate zkSNARK proving for systems based on Polynomial IOPs We show how to construct delegation schemes for: 1. the KZG and inner-product-argument polynomial commitment schemes, 2. the Marlin [CHMMVW20] PIOP, 3. Generically any zkSNARK combining these components We implemented and evaluated our protocols. TL; DR: delegating from a mobile phone is 26x faster than computing locally!
- 13. What is MPC? 13 x1 x2 x3 A way for multiple parties to compute a function over their joint inputs in a privacy-preserving manner F F(x1, x2, x3)
- 14. Simple MPC Construction 14 Model of Computation × + = x1 x2 x3 Arithmetic circuits over fi nite fi eld Circuit Execution 1. Share inputs with additive secret sharing m sn = [[m]]n si = [[m]]i s1 = [[m]]1 Share Σ m 2. Evaluate circuit gate by gate: : Just add local shares! Add(x, y) : Triple-based, HE-based, etc (All require interaction!) Mul(x, y) [SPDZ]
- 15. MPC to compute SNARK Prover? 15 Delegation protocol π zkSNARK proof x public input w private witness MPC for C 𝖲 𝖭 𝖠 𝖱 𝖪 MPC is slow! For example, • Multiplications require interaction • Preprocessing requires heavy cryptography • Malicious security requires at least 2x overhead Circuit for SNARK is large! For example, • Need to support fi eld ops, group ops, RO calls • Need to support large MSMs and FFTs
- 16. Ef fi cient Circuits for zkSNARK Provers
- 17. V(vk, 𝕩 ) P(pk, 𝕩 , 𝕨 ) PIOP. P ROVER PIOP. V ERIFIER p1 r1 … PC.COMMIT QUERY PC.OPEN pt rt PC.COMMIT cm1 cmt DECISION (π, [v]) PC.CHECK 17 Q Recap: PIOPs + PC Schemes → SNARK + Fiat—Shamir to get non-interactivity
- 18. What operations does SNARK prover perform? 18 P(pk, 𝕩 , 𝕨 ) PIOP. P ROVER p1 r1 … PC.COMMIT QUERY PC.OPEN pt rt PC.COMMIT cm1 cmt (π 𝖯 𝖢 , [v]) Q ρ ρ PIOP over requires arithmetic. Hence, circuit should natively support operations. 𝔽 r 𝔽 r 𝔽 r Popular PC schemes require EC ops, which involve ops for . 𝔽 q 𝔽 q ≠ 𝔽 r Even if we instantiate RO with MPC/ SNARK-friendly hashes, this still require tons of multiplications
- 19. 19 Problem 1: Multiple kinds of operations Problem 2: Lots of operations
- 20. Solution: generalize circuit! 20 Model of Computation ρ + 𝔽 × 𝔾 x1 x2 x3 New gates for addition, -(scalar) multiplication, RO calls 𝔾𝔾 Circuit Execution Key insight: additive sharing is linear! 2. Evaluate circuit gate by gate: , : as before Add 𝔽 (x, y) Mul 𝔽 (x, y) [Smart-Alaoui 2019] [Ozdemir-Boneh 2022] : locally add shares of Add 𝔾 (X, Y) X, Y : scalar-multiply by share of Mul 𝔾 (x, Y) Y x (assumes is public) Y : coming up! ρ(x) M ∈ 𝔾 Sn ∈ 𝔾 Si ∈ 𝔾 S1 ∈ 𝔾 Share Σ M
- 21. 21 Problem 1: Multiple kinds of operations Problem 2: Lots of operations!
- 22. Ef fi cient Circuits for PIOP Provers 22 Evaluate over subgroup p Divide by vanishing poly p Multiply by public scalar p Multiply two polynomials Require only addition gates Local computation ~ as ef fi cient as plaintext prover ⟹ PIOP.PROVER Interpolate polynomial Add two polynomials FFT (linear) IFFT (linear) Pointwise mul (depth-1)
- 23. Ef fi cient Circuits for PC Schemes 23 1. Parse as 2. Let the coe ffi cients of be 3. Output (like standard KZG!) KZG.Commit( 𝗌 𝗋 𝗌 , [[p]]) : 𝗌 𝗋 𝗌 {G, βG, …, βd G} [[p]] (a0, a1, …, ad−1) [[cm]] := d−1 ∑ i=0 ai ⋅ βi G 1. Compute share of witness poly 2. Output KZG.Open( 𝗌 𝗋 𝗌 , [[p]], z) : [[w(X)]] := [[p(X)]] − [[p(z)]] X − z [[π]] := KZG.Commit( 𝗌 𝗋 𝗌 , [[w]]) Complexity is same as standard KZG + no interaction! Similar techniques in [KZGM21, OB22]
- 24. Delegation protocol Progress so far 24 π zkSNARK proof x public input w private witness MPC for C 𝖲 𝖭 𝖠 𝖱 𝖪 MPC is slow! For example, • Multiplications require interaction • Preprocessing requires heavy cryptography • Malicious security requires at least 2x overhead Designed e ffi cient ! But so far only as e ffi cient as prior work [KZGM21, OB22] Can we do better? C 𝖲 𝖭 𝖠 𝖱 𝖪
- 25. Tailored MPC for zkSNARK Provers
- 26. How to Improve MPC? 26 Opportunity 1: Asymmetric Threat Model Opportunity 2: Error-resilient nature of C 𝖲 𝖭 𝖠 𝖱 𝖪 Delegation protocol Delegator is always honest! If SNARK prover has a non-trivial deviation from honest algorithm, soundness guarantees of zkSNARK will ensure the proof is invalid Can we use this to get cheaper security against malicious workers?
- 27. Taking advantage of asymmetric threat model
- 28. Protocols for multiplication gates 28 [[x]]B, [[y]]B [[x]]A, [[y]]A [[z]]B = [[xy]]B [[z]]A = [[xy]]A Example 1: Protocols with Preprocessing Offline 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 B 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 A Online 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 B 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 A [[x]]A, [[y]]A [[x]]B, [[y]]B Preprocessing protocol Online protocol Can require heavy crypto!
- 29. Protocols for multiplication gates 29 [[x]]B, [[y]]B [[x]]A, [[y]]A [[z]]B = [[xy]]B [[z]]A = [[xy]]A Example 1: Protocols with Preprocessing Offline 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 B 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 A Online 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 B 𝗉 𝗋 𝖾 𝗉 𝗋 𝗈 𝖼 A [[x]]A, [[y]]A [[x]]B, [[y]]B Online protocol Usually just secret sharing!
- 30. Protocols for multiplication gates 30 [[x]]B, [[y]]B [[x]]A, [[y]]A [[z]]B = [[xy]]B [[z]]A = [[xy]]A Example 2: Delegator performs multiplication Online [[x]]B, [[y]]B [[x]]A, [[y]]A
- 31. Protocols for multiplication gates 31 [[z]]B = [[xy]]B [[z]]A = [[xy]]A Example 2: Delegator performs multiplication Online y = [[y]]A + [[y]]B x = [[x]]A + [[x]]B z = xy [[x]]B, [[y]]B [[x]]A, [[y]]A
- 32. Protocols for multiplication gates 32 [[z]]B = [[xy]]B [[z]]A = [[xy]]A Example 2: Delegator performs multiplication Online y = [[y]]A + [[y]]B x = [[x]]A + [[x]]B z = xy [[z]]B [[z]]A [[x]]B, [[y]]B [[x]]A, [[y]]A
- 33. Protocols for RO gates 33 Delegator performs RO call [[x]]B [[x]]A
- 34. Protocols for RO gates 34 Delegator performs RO call x = [[x]]A + [[x]]B z = ρ(x)
- 35. Protocols for RO gates 35 Delegator performs RO call z z x = [[x]]A + [[x]]B z = ρ(x) No hashes in MPC!
- 36. Taking advantage of the threat model
- 37. Malicious security 37 MPC generally has high overhead for malicious security For example, SPDZ uses algebraic MACs, which doubles the amount of communication and computation. This is re fl ected in the protocol of [OB22], which incurs at least a 2x overhead compared to local proving. Can we do better?
- 38. Intuition: GMW Compiler 38 ZKP for correct computation of each message x1 x2 x3 F(x1, x2, x3) Semi-honest Secure + Privacy (but not correctness) against malicious Adv x1 x2 x3 F(x1, x2, x3) Malicious Secure: Privacy and correctness against malicious Adv Expensive!
- 39. Idea: The computation is itself a ZKP! 39 Delegation MPC 𝖵 𝖾 𝗋 𝗂 𝖿 𝗒 ( 𝗏 𝗄 , x, π) ? = 1 Privacy: Guaranteed by base semi-honest protocol. Correctness: If adversary deviates in non-trivially, then end proof will fail to verify
- 40. Selective Failure Attacks 40 Delegation MPC 𝖵 𝖾 𝗋 𝗂 𝖿 𝗒 ( 𝗏 𝗄 , x, π) ? = 1 This idea as is does not work! Malicious worker can malleate its messages in a way so that the fi nal proof fails only sometimes. This can leak information about witness!
- 41. Our Approach: Consistency Checkers 41 Delegation MPC 𝖵 𝖾 𝗋 𝗂 𝖿 𝗒 ( 𝗏 𝗄 , x, π) ? = 1 Introduce additional cheap checks that enforce that workers are using the provided witness, and not a malleated one 𝖢 𝗁 𝖾 𝖼 𝗄 ( 𝗏 𝗄 , x, π′  ) ? = 1
- 42. Our Approach: Consistency Checkers 42 Delegation MPC 𝖵 𝖾 𝗋 𝗂 𝖿 𝗒 ( 𝗏 𝗄 , x, π) ? = 1 Consistency checker for Marlin: additional query to witness polynomial + linear amount of delegator work Introduce additional cheap checks that enforce that workers are using the provided witness, and not a malleated one 𝖢 𝗁 𝖾 𝖼 𝗄 ( 𝗏 𝗄 , x, π′  ) ? = 1
- 43. Our Overall: Consistency Checkers 43 Delegation MPC 𝖵 𝖾 𝗋 𝗂 𝖿 𝗒 ( 𝗏 𝗄 , x, π) ? = 1 Consistency checker for Marlin: additional query to witness polynomial + linear amount of delegator work Introduce additional cheap checks that enforce that workers are using the provided witness, and not a malleated one 𝖢 𝗁 𝖾 𝖼 𝗄 ( 𝗏 𝗄 , x, π′  ) ? = 1
- 44. 44 But does all of this result in concrete performance improvements?
- 45. Tons more optimizations! 45 Crypto: • No heavyweight malicious security techniques • Avoiding MPC for witness-independent part of zkSNARK • Multiplication triple generation at delegator • Novel security-ef fi ciency trade-offs Systems: • Better parallelization for high-core machines • Eager memory reclamation in AHP prover
- 46. Implementation 46 We implemented our protocols in a Rust library in the arkworks ecosystem. Our library constructs delegation protocols for any PIOP-based SNARKs given circuits for the PIOP prover and PC scheme. Additionally, we implement circuits for the 1. KZG polynomial commitment scheme, and 2. Marlin [CHMMVW20] PIOP This gives us a delegation protocol for the Marlin zkSNARK.
- 47. Evaluation 47 Speedup Increase in Provable R1CS Size Speedup over [OB22] Laptop w/ gigabit internet 9x 256x 6x Laptop w/ standard home internet 6x 256x — Phone w/ standard home internet 26x 256x —
- 48. Thank You! 48 Code coming soon to an arkworks repository near you! Paper: www.usenix.org/conference/usenixsecurity23/presentation/chiesa (Also coming soon to ePrint)