What is the difference between zero-knowledge proofs and zero-knowledge arguments?
Think about your answer, then reveal below.
Model answer: Zero-knowledge proofs have statistical soundness: even a computationally unbounded prover cannot cheat with non-negligible probability. This requires multiple rounds of interaction. Zero-knowledge arguments have only computational soundness: a polynomial-time prover cannot cheat, but unbounded provers can. Arguments allow single-pass non-interactive protocols (NIZKs) using hash functions (random oracle model) or structured reference strings (common reference string). The trade-off is fundamental: unconditional soundness requires interaction; computational soundness enables efficiency.
This distinction explains why modern cryptography uses arguments (zk-SNARKs, zk-STARKs) rather than proofs: efficiency trumps unconditional soundness for practical applications.
Question 2 Multiple Choice
A zk-SNARK is 'succinct.' What does succinctness mean, and why is it valuable?
ASuccinct means the proof is shorter than the statement being proven; this reduces communication
BSuccinct means proofs can be verified quickly (polynomial time) despite the statement being hard to verify classically (NP-hard)
CSuccinct is unrelated to efficiency; it is a naming convention
DSuccinct means only a small fraction of honest provers can generate valid proofs
Succinctness means proof size is logarithmic or poly-logarithmic in the statement size, often independent of the computation being proved (constant-size proofs). This is valuable because transmitting a short proof (kilobytes) is faster than sending the full computation (potentially gigabytes). For blockchain applications, succinctness enables scaling: verifying a large batch of transactions via a single zk-SNARK proof is far more efficient than verifying individually.
Question 3 True / False
Non-interactive ZKPs (NIZKs) require setup. What is the difference between Random Oracle Model and Common Reference String setups?
TTrue
FFalse
Answer: True
Random Oracle Model (ROM) assumes hash functions are truly random oracles; NIZKs in ROM are proven secure assuming this idealization, but real hash functions may not behave like random oracles. Common Reference String (CRS) requires a trusted setup ceremony to generate shared setup material; if the ceremony is compromised, security fails. ROM is transparent (no trusted setup) but is a heuristic; CRS is concrete but requires trust. This trade-off influences which NIZK scheme is appropriate for an application.