Collaborative zk-SNARKs: Proving as One over Distributed Secrets
summary
Shows that secret‑sharing MPCs that are secure up to additive attacks can already yield a weak malicious guarantee called L‑malicious security, and because SNARKs are self‑verifying this escalates to full malicious security for common proofs (Groth16, Plonk, Bulletproofs) in the random‑oracle/Fiat‑Shamir setting. Construction uses degree‑2 reductions, Bar‑Ilan‑Beaver style randomized steps and the zk simulator to avoid an oracle for the prover. Works in honest‑majority, avoids costly consistency compilers but requires checking the statement first to avoid a privacy leak.
AI-written summary · about
chapters (11)
- 0:00Collaborative zk-SNARKs intro
- 2:53Single prover SNARKs limits
- 7:54Collaborative proof challenges
- 12:19Semi-honest to malicious security
- 24:15Malicious security for free?
- 36:17Groth 16 degree-2 computations
- 41:03Malicious security for Groth 16
- 46:48Randomized functions in SNARKs
- 49:17Bulletproofs and Plonk in MPC
- 50:20Open problems and future work
- 51:28Q&A
related talks
23mSonic: Nearly Trustless SNARK Setups
48mzkSNARKs — Cryptographic Proofs for Scaling and Security Challenges
39mPrivacy and Evolution of SNARKs
18mSoK: Understanding zk-SNARKs: The Gap Between Research and Practice
18mA Selection of Pairing Based zk-SNARKs
33mAn Introduction to Zero Knowledge Proofs
18mzkSaaS: Zero-Knowledge SNARKs as a Service
41mThe Future Is Trustless: How ZkVMS And ZkTLS Transform Bug