Applying ZKP concepts for privacy preservation in distributed ledger systems
By the end of this session, you will be able to:
A Zero-Knowledge Proof (ZKP) is a cryptographic method that allows one party (the prover) to prove to another party (the verifier) that they know a secret without revealing the secret itself.
Prover and Verifier agree on a mathematical statement to prove
Prover creates a cryptographic commitment using their secret
Verifier sends a random challenge to test the Prover's knowledge
Prover provides response that proves knowledge without revealing the secret
This process is repeated multiple times. Each round has a 50% chance of success if the prover is cheating. After n rounds, the probability of successful cheating drops to (1/2)^n, making it negligibly small.
Claim: Alice knows the secret password to the door that connects both paths inside the cave.
Goal: Prove this knowledge to Bob without revealing the actual password.
Action: Alice enters the cave and randomly chooses either Path A or Path B.
Important: Bob cannot see which path Alice chose - he waits outside!
Challenge: Bob randomly calls out "Come out from Path A!" or "Come out from Path B!"
Result: If Alice knows the password, she can always exit from the requested path (using the secret door if needed).
After multiple rounds, Bob becomes convinced Alice knows the password without learning the password himself. This demonstrates all three ZKP properties: completeness, soundness, and zero-knowledge!
If the statement is true and both parties follow the protocol, the verifier will be convinced
If the statement is false, no cheating prover can convince the verifier (except with negligible probability)
The verifier learns nothing about the secret beyond the fact that the statement is true
Require back-and-forth communication between prover and verifier
Single message from prover to verifier, no interaction needed
Blockchain applications typically use non-interactive ZKPs because:
zk-SNARKs use elliptic curve cryptography and bilinear pairings to create extremely compact proofs that can verify complex computations.
Convert the computation into an arithmetic circuit (R1CS - Rank-1 Constraint System)
Example: (a + b) * c = output
becomes:
s1 = a + b
s2 = s1 * c
s2 = output
Generate proving and verifying keys using random toxic waste
Powers of tau ceremony:
τ, τ², τ³, ..., τⁿ
Toxic waste τ must be destroyed!
Prover creates a proof using secret witness and proving key
π = Prove(pk, public_input, secret_witness)
Size: ~200 bytes regardless of computation complexity
Verifier checks proof using public inputs and verifying key
result = Verify(vk, public_input, π)
Time: ~5-10 milliseconds
Returns: true/false
Problem: Send cryptocurrency privately while proving transaction validity.
Solution using zk-SNARKs:
zk-STARKs use hash functions and error-correcting codes (specifically Reed-Solomon codes) to create transparent, scalable proofs without trusted setup.
Convert computation into algebraic constraints over finite fields
Example: Fibonacci sequence
f(x+2) = f(x+1) + f(x)
Constraint: next_value = current + previous
Use Fast Reed-Solomon Interactive Oracle Proofs (FRI)
Commit to execution trace as polynomial
P(x) encodes the computation
Merkle tree commits to evaluations
Interactive protocol for polynomial proximity testing
Recursively reduce polynomial degree
Each round halves the degree
Verifier samples random points
Make interactive protocol non-interactive using hash functions
challenges = Hash(transcript)
No trusted setup needed
Purely based on hash functions
| Computation Size | Proof Size | Proving Time | Verification Time | Memory Usage |
|---|---|---|---|---|
| 1M constraints | ~100 KB | ~30 seconds | ~10 ms | ~8 GB |
| 10M constraints | ~150 KB | ~5 minutes | ~15 ms | ~80 GB |
| 100M constraints | ~200 KB | ~45 minutes | ~20 ms | ~800 GB |
Problem: Scale Ethereum DEX to handle thousands of trades per second.
Solution using zk-STARKs:
Bulletproofs use inner product arguments and Pedersen commitments to create compact range proofs without trusted setup, particularly optimized for confidential transactions.
Cryptographically commit to values using elliptic curve points
Commitment: C = vG + rH
v = secret value
r = random blinding factor
G, H = public generator points
Prove that committed value is in valid range [0, 2ⁿ-1]
Prove: 0 ≤ v < 2⁶⁴
Binary representation: v = Σ aᵢ2ⁱ
Each aᵢ ∈ {0,1}
Recursively reduce the proof size using inner product relations
⟨a, b⟩ = Σ aᵢbᵢ
Recursive halving technique
O(log n) proof size
Efficiently combine multiple range proofs into single proof
Single proof for multiple values:
Prove v₁, v₂, ..., vₙ all in range
Logarithmic size in number of proofs
| Bit Range | Single Proof | Aggregated (n=10) |
|---|---|---|
| 8-bit | 418 bytes | 580 bytes |
| 32-bit | 546 bytes | 708 bytes |
| 64-bit | 674 bytes | 836 bytes |
Problem: Hide transaction amounts while preventing double-spending and ensuring positive amounts.
Solution using Bulletproofs:
| Property | zk-SNARKs | zk-STARKs | Bulletproofs |
|---|---|---|---|
| Trusted Setup | Required | Not Required | Not Required |
| Proof Size | ~200 bytes | ~100-200 KB | ~600-2000 bytes |
| Verification Time | ~5 ms | ~10-20 ms | ~100-500 ms |
| Proving Time | Minutes-Hours | Seconds-Minutes | Milliseconds |
| Quantum Resistance | No | Yes | No |
| Memory Usage | GB-TB | GB-TB | MB-GB |
| Best Use Case | General computation | Large-scale computation | Range/arithmetic proofs |
| Maturity | Production Ready | Emerging | Production Ready |
Hide transaction amounts and participants while proving validity
Users can send "shielded" transactions where:
Compress many transactions into a single proof for efficiency
Layer 2 scaling solution that:
Prove identity attributes without revealing personal information
Prove you're over 18 without revealing:
Enable verifiable elections while maintaining voter privacy
Voters can prove they:
Blockchain systems traditionally emphasize transparency, but many applications require privacy. ZKPs offer a way to balance these competing needs.
Zero-knowledge proofs enable systems that are:
In the next session, we'll explore Keyless Technologies & Multiple IDs, examining how distributed ledger systems can manage identity without traditional key-based approaches and support multiple identity frameworks.