Skip to content

Conversation

@huitseeker
Copy link
Contributor

@huitseeker huitseeker requested a review from bobbinth December 30, 2025 03:41
Update project dependencies to use Plonky3-based miden versions:
- miden-crypto v0.20
- miden-vm from github.com/0xMiden/miden-vm (branch al-migrate-p3-ver2)
- miden-base from github.com/0xMiden/miden-base (branch huitseeker/update-miden-deps-p3)
- Add miden-core git dependency

Fix breaking API changes:
- Replace StarkField::MODULUS with PrimeField64::ORDER_U64
- Remove FieldElement imports (no longer exported)
- Change Felt::ZERO/ONE to ZERO/ONE constants
- Update MMR proof field access to use methods (.forest(), .merkle_path())
- Add missing LargeSmtError enum variants (RootMismatch, StorageNotEmpty)
- Replace ExecutionProof::new_dummy() with struct construction
- Handle HashFunction type conflicts from aliased git repos using transmute
…ntime detection

The miden-vm prover's prove_sync() method detects when it's called from
within a Tokio runtime and panics, recommending to use the async prove()
method instead. Even tokio::task::spawn_blocking() still runs within the
Tokio runtime context and triggers this check.

Changes:
- Wrap Prover enum's Mutex types in Arc to allow cloning
- Use std::thread::spawn() instead of spawn_blocking() for prove_tx
- Use tokio::sync::oneshot channel to communicate result back to async context
- This allows the sync prove() call to run outside Tokio's runtime detection

The prove_batch and prove_block methods remain unchanged as they are
synchronous and not called from async context in the same way.

Fixes the test_prove_transaction test failure.
- Change try_from to from for infallible u64 to Felt conversions
- Add clippy::missing_transmute_annotations allow for HashFunction transmutes
- Remove unused miden-air dependency from stress-test crate
- Remove let-and-return pattern in test utilities

These are cleanup items from the new miden dependencies that have
stricter type conversions and new clippy lints.
@Mirko-von-Leipzig Mirko-von-Leipzig added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Jan 9, 2026
@Mirko-von-Leipzig Mirko-von-Leipzig force-pushed the huitseeker/update-miden-deps-p3 branch from cc92a33 to e24d83d Compare January 9, 2026 10:49
@Mirko-von-Leipzig
Copy link
Collaborator

I've rebased, stress-test is failing though - @SantiagoPittella could you see if you could resolve it? Or if its a bug/issue in the protocol branch.

@SantiagoPittella
Copy link
Collaborator

Sure, I'm taking a look.

@SantiagoPittella
Copy link
Collaborator

I think the error comes from some changes in miden-crypto, in particular with the changes of get_leaf in 0xMiden/crypto#691 . In:

  if self.smt.get_leaf(&id_key).is_ok() {
      return Err(DuplicateIdPrefix);
  }

With the old impl we were checking if leaves.contains_key(leaf_index) and that returned error, which made the mentioned check to succeed.
With the newer version get_leaf walks down the tree from root and one of the account is in one of those empty subtrees and that returned Ok(...), making above's check to fail and return the duplicated prefix error.

I think this probably will arise too when using the network monitor, but currently has this error at start up:

2026-01-09T13:59:56.063596Z ERROR network_monitor.tasks.spawn_ntx_service:deploy-counter-account:prove_program_sync: miden_node_utils::logging: crates/utils/src/logging.rs:75: panicked at /Users/spittella/.cargo/git/checkouts/miden-vm-c752872632350e49/f2dac9e/prover/src/lib.rs:160:13:
Cannot call prove_sync from within a Tokio runtime. Use the async prove() method instead., panic: true

cc @Mirko-von-Leipzig

@huitseeker
Copy link
Contributor Author

Ah, I can help there.

The tokio failure you're seeing is discussed in 0xMiden/miden-vm#2501, and the issue is you're trying to call a sync API that starts a runtime from another runtime. The processor's main API has changed to be async (PoC: @plafer) and these *_sync wrappers are planned to undergo a few changes (see sub-issues of the above). The simplest fix is to call the async APIs, and handle the block (or spawn, according to your preference) on your side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no changelog This PR does not require an entry in the `CHANGELOG.md` file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants