1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
//! Core trait for external proof adaptation.
//!
//! # Overview
//!
//! This module defines the [`ExternalProof`] trait for converting proofs from external
//! systems (snarkjs, gnark, jf-plonk) into samaharam's [`AccumulatorInstance`] format.
//!
//! # Groth16 vs PLONK Compatibility (Expert Panel Note)
//!
//! Per Dan Boneh and Eli Ben-Sasson's review, there are important mathematical
//! differences between proof systems:
//!
//! ## Groth16 (snarkjs/circom)
//!
//! Groth16 verification uses a pairing equation:
//! ```text
//! e(A, B) = e(α, β) · e(Σ aᵢLᵢ, γ) · e(C, δ)
//! ```
//! The proof consists of points (A, B, C) with no polynomial commitment structure.
//!
//! ## PLONK (gnark, jf-plonk)
//!
//! PLONK verification uses polynomial commitments with KZG openings:
//! ```text
//! Commitments: [a]₁, [b]₁, [c]₁, [z]₁, [t]₁
//! Openings: Quotient polynomials at challenge point ζ
//! ```
//! Each opening is a KZG proof: (commitment, point, evaluation, quotient).
//!
//! ## Adaptation Strategy
//!
//! The [`to_accumulator_instances`] method extracts KZG-like opening instances:
//!
//! | Proof System | Strategy |
//! |--------------|----------|
//! | **Groth16** | Extract A and C as commitments, use synthetic evaluations |
//! | **PLONK** | Direct extraction of wire/quotient polynomial openings |
//!
//! ### Security Consideration
//!
//! **Homogeneous batching** (same proof type) is more efficient and secure.
//! **Heterogeneous batching** (mixing Groth16 and PLONK) requires careful
//! handling to ensure the random linear combination doesn't introduce
//! soundness issues.
//!
//! For production use:
//! 1. Prefer batching proofs of the same type together
//! 2. Use separate accumulator instances for different proof types
//! 3. Verify the mathematical soundness of cross-type aggregation
//!
//! # Example
//!
//! ```rust,ignore
//! use samaharam::adapters::{ExternalProof, SnarkjsProof, GnarkPlonkProof};
//!
//! // Homogeneous batching (recommended)
//! let mut plonk_accumulator = ProofAccumulator::new("plonk");
//! for proof in gnark_proofs {
//! let instances = proof.to_accumulator_instances()?;
//! for instance in instances {
//! plonk_accumulator.add(instance);
//! }
//! }
//!
//! // Heterogeneous batching (use with caution)
//! let mut mixed_accumulator = ProofAccumulator::new("mixed");
//! mixed_accumulator.add(groth16_proof.to_accumulator_instances()?[0].clone());
//! mixed_accumulator.add(plonk_proof.to_accumulator_instances()?[0].clone());
//! ```
use crateAccumulatorInstance;
use cratePairingEngine;
use fmt;
/// Error type for adapter operations.
/// Metadata about an external proof.
/// Trait for converting external proofs to samaharam's aggregation format.
///
/// Implement this trait for any external proof system to enable aggregation.
///
/// # Example
///
/// ```rust,ignore
/// use samaharam::adapters::{ExternalProof, SnarkjsProof};
///
/// let proof = SnarkjsProof::from_json(json_data)?;
/// let instances = proof.to_accumulator_instances()?;
/// for instance in instances {
/// accumulator.add(instance);
/// }
/// ```