Overview
The batched grouped ciphertext validity proof provides an efficient way to verify multiple grouped ElGamal ciphertexts when they all use the same set of public keys. Instead of generating separate proofs for each ciphertext, this proof batches them together using a random challenge scalar, significantly reducing proof size and verification time. This is particularly useful in scenarios with multiple transfers or operations involving the same parties.Batched proofs are more efficient than individual proofs when verifying 2 or more grouped ciphertexts with identical public key sets.
When to Use Batched Proofs
Use Batched Proofs When:- Multiple grouped ciphertexts share the same public keys
- Processing multiple transfers in a single transaction
- Batch processing confidential operations
- Optimizing verification costs
- Only one grouped ciphertext needs verification
- Public keys differ between ciphertexts
- Simplicity is preferred over efficiency
Proof Variants
Like standard grouped ciphertext proofs, batched variants support:- 2 Handles:
BatchedGroupedCiphertext2HandlesValidityProof - 3 Handles:
BatchedGroupedCiphertext3HandlesValidityProof
Batching Strategy
The batching uses a random linear combination:w is a random challenge scalar from the Fiat-Shamir transcript. This allows verification of all individual proofs in a single algebraic check.
Proof Structure
The batched proof structure is similar to individual proofs but applies to multiple ciphertexts simultaneously. For the 2-handle case, it still contains:Y_0: Commitment for the shared Pedersen commitmentsY_1: Commitment for first handlesY_2: Commitment for second handlesz_r: Masked randomness (batched)z_x: Masked amounts (batched)
Generating a Batched Proof
Use Cases
Batch Token Transfers
Process multiple confidential transfers in one transaction:Multi-Operation Accounts
- Batch multiple deposits to the same account
- Process multiple withdrawals together
- Aggregate balance updates
- Bundle related financial operations
Verification Efficiency
Individual Proofs:- N ciphertexts = N proof verifications
- N × (computation + storage)
- N ciphertexts = 1 batched verification
- ~40-60% reduction in verification cost
- ~30-50% reduction in proof size
The exact efficiency gain depends on the number of ciphertexts batched. Generally, batching 3+ ciphertexts provides significant benefits.
Security Considerations
Soundness
The batched proof maintains the same security guarantees as individual proofs:- Computational soundness (discrete log hardness)
- Perfect zero-knowledge
- Fiat-Shamir security in the random oracle model
Implementation Notes
From the proof structure, batching is achieved by:- Generating individual proof commitments
Y_ifor each ciphertext - Computing challenge scalar
wfrom transcript - Combining responses:
z_batched = Σ (w^i × z_i) - Verifying single batched equation
Proof Size Comparison
| Scenario | Individual Proofs | Batched Proof | Savings |
|---|---|---|---|
| 2 ciphertexts | 320 bytes | 160 bytes | 50% |
| 4 ciphertexts | 640 bytes | 160 bytes | 75% |
| 8 ciphertexts | 1,280 bytes | 160 bytes | 87.5% |
Batched proof size remains constant regardless of the number of ciphertexts batched.
Limitations
- Maximum batch size: Limited by available computation units
- Key uniformity: All ciphertexts must use identical public key sets
- Complexity: More complex to implement than individual proofs
Related Proofs
- Grouped Ciphertext Validity: Individual ciphertext validity proof
- Range Proofs: For proving amounts are in valid ranges
- Ciphertext-Commitment Equality: Link ciphertexts with commitments
Source Code
Sigma proof implementation:zk-sdk/src/sigma_proofs/batched_grouped_ciphertext_validity/
Proof data structure: zk-sdk/src/zk_elgamal_proof_program/proof_data/batched_grouped_ciphertext_validity/