chore: regenerate tinyfield

[ivokub]

Description

Update gnark-crypto dependency and regenerate tinyfield implementation to avoid CI failures due to dirty tree after generation.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

---

Note

Updates gnark-crypto and testify, regenerates tinyfield with new exponent APIs (scalar and vector) and minor ops tweaks, adds empty-slice tests, and annotates BitReverse uses with nolint across backends/templates/tests.

• Dependencies:
  • Bump github.com/consensys/gnark-crypto to v0.19.3-0.20251114....
  • Bump github.com/stretchr/testify to v1.11.1.
• tinyfield regeneration:
  • Add Element.ExpInt64 and route Element.Exp to it for int64 exponents (supports negatives).
  • Add Vector.Exp(a, k int64) for batch exponentiation with negative-exponent handling.
  • Optimize MulBy3 via Double + Add.
• Tests:
  • Add TestVectorEmptyOps ensuring zero-length vector ops don’t panic and return zero.
• Lint/compat tweaks:
  • Annotate fft.BitReverse(...) calls with //nolint:staticcheck in backend/plonk/*/prove.go, GKR gate testing, templates, and test/unsafekzg/kzgsrs.go (backward-compatible API usage).

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

[gbotrel]

was the bitReverse refactor needed because a linter complained the old one is marked Deprecated ?
Asking because I'm not a huge fan of having the package name being utils on gnark-crypto, was planning to revisit before doing a next release so we might have a tiny refactor to re-do.

[ivokub]

was the bitReverse refactor needed because a linter complained the old one is marked Deprecated ? Asking because I'm not a huge fan of having the package name being utils on gnark-crypto, was planning to revisit before doing a next release so we might have a tiny refactor to re-do.

Exactly! https://github.com/Consensys/gnark/actions/runs/17613708150/job/50041471329#step:7:29

I can also nolint tag it.

[ivokub]

And there is no big rush from my side. I wanted to merge Consensys/gnark-crypto#725, but then need #1601 on gnark side to fix some existing tests which assume gnark-crypto current behaviour. And that lead to linter errors which I wanted to fix in this PR.

But the initial issue is still imo great to merge - it allows for compatibility with other ecdsa libs.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	github.com/​consensys/​gnark-crypto@​v0.19.1 ⏵ v0.19.3-0.20251114101102-c7c3213680f8	+1	+20
	github.com/​stretchr/​testify@​v1.10.0 ⏵ v1.11.1	+1

View full report

[ivokub]

@gbotrel - reverted using utils.BitReverse and added nolint instead.

[gbotrel]

why? dependency issue ?

[gbotrel]

lgtm, don't get why we can't use the non-deprecated method in gnark-crypto but it's a quick refactor anyway once we sort all the branches out

[ivokub]

The BitReverse in fft packages is denoted deprecated and recommended using BitReverse in utils package. It made linter complain and I changed to the utils package version. But you noted above that you'll probably refactor the utils package. So I reverted and added nolint instead.

And I need gnark-crypto update to fix ECDSA. But it introduces the changes to code generation which makes tests here (checking code generation) fail.