A Practical Approach
Zero-knowledge proofs (ZKPs) are cryptographic protocols that allow a prover to convince a verifier that a statement is true without revealing any additional information. In practical applications, minimizing communication complexity—specifically the number of rounds and proof size—is crucial for efficiency.
In this article, we’ll explore a concrete example: proving knowledge of a discrete logarithm while minimizing communication overhead. We’ll implement both a naive interactive protocol and an optimized non-interactive version using the Fiat-Shamir heuristic.
Problem Statement
Given a cyclic group $G$ of prime order $q$ with generator $g$, and a public value $h = g^x$, the prover wants to convince the verifier that they know the secret value $x$ such that:
$$h = g^x \bmod p$$
We aim to minimize:
- Round complexity: Number of message exchanges
- Proof size: Total bits transmitted
Subject to constraints:
- Soundness error $\leq 2^{-\lambda}$ (security parameter $\lambda$)
- Completeness: Honest provers always succeed
- Zero-knowledge: No information about $x$ is leaked
Python Implementation
1 | import numpy as np |
Code Explanation
Core Components
1. Cryptographic Setup
The generate_safe_prime_params() function provides a safe prime using the Mersenne prime $p = 2^{127} - 1$. This ensures the discrete logarithm problem is computationally hard in the group $\mathbb{Z}_p^*$. The random_in_range() function uses Python’s secrets module for cryptographically secure random number generation, avoiding the overflow issues with numpy.random.randint() for large integers.
2. Interactive Schnorr Protocol
The InteractiveSchnorrProtocol class implements the basic three-round protocol:
- Commitment Phase: Prover selects random $r \in \mathbb{Z}_q$ and computes $t = g^r \bmod p$
- Challenge Phase: Verifier sends random challenge $c \in {0,1}$
- Response Phase: Prover computes $s = r + cx \bmod q$
- Verification: Verifier checks if $g^s = t \cdot h^c \bmod p$
To achieve security parameter $\lambda$, the protocol must be repeated $\lambda$ times in parallel, resulting in proof size:
$$\text{Size}_{\text{interactive}} = \lambda \cdot (128 + 1 + 128) = 257\lambda \text{ bits}$$
3. Non-Interactive Protocol (Fiat-Shamir)
The Fiat-Shamir heuristic converts the interactive protocol to non-interactive by replacing the verifier’s random challenge with a cryptographic hash:
$$c = H(g, h, t)$$
This reduces rounds from 3 to 1 while maintaining security in the random oracle model. The proof size becomes constant:
$$\text{Size}_{\text{Fiat-Shamir}} = 256 \text{ bits}$$
The soundness error is now bounded by the collision resistance of the hash function: $\epsilon \approx 2^{-128}$.
4. Batch Protocol Optimization
The OptimizedBatchProtocol implements a crucial optimization: proving multiple statements simultaneously with a single proof. For $n$ statements $(x_1, h_1), \ldots, (x_n, h_n)$, instead of sending $n$ separate proofs, we:
- Compute single commitment $t = g^r$
- Generate challenge $c = H(g, h_1, \ldots, h_n, t)$
- Send aggregated response $s = r + \sum_{i=1}^n c^i x_i \bmod q$
This achieves constant proof size regardless of $n$:
$$\text{Size}_{\text{batch}} = 256 \text{ bits}$$
The compression ratio grows linearly: $\frac{256n}{256} = n$.
Performance Optimizations
Fast Modular Exponentiation: Using pow(base, exp, mod) instead of (base ** exp) % mod provides exponential speedup through the binary exponentiation algorithm.
Secure Random Generation: The secrets module provides cryptographically secure randomness without the integer overflow limitations of NumPy’s random functions when dealing with large cryptographic integers.
Hash-Based Challenges: SHA-256 provides 128-bit security with negligible computation overhead compared to interactive randomness exchange.
Visualization and Analysis
The code generates comprehensive visualizations:
2D Plots:
- Communication complexity vs security parameter (linear for interactive, constant for non-interactive)
- Round complexity comparison (constant 3 vs 1)
- Computation time scaling (logarithmic in security parameter)
- Batch efficiency showing $O(1)$ proof size vs $O(n)$ naive approach
3D Plots:
- Trade-off surface showing relationships between security, rounds, and proof size
- Batch performance manifold displaying size-time-batch_size relationships
- Compression advantage visualization comparing batched vs naive approaches
Results Analysis
Zero-Knowledge Proof Communication Complexity Analysis
============================================================
Initializing cryptographic parameters...
Testing Interactive Protocol...
Security=32: Rounds=3, Size=8224 bits, Time=0.0027s
Security=64: Rounds=3, Size=16448 bits, Time=0.0050s
Security=96: Rounds=3, Size=24672 bits, Time=0.0076s
Security=128: Rounds=3, Size=32896 bits, Time=0.0106s
Security=160: Rounds=3, Size=41120 bits, Time=0.0126s
Security=192: Rounds=3, Size=49344 bits, Time=0.0156s
Security=224: Rounds=3, Size=57568 bits, Time=0.0182s
Security=256: Rounds=3, Size=65792 bits, Time=0.0209s
Testing Non-Interactive Protocol...
Security=32: Rounds=1, Size=256 bits, Time=0.0002s
Security=64: Rounds=1, Size=256 bits, Time=0.0001s
Security=96: Rounds=1, Size=256 bits, Time=0.0002s
Security=128: Rounds=1, Size=256 bits, Time=0.0002s
Security=160: Rounds=1, Size=256 bits, Time=0.0001s
Security=192: Rounds=1, Size=256 bits, Time=0.0002s
Security=224: Rounds=1, Size=256 bits, Time=0.0001s
Security=256: Rounds=1, Size=256 bits, Time=0.0001s
Testing Batch Protocol...
Batch size=1: Size=256 bits, Time=0.0001s
Batch size=2: Size=256 bits, Time=0.0001s
Batch size=4: Size=256 bits, Time=0.0001s
Batch size=8: Size=256 bits, Time=0.0001s
Batch size=16: Size=256 bits, Time=0.0001s
Batch size=32: Size=256 bits, Time=0.0002s
Batch size=64: Size=256 bits, Time=0.0004s
Batch size=128: Size=256 bits, Time=0.0008s
====================================================================================================
COMPREHENSIVE COMPARISON TABLE
====================================================================================================
Security λ Protocol Rounds Size (bits) Time (ms) Soundness
----------------------------------------------------------------------------------------------------
32 Interactive 3 8224 2.6989 2.33e-10
Non-Interactive 1 256 0.1788 2.94e-39
----------------------------------------------------------------------------------------------------
64 Interactive 3 16448 4.9698 5.42e-20
Non-Interactive 1 256 0.1426 2.94e-39
----------------------------------------------------------------------------------------------------
96 Interactive 3 24672 7.6480 1.26e-29
Non-Interactive 1 256 0.1516 2.94e-39
----------------------------------------------------------------------------------------------------
128 Interactive 3 32896 10.6094 2.94e-39
Non-Interactive 1 256 0.1576 2.94e-39
----------------------------------------------------------------------------------------------------
160 Interactive 3 41120 12.5782 6.84e-49
Non-Interactive 1 256 0.1450 2.94e-39
----------------------------------------------------------------------------------------------------
192 Interactive 3 49344 15.5516 1.59e-58
Non-Interactive 1 256 0.1502 2.94e-39
----------------------------------------------------------------------------------------------------
224 Interactive 3 57568 18.2030 3.71e-68
Non-Interactive 1 256 0.1361 2.94e-39
----------------------------------------------------------------------------------------------------
256 Interactive 3 65792 20.8933 8.64e-78
Non-Interactive 1 256 0.1149 2.94e-39
----------------------------------------------------------------------------------------------------
====================================================================================================
BATCH PROTOCOL ANALYSIS
====================================================================================================
Batch Size Proof Size (bits) Naive Size (bits) Compression Ratio Time (ms)
----------------------------------------------------------------------------------------------------
1 256 256 1.00 x 0.0601
2 256 512 2.00 x 0.0787
4 256 1024 4.00 x 0.0660
8 256 2048 8.00 x 0.0877
16 256 4096 16.00 x 0.1154
32 256 8192 32.00 x 0.2029
64 256 16384 64.00 x 0.3715
128 256 32768 128.00 x 0.8318
====================================================================================================
Generating visualizations...


Analysis complete! Graphs saved as 'zkp_communication_analysis.png' and 'zkp_batch_analysis_3d.png'
Key Insights
Communication Minimization Strategies:
Fiat-Shamir Transformation: Reduces rounds from 3 to 1 with minimal proof size increase (constant 256 bits vs $257\lambda$ bits for security $\lambda$)
Batch Proofs: Achieve $O(1)$ proof size for $n$ statements versus $O(n)$ naive approach, providing $n$-fold compression
Challenge Space Optimization: Using full hash output (256 bits) versus binary challenges eliminates repetition requirements
Trade-offs:
- Interactive protocols require fewer assumptions (no random oracle) but have higher communication
- Non-interactive protocols sacrifice rounds for constant proof size
- Batch proofs trade individual verifiability for aggregate efficiency
Practical Applications:
These techniques are foundational in modern blockchain systems (zk-SNARKs, zk-STARKs), privacy-preserving authentication, and anonymous credentials where minimizing on-chain data is critical.












