Repository navigation
perf(crypto): optimize bn128 arithmetic and subgroup checks - #64
Federico2014 wants to merge 4 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 7 files
Reply with feedback, questions, or to request a fix.
View guided diff | Turn on auto-fix | Re-trigger cubic
Replace the full-order G2 subgroup multiplication with the equivalent BN Frobenius criterion and preserve the infinity fast path. Remove the duplicate Fp6 non-residue, document the extension parameters, and reuse specialized Fp2 constant multiplication throughout Fp6/Fp12. Add full-order subgroup oracles, cofactor torsion rejection, sparse and cyclotomic arithmetic regressions, and precompile invalid-point coverage.
Federico2014
changed the title
What does this PR do?
Optimizes BN128 field arithmetic and G2 input validation:
Fp2.squared(),mul(),inverse(), and multiplication by9+i; corrects its documentation and diagnostictoString()to usea+bi.Fp6.NON_RESIDUE, and reusesFp2.mulByNonResidue()throughoutFp6andFp12. Documents that the Fp2 helper multiplies by9+i, while the Fp6 helper multiplies byv, withv^3=9+i.Why are these changes required?
The fixed BN128 parameters permit equivalent arithmetic with fewer BigInteger multiplications. The G2 subgroup check runs for every decoded pairing term and can exploit the existing twist endomorphism.
For
z=4965661367192848881andpsi=mulByP, the criterion is[z+1]P + psi([z]P) + psi^2([z]P) = psi^3([2z]P)(paper, Sections 3 and 5.1). On this sextic twist,g(psi)=0forg(X)=X^4-X^2+1; the integer resultant ofgandf(X)=z+1+zX+zX^2-2zX^3is exactlyr. The resulting integral Bezout identity excludes additional torsion in the acceptance set. Conversely,psi=[p]on G2 andf(p)=0 mod r.This PR has been tested by:
Follow up
Historical replay, mixed-version producer/validator testing near CPU deadlines, and ARM64/JDK17 performance measurements remain pending.
Extra details
Compatibility and consensus
The intended point acceptance set, coordinate validation, input encoding, binary results, public method signatures, and Energy pricing are unchanged.
Fp2.toString()intentionally corrects diagnostic text; protocol serialization does not use it. The removed Fp6 constant is internal to a package-private implementation.Faster execution can change outcomes near local CPU deadlines. Signed-block replay has configurable CPU allowances, retry, and receipt matching, but an older validator can still reject a result it cannot reproduce within its allowance. No deterministic arithmetic or validation-rule change was identified; mixed-version timeout compatibility has not been fully validated.
Performance comparison (final combined implementation)
Baseline:
release_v4.8.3at409a33f21e6341e31dff5a6341f34f6d0b212d50. Final source tree:273858d778a1519f9639c28a0c152a074f0ba9f1. Host: Intel i7-9750H, macOS x86_64, Oracle JDK 1.8.0_221, 512 MiB heap, Parallel GC,-Xbatch.Three fresh JVMs compared isolated baseline/final runtimes after warmup, using five paired rounds with alternating order and varied inputs. All zksnark classes were overridden together; the remaining runtime was identical. Input/output corpus hashes matched across both variants and all forks. Source hashes were recorded and the published Git tree was verified against the staged, tested tree.
Before/after are medians of per-JVM median latencies. Reduction is the median of within-JVM paired reductions, so it is not the ratio of the displayed medians.
Pairing improved in all three JVMs. Allocated bytes/op decreased by 26.19%, 36.29%, 38.49% for 1/2/4 terms. Addition and multiplication use Fp and serve as controls; their allocations were identical. Individual multiplication control timings varied by roughly -10% to +6%, indicating host noise. The host had background activity, so absolute timings should not be compared with the earlier Fp2-only run.
These are single-host, warmed
execute()measurements including decoding and subgroup checks, rather than transaction TPS or Energy reductions. The table replaces the earlier Fp2-only measurements. Benchmark tooling and raw data remain outside the PR.