bounty: migrate to arkworks ecosystem

[Autoparallel]

Bounty description

This bounty is to replace three crates in the edge-prover that are effectively deprecated or are causing additional friction. The overarching goal is to improve the cleanliness of the edge-prover codebase. A successful PR should net remove lines of code, reduce glue code in edge-frontend, and lose zero functionality. Performance is less of a worry, though a successful PR should also be able to provide changes in performance numbers.

Implementation requirements

Note, this issue is marked with the discussion label, and as such we expect some back and forth discussion on changes for a solution to this issue. Nonetheless, here are the requirements as we have them today.

• Replace in the workspace the use of ff with ark-ff
  • Reasoning: ff is a great crate, but if you look at its history, it is stale and has not seen changes in a while (until VERY recently). See here. Amazingly, the last update was March 9th 2025, but prior to that it was more than two years before a change. Also, other crates such as those to do with ACIR primarily use ark-ff.
• Replace bellpepper with ark-r1cs
  • Reasoning: similarly to the above, bellpepper is a nice crate, but it has also been abandoned. It's a bit more complex than what we need as well. The ark-r1cs alternative is a bit more simple.
  • Another option as well would be to use Pluto's WIP custom-constraints crate.
• Replace halo2curves with ark-ec
  • Reasoning: with the other changes, having to interface between halo2curves and the ark ecosystem would be a bit dirty and unnecessary. We should migrate to the ark ecosystem entirely by this point, so we may as well drop off the halo2curves.
• Is there more...?

Overall, this gives us a chance to work with the arkworks ecosystem which has no FFI as far as I know it. It also is being worked on actively, albeit maybe a bit slowly. Furthermore, and this is important, we can use sonobe as a reference point since they did everything there using the arkworks ecosystem.

Bonus features

There is more that can be done, and the emphasis is entirely on code quality and minimization. It does not directly have to do with this migration, but doing a migration as large as this opens up a good opportunity to do larger scale refactoring. To that end, here are some other generic features of this bounty:

• Reduce trait complexity.
  • The edge-prover codebase (based off of Arecibo) has a fairly tangled web of traits. It makes navigating and working in the repo challenging. In fact, this can really make the Rust analyzer choke.
  • The upshot here is that with a further simplified codebase, iteration on this project in the future becomes far less cumbersome. Your work here in clearing out space will make it a joy for future contributors. Folding is constantly undergoing research with large changes, we should be able to iterate quickly!
• Reduce number of dependencies.
  • Dependencies are inherently a complexity. We have to make sure they are cross-compatible and often times even pin versions or deal with compilation into different targets. Many times a dependency is used for a tiny amount of code, but we are adding many nested packages just to accomplish what is maybe just "extra" or what could be handled by a bit more self-contained code.
• Reduce generality of code.
  • Right now the codebase is highly generalized allowing, for example, different commitment schemes. I don't think we want to completely remove the capability of easily swapping in and out certain components, but the abstractions laid down today are not very admissible to this goal. At this point, it would be smarter to overall reduce the generality and make more succinct and focused code.
• Reduce code redundancy.
  • Redundancy is hard to manage and is by definition unnecessary. Let's remove as much of this as possible.
• Investigate serialization.
  • We had in earlier pull requests introduced a FastSerde trait and implemented it where needed. I'm curious if this is necessary. Arkworks offers its own CanonicalSerialize in the ark-serialize crate. Also, there is rkyv for zero-copy serialization. An issue (bench: rkyv as a (de)serializer #14) proposes benching these implementations together. I would love to see which comes out fastest (most importantly in the WASM context) so that we can potentially drop in a more general serialization library and remove the need for FastSerde (again, if benchmarks demonstrate this is a good idea).

Resources

• Arkworks
• Sonobe

Criteria

For timely submissions of bounties that meet the implementation requirements, a bounty of at least $2500 will be awarded to the contributor. Additional bounty amounts are available and will be rewarded based on the following criteria:

1. Completion of any of the bonus features listed above and/or other bonus features that improve the quality of the submission.
2. Correctness and security: A thorough review of the implementation should convince our team that they are correct and secure, with all requirements met.
3. Code clarity and quality: Succinct, easy-to-follow code with appropriate naming conventions. Utilize Rust’s type system for flexibility and security (e.g., compile-time checks where possible), and avoid external crates. Optimizations should be a lower priority than clarity, but can be included behind a feature flag as a bonus.
4. Documentation quality: Provide comprehensive README’s, Cargo docs, and inline comments where code itself is not self-explanatory. Prioritize clarity and readability.

---

Note: This is Pluto's largest bounty offering yet. This is a serious chance to make progress in folding backends for ZKPs.

[devloper]

send blst to the grave

[mahmudsudo]

Seems interesting , I will love to take on this

[Autoparallel]

@mahmudsudo awesome! I am not going to assign anyone in particular here for a bit and leave this to be an open request for the broader community. I would love to see multiple people work on this and collaborate.

We're all aligned here on the same vision and we'll make sure to reward the contributors properly!