Migrate backend to Plonky3

[Al-Kindi-0]

This PR replaces Winterfell with Plonky3 as the STARK proving backend.

What Changed

STARK Backend: Removed all Winterfell dependencies (winter-air, winter-prover, winter-verifier) and integrated Plonky3. The VM now uses 13 core Plonky3 crates plus 4 custom Miden extensions from github.com/0xMiden/p3-miden.

Hash Functions: Added support for multiple hash functions with runtime selection. Users can now choose between Blake3, Keccak, RPO256, Poseidon2, and RPX256 for proof generation.

Constraint System: Deleted ~7,900 lines of explicit constraint code. Constraints are now expressed using Plonky3's builder pattern via the MidenAirBuilder trait from p3-miden-air.

Metal GPU Support: Removed Metal acceleration code (~1,000 lines) as Plonky3 doesn't support it.

Dependencies: Updated miden-crypto to a Plonky3-compatible branch (huitseeker/p3-rebased).

Notes

• Supersedes (wip) migrate plonky3 #2258 and Full integration of 0xMiden/Plonky3 with Miden VM #2467 (rebasing was impractical due to divergence)
• Minimum trace length increased to 2048 due to current FRI implementation
• Blake3 uses binary folding (log_folding_factor=1) to avoid verification issues
• Blake3_192 support pending (needs Plonky3 upstream changes)
• base miden-crypto PRs: Plonky3-rebased (alternate) crypto#720 and Re-organize top-level crate exports crypto#736

[plafer]

Trace length goes from 64 to 2048; is this because Plonky3 requires a trace length minimum of 2048? Is this the only thing that changed otherwise with trace generation?

[Al-Kindi-0]

Indeed, the minimal trace length has changed to 2048. This is due to some short-comings of the current FRI implementation, which should hopefully be resolved soon.

[Al-Kindi-0]

Also related to trace gen, we now do not insert randomness in the final NUM_RAND_ROW rows

[adr1anh]

Wow! This is really amazing work. I left a few comments around which should be relatively easy to address.

• We should try to use plonky3's inversion and transposition
• We should run clippy to fix some formatting (unused parentheses)
• Some changes can likely be reverted and seem to be residues of merges.

[adr1anh]

Is this leftover? I dont think Field has as_int

[Al-Kindi-0]

No, but we needed something similar in other places that is const. Removed it from here and everywhere else where we don't need the const-ness. There is only one place where we need const-ness, which we can address later once we work on removing our dependence on p3-miden-goldilocks.

[adr1anh]

was the - 1 accidentally removed?

[Al-Kindi-0]

It seems the the real expression was total_program_rows + NUM_RAND_ROWS - NUM_RAND_ROWS. So the expression as it stands now is correct.

[adr1anh]

The last commit aims to minimize the diff, even though there are some regressions.

• We can make StackInputs and StackOutputs Copy
• Revert renaming of field precompile_requests → pc_requests in ExecutionProof

Before merging, I'd like to take a look at all usage of inverse and make sure that we shouldn't instead use .try_inverse().unwrap_or(Felt::ZERO)

[adr1anh]

I think we should get plonky3 to make BinomialExtensionField::new public

[Al-Kindi-0]

I think we should get plonky3 to make BinomialExtensionField::new public

Agreed

[Al-Kindi-0]

The last commit aims to minimize the diff, even though there are some regressions.

* We can make `StackInputs` and `StackOutputs` `Copy`

* Revert renaming of field `precompile_requests` → `pc_requests` in ExecutionProof

Should we create an issue to track, at least, the first item ?

Before merging, I'd like to take a look at all usage of inverse and make sure that we shouldn't instead use .try_inverse().unwrap_or(Felt::ZERO)

Did a pass to check that but would be good if you can do that as well.
One thing is when inverting random extension field elements, and I think that it is maybe better to panic there as this is a very rare event. Though maybe there are better solutions here.

[adr1anh]

• We can make StackInputs and StackOutputs Copy

Should we create an issue to track, at least, the first item ?

Done in #2487

Before merging, I'd like to take a look at all usage of inverse and make sure that we shouldn't instead use .try_inverse().unwrap_or(Felt::ZERO)

Did a pass to check that but would be good if you can do that as well. One thing is when inverting random extension field elements, and I think that it is maybe better to panic there as this is a very rare event. Though maybe there are better solutions here.

I also checked and it seems good, and I agree about the inverses for the auxiliary column building. I did add 30c9c7d which adds an .expect("...") for the FRI fold instructions. It was mainly to note them down, but from a quick glance this might still panic given a wrong poe value. We should probably return an error instead.

[Al-Kindi-0]

I also checked and it seems good, and I agree about the inverses for the auxiliary column building. I did add 30c9c7d which adds an .expect("...") for the FRI fold instructions. It was mainly to note them down, but from a quick glance this might still panic given a wrong poe value. We should probably return an error instead.

That is a good idea.

[huitseeker]

Jotting down another find while working on miden-base: The debug-types crate in this branch has this:

miette = { package = "miden-miette", version = "8.0", default-features = false }

Even with default-features = false, miden-miette enables its own internal defaults. Those defaults include fancy-no-backtrace, which pulls in terminal_size.

Note: This works fine on origin/next with Winterfell VM. The issue is specific to the P3 VM branch origin/al-migrate-p3-ver2.

A fix: use the fancy-no-syscall feature. It was made for this case.

- miette = { package = "miden-miette", version = "8.0", default-features = false }
+ miette = { package = "miden-miette", version = "8.0", default-features = false, features = ["fancy-no-syscall", "derive"] }

---

Edit: fixed

[bobbinth]

Looks good! Thank you! I left some more comments above. We could probably address the simple ones in this PR, but for anything that requires non-trivial amount of work, we should create follow-up issues.

[bobbinth]

All looks good! Thank you! I pushed one last commit removing some more unused dependencies. But other than that, I think this should be good to go.