implementation-vs-arkworks.md
1 # [Implementation vs Arkworks](@id implementation-vs-arkworks) 2 3 This page maps each Groth.jl subsystem to the analogous arkworks component and 4 highlights where we match or intentionally diverge. 5 6 ```@contents 7 Depth = 2 8 ``` 9 10 ## Evaluation Domains & FFTs 11 12 | Topic | Arkworks | Groth.jl | 13 | --- | --- | --- | 14 | Domain sizing | `EvaluationDomain::new(num_constraints + num_inputs)` fills every slot before the IFFT. | Currently we pick the smallest power-of-two ≥ `num_constraints`. When the circuit does not span the full domain we recover the coefficients via barycentric interpolation before padding. **Next step:** populate every slot so the coset FFT can consume the coefficients directly. | 15 | Coset shift | `EvaluationDomain::get_coset(F::GENERATOR)` tracks offsets and inverses. | `get_coset(domain, default_coset_offset)` stores the offset, its inverse, and `offset_pow_size`. | 16 | Vanishing polynomial on a coset | Cached evaluation via `domain.evaluate_vanishing_polynomial(g)`. | For full domains we use the closed form `g^n - 1`. Subset domains FFT `t(x)` on the coset; once the padding matches arkworks we can reuse cached evaluations. | 17 18 **Refactor snapshot (Sep 2025):** 19 20 - Coset path is the default (`compute_h_polynomial` asserts coset vs dense parity). 21 - Subset domains temporarily rebuild coefficients via barycentric interpolation before the FFT padding step. 22 - Alignment plan: populate the full evaluation domain so the FFT/IFFT pair operates without the interpolation shim. 23 24 ## Multi-Scalar Multiplication (MSM) 25 26 | Topic | Arkworks | Groth.jl | 27 | --- | --- | --- | 28 | Variable-base MSM | Straus with optional endomorphism on BLS curves. | `GrothAlgebra.multi_scalar_mul` implements Straus-style MSM; w-NAF helpers are shared with arkworks. Endomorphism optimisations are still TODO. | 29 | Fixed-base tables | `FixedBaseMSM` window tables. | `FixedBaseTable` plus `build_fixed_table`, `mul_fixed`, and `batch_mul` mirror the workflow; benchmarks track table build vs reuse. | 30 31 **Next steps:** profile the prover with window heuristics and consider endomorphisms once the coset path stabilises. 32 33 ## Curve Abstractions & Pairing Engine 34 35 | Topic | Arkworks | Groth.jl | 36 | --- | --- | --- | 37 | Curve traits | `AffineCurve`, `ProjectiveCurve`, generic engines. | `ProjectivePoint{Curve,F}` underpins `BN254Engine`; exposes the same pairing interface. | 38 | Pairing pipeline | Optimal ate with sparse line placement and Frobenius corrections. | Identical formulas, split across `BN254MillerLoop.jl`, `BN254FinalExp.jl`, `BN254Pairing.jl`. | 39 | Extensibility | Feature flags enable extra curves (e.g., BLS12-381). | Abstractions are in place; BN254 is live today and a second engine is on the roadmap. | 40 41 ## Groth16 Pipeline 42 43 | Topic | Arkworks | Groth.jl | 44 | --- | --- | --- | 45 | R1CS → QAP | Domain fully populated, IFFT then FFT on the coset. | Same structure; subset handling currently performs barycentric recovery before padding. | 46 | Prover | Coset FFT path, dense available for debugging. | Coset path is default; dense exists only for assertions. Will align fully once domains match. | 47 | Prepared verifier | `PreparedVerifyingKey` batches pairings. | `prepare_verifying_key`, `prepare_inputs`, and `verify_with_prepared` mirror the API. | 48 | Aggregation | Optional `groth16::aggregate_proofs`. | Not yet ported; tracked on the roadmap. | 49 50 ## Upcoming Alignment Tasks 51 52 1. Populate every evaluation domain slot (`num_constraints + num_inputs`) before the IFFT so we can delete the barycentric interpolation helper. 53 2. Mirror arkworks’ domain utilities (cached vanishing evaluations, twiddle reuse) once the layout matches. 54 3. Rebaseline benchmarks after the domain alignment to ensure prover performance stays on track. 55 4. Port proof aggregation only after the core prover is arkworks-aligned. 56 57 Use this page as a checklist whenever behaviour changes—update the tables above as new features land.