feat: add grumpkin curve support

[yelhousni]

Description

This PR adds support for the Grumpkin curve (ecc.GRUMPKIN) in gnark. Grumpkin is an elliptic curve defined over the BN254 base field, commonly used in folding schemes (e.g. Nova, HyperNova) and cycle-of-curves constructions.

Changes

Constraint System

New curve-typed constraint system implementation (R1CS and SparseR1CS):

• constraint/grumpkin/ — coefficient table, marshal, solver, system backed by gnark-crypto/ecc/grumpkin/fr

Frontend Builders

frontend/cs/r1cs/builder.go and frontend/cs/scs/builder.go dispatch to the new Grumpkin constraint system when the target field matches ecc.GRUMPKIN.

Witness

backend/witness/vector.go handles Grumpkin field elements in witness encoding/decoding.

Curves Registry

doc.go — ecc.GRUMPKIN added to gnark.Curves().

Type of change

• New feature (non-breaking change which adds functionality)

How has this been tested?

go test -short ./constraint/grumpkin/...
go test -short ./frontend/...
go test -short ./backend/witness/...

Also tested end-to-end with a circuit compiled over ecc.GRUMPKIN (native BN254 map-to-curve).

Checklist

• I have performed a self-review of my code
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Dependent gnark-crypto Grumpkin packages are available

---

Note

Medium Risk
Adds a new curve-typed constraint system and solver/serialization path for ecc.GRUMPKIN, which touches core proving inputs (witness encoding) and constraint solving logic. Risk is mainly around correctness/compatibility of the new field-specific implementations and dispatching by modulus.

Overview
Adds Grumpkin (ecc.GRUMPKIN) support end-to-end by introducing a new constraint/grumpkin implementation (coeff table, solver, and marshal/system glue) backed by gnark-crypto/ecc/grumpkin/fr.

Updates witness handling (backend/witness) and frontend builders (frontend/cs/r1cs and frontend/cs/scs) to recognize the Grumpkin scalar field modulus and route vector allocation/serialization and constraint-system construction accordingly.

Extends generic field-type selection (constraint/FitsElement) to accept the Grumpkin modulus, and updates the backend generator to include Grumpkin codegen metadata while skipping autogenerated tests via a new NoTests flag.

^{Written by Cursor Bugbot for commit 8ee6053. This will update automatically on new commits. Configure here.}

[ivokub]

@yelhousni - can you explain why we would need these frontend implementations in gnark? Usually for large-field case (i.e. grumpkin) we want to be able to prove the circuit in PLONK/Groth16, but afaik Grumpkin is not proving friendly?

And Goldilocks would just be super inefficient, our constraint.U64 is actually [6]uint64 to fit all supported scalar fields of the supported backend curves. And again, we wouldn't have a backend for it. For other small field backends the goal is that we can compile the circuit and then embed it in Vortex circuit which works over small fields, but Vortex is not configurable to work with Goldilocks.

Unless you have some interesting ideas using folding etc. to have new backends, then I don't currently see the benefit of adding support for new curves for compiling the circuits.

[yelhousni]

Member

@yelhousni - can you explain why we would need these frontend implementations in gnark? Usually for large-field case (i.e. grumpkin) we want to be able to prove the circuit in PLONK/Groth16, but afaik Grumpkin is not proving friendly?

And Goldilocks would just be super inefficient, our constraint.U64 is actually [6]uint64 to fit all supported scalar fields of the supported backend curves. And again, we wouldn't have a backend for it. For other small field backends the goal is that we can compile the circuit and then embed it in Vortex circuit which works over small fields, but Vortex is not configurable to work with Goldilocks.

Unless you have some interesting ideas using folding etc. to have new backends, then I don't currently see the benefit of adding support for new curves for compiling the circuits.

I need this for some bn254/grumpkin constraints benchmarks, but I'll how I can do that cleanly.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[ivokub]

In principle looks good. But why not use code generation in internal/generator/backend? For example following configuration would work and generate the same thing:

	grumpkin := templateData{
		CSPath:      "../../../constraint/grumpkin/",
		Curve:       "Grumpkin",
		CurveID:     "GRUMPKIN",
		noBackend:   true,
		NoGKR:       true,
		ElementType: "U64",
	}

[ivokub]

To avoid generating the tests which would fail imo we could just check if the curve is in gnark.Curves() and then omit generating the test file. Imo that list is a good list of "supported curves" and we could consider everything out of that as experimental.

[ivokub]

Looks good now! Thanks!