Use dynamic prime field with modulus sampled at runtime

[frozenspider]

Resolves #136

Introduce DynField, a field with $\le 126$ bit modulus that is squeezed from Fiat-Shamir transcript after the commitment and statement are bound. Number of bits to use in this prime depend on the claim shape.

A lot of code is shared with Fq, this shared code has been moved to a new helpers module.

This field relies on a globally shared modulus, and on an assumption that nobody would change that while field elements still exists. This convention is sadly not enforced by the type system.
[Remark: We could avoid this problem completely by passing around FieldConfig, but that's a bit cumbersome]

To sample a random prime, we use small prime numbers table sieve, followed by Miller-Rabin primality test, based on the PoC repo implementation.

E2E performance is quite close to static field, and can be optimized further. This is notable given that P/V can no longer do prime projection at the setup phase (setup got a bit faster).

Notable tricks used:

• Constraint matrices A, B, C are now prepared in two stages, integer ones are prepared in the setup as before, and P/V project them onto a field after the prime is drafted.
• When used this way, constraint matrices are hashed in their integer forms.
  • It's still possible to construct constraint matrices with field elements from the start, in this case field elements are hashed as before.
• Constraint matrix coefficients are now stored as flat Vec<_>, with Layout specifying the sparse matrix layout.
• BigInt to Field projection has been optimized for u128-wide cases (in practice - pretty much all of them)

Performance

To measure performance, I used a circuit sha256-2kb

RUSTFLAGS="-C target-cpu=native" cargo run --release -p bitz-cli -- circuit-e2e --circuit sha256-2kb

Circuit sha256-2kb	Static 121-bit	Dynamic 121-bit
Setup	~370 ms	~350 ms
Prove	~130 ms	~150 ms
Verify	~55 ms	~65 ms

Notes:

• SHA-256 does not technically need a random prime for soundness
• In the main branch we normally use Fq<Q100>, a 100-bit prime. To make it comparable, I used Fq<2230695117703373733444658220249201783>

[zkfriendly]

The PR looks well structured overall. Cross-checked everything with the PoC repo and left some comments regarding correctness and soundness. Other stuff looks good (Prime candidate sampling, width selection, and verification look correct and compatible with bounds we have. Wide mul and Barret reduction look correct too.)

[zkfriendly]

This may not actually be safe. Main reason is the global modulus can change (through prove and verify for example) and then doing arithmetic on values that remain accessible could result to an overflow:

For example, x = 100 is valid modulo 101. After changing the modulus to 3:

x += x:  100 + 100 - 3 = 197
x += x:  197 + 197 - 3 = 391
x += x:  391 + 391 - 3 = 779

Eventually, x could overflow!

[zkfriendly]

The PoC explicitly validates the case that a value from a larger prime fits. Worth having that check here too: https://github.com/albert-garreta/BitZ-PoC/blob/8ced3b985a188e9ffb03d2550737cbb4a7345f2b/src/piop/spartan/piop.rs#L1254

[zkfriendly]

These binds are not enough; My test changed integer coefficients while preserving earlier transcript inputs; the sampled prime stayed unchanged.

This PR currently follows:

Commitment + public bytes → choose prime q → absorb matrix digest → Spartan

which means we sample the prime before binding integer coefficients, instead as in the PoC repo we need to do this:

Commitment + public bytes + matrix digest → choose prime q → Spartan

Basically here we need to add this too:

transcript.public_message(self.matrices.digest());

[zkfriendly]

Here, similar to PoC we could only project distinct coeffs, for example, our 32-block SHA fixture contains 1,785,960 entries but only 133 distinct coefficients. we could defer this to optimisations