update(idemix): hardening

[adecaro]

This PR introduces idemix hardening.

[github-actions]

📊 Token Validation Benchmark

Comparison of this PR against the base branch. 🟢 improvement · 🔴 regression · ➖ within ±1.0% noise.

Variant	Benchmark	Params	Workers	TPS (base → PR)	Δ TPS
csp	BenchmarkAPIGRPC	f=1, nc=4, w=token-validation-service	4	106 → 96	🔴 -8.7%
csp	BenchmarkLocalTokenValidation	out-tokens=2in-tokens=2	4	135 → 123	🔴 -9.3%
ipa	BenchmarkAPIGRPC	f=1, nc=4, w=token-validation-service	4	78 → 72	🔴 -6.7%
ipa	BenchmarkLocalTokenValidation	out-tokens=2in-tokens=2	4	68 → 64	🔴 -6.5%

[AkramBitar]

LGTM

[adecaro]

waiting for IBM/idemix#89 to get merged

[github-actions]

📊 Token Validation Benchmark

Comparison of this PR against the base branch. 🟢 improvement · 🔴 regression · ➖ within ±1.0% noise.

Variant	Benchmark	Params	Workers	TPS (base → PR)	Δ TPS
csp	BenchmarkAPIGRPC	f=1, nc=4, w=token-validation-service	4	118 → 107	🔴 -9.3%
csp	BenchmarkLocalTokenValidation	out-tokens=2in-tokens=2	4	104 → 94	🔴 -9.4%
ipa	BenchmarkAPIGRPC	f=1, nc=4, w=token-validation-service	4	78 → 73	🔴 -6.6%
ipa	BenchmarkLocalTokenValidation	out-tokens=2in-tokens=2	4	76 → 71	🔴 -6.8%

[Effi-S]

See:
From: https://github.com/IBM/mathlib/blob/v0.3.1/driver/gurvy/bls12381/bls12-381.go#L259-L263

// Mul2 computes [e]g + [f]Q via a joint Strauss-Shamir scalar multiplication.
// Benchmarked against two independent Mul calls plus an Add: allocates far less
// (1 vs ~26 allocs) but is not faster in wall-clock time, because — unlike Mul —
// it does not use the GLV endomorphism speedup, so it forgoes the ~2x speedup that
// GLV gives each individual scalar multiplication.

[Effi-S]

[Effi-S]

Hi @adecaro,

Please see the full benchmarking results (Both CSP/IPA Client-Server Token Validation)
There is a clear degradation introduced by the newer mathlib version .

What do you think?

How do you want to proceed?

[aaadir]

"Token Validation Benchmark" also shows a performance degradation, so unless the new mathlib fixes some bugs - then why would we want to take it?

I also recall when working on the proof optimization that Claud claimed that mathlib (I guess that would be the current version) computed addition with 0 just like any other addition, rather than a trivial nop. This was one of the reasons why the optimization could exploit the 0-padded witness and field values. Now that the optimization is committed, I'm not sure there are many other places that would benefit from a trivial add-0, but may be worth an investigation.