Field-agnostic prover: extract provekit-field-bn254 + provekit-noir

[BornPsych]

Summary

Makes the proving spine (provekit-common, provekit-prover, provekit-verifier) field-agnostic and moves all bn254-specific code into a new provekit-field-bn254 crate. The Noir/mavros frontend moves into a new provekit-noir crate. bn254 output is unchanged from v2.

The field is now chosen by which crate a binary depends on, not by a Cargo feature. The spine names no concrete field; a binary links the one field crate it registers. Adding a field is a new crate plus a register() call.

This is the first of two PRs, both targeting v2. It has no Goldilocks code; the Goldilocks crate comes in the follow-up.

Why a runtime registry

The orphan rule blocks impl SomeTrait for ark_bn254::Fr from living in provekit-field-bn254 (it can only live in the trait's crate or in arkworks). So instead of a per-field trait impl, common exposes a FieldHashProvider registry, the same mechanism whir uses for its ENGINES/NTT registries. provekit_field_bn254::register() installs the provider and engines at startup, and the spine looks them up at runtime.

What changed

• common: field-agnostic spine; new FieldHashProvider registry and DynFieldSponge; FieldElement derived from a single Identity<Fr> instantiation point; drops the ntt/poseidon2/skyscraper deps.
• provekit-prover: generic WHIR engine, no field/acir/nargo deps.
• provekit-verifier: field-agnostic; the caller registers the backend.
• provekit-field-bn254 (new): Skyscraper/Poseidon2/NTT, the EC/bigint/witness-hint code, the FieldHashProvider impl, and register(). The bn254 public-input KATs live here.
• provekit-noir (new): the Noir/mavros Prove impls, witness solving, and input glue.
• Tooling (cli/ffi/bench/wasm) rewired to provekit-noir; standalone-verify paths and pk_init call register().

Verification

• e2e compiler suite: 73/73 pass.
• Field KATs, relocated unit tests, and MSM witness-solving tests pass.
• cargo tree: common, prover, and verifier link no field crate.
• bn254 is unchanged from v2: the R1CS-construction path has an empty diff against v2, and a regression test in provekit-bench pins basic-4's R1CS hash and proof-structure params.

WHIR ZK proofs use thread_rng blinding and are non-deterministic by design, so the regression test pins deterministic artifacts and checks proofs functionally rather than byte-comparing them.

Follow-ups (not blocking)

• The Noir scheme structs still live in common, so common/prover keep the acir/mavros deps. This is the frontend axis (Noir is bn254-only) and is independent of the field work here.
• The relocated bigint/EC/NTT code carries pre-existing clippy warnings (same as on v2); a focused cleanup is a separate task.

[vercel]

@BornPsych is attempting to deploy a commit to the World Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[shreyas-londhe]

Solid carve. Verified bn254 is byte-identical to v2: the boxed sponge forwards to the same DuplexSpongeInterface calls, and the public-input KATs were moved verbatim, not regenerated. Hash-via-registry is the right call too. whir dispatches its own Merkle hashes through ENGINES/EngineId, and hash config is runtime data, so a registry fits.

One architectural gap holds this back as a base for the Goldilocks work, plus a few panics to clean up.

Make the algebra generic over Embedding. Field-agnostic hashing isn't enough.

The spine still pins one concrete FieldElement (common/src/lib.rs: ProvekitEmbedding = Identity<Fr>, FieldElement = ::Source) and uses it for both committed data (coeffs/w1/w2 in interner.rs, r1cs.rs, sparse_matrix.rs) and challenges (verifier/src/whir_r1cs.rs). Goldilocks needs those to be different types: committed data in M::Source (base, Field64), challenges in M::Target (ext, Field64_3). A single alias can't carry both. So the flip to Basefield<Field64_3> re-threads the whole spine anyway, and the Identity-vs-Basefield differential test is impossible, since one global alias plus a one-slot provider can't hold two fields in one binary.

The fix is additive:

• Keep the hash registry. whir does the same.
• Make the math (sumcheck, covectors, sparse-matrix) generic over <M: Embedding>. Committed data becomes M::Source, challenges M::Target, base×ext products go through mixed_mul/mixed_dot. Instantiate Identity<Fr> for bn254; output stays byte-identical.
• whir::Config<M: Embedding> is already generic, so this matches the dep. Our wrappers calling whir want the same M.

This is how the references layer it. whir: Config<M> for algebra, separate ENGINES registry for hashing. Plonky3: StarkGenericConfig bundle at the prove/verify entry, AIR and field math generic over F: Field underneath. None of arkworks, whir, or Plonky3 put a hash method on the field trait.

The earlier impl ProofField for Fr hit the orphan rule (E0117: both the trait and Fr are foreign to field/bn254), which is why the registry replaced it. Fine. If a per-field trait comes back later, impl it for a local marker (struct Bn254; impl ProofField for Bn254 { type Embedding = Identity<Fr>; }), same as arkworks FrConfig, Plonky3 BabyBearParameters, whir's own FConfig64. The math doesn't need that trait though. Generic over Embedding is leaner.

Panics in library paths. Fix before merge.

• common/src/field/mod.rs: provider() is .expect(), so every Skyscraper/Poseidon2 path panics if register() wasn't called. Return a Result and propagate.
• verifier/src/lib.rs: verify() dropped self-registration. A verify-only caller that skips register() panics. Tests survive only because the prover registers first in-process. Re-register or return Err.
• field/bn254/src/lib.rs: field_sponge() is unreachable!() on non-native configs, but it's a public trait method. Narrow the input type or return Option.
• common/src/field/mod.rs: register_field_hash_provider does let _ = OnceLock::set(...), silently dropping a conflicting second registration. Once a second field crate exists that's a silent wrong-field bug. debug_assert! or panic on conflict.

Scope. Ship this as the modularization plus hash registry. That part's good. Track the Embedding genericization as the next PR. That's the piece that carries base/ext.