Make new_mint_transaction(), new_send_transaction(), and new_consume_transaction() automatically use delegated proving if available

[partylikeits1983]

Feature description

Description
Currently, to leverage delegated proving in the web client, you must manually craft and submit a custom transaction via submit_transaction_with_prover(). Reference

This process is cumbersome because it involves building a TransactionRequest from scratch in the browser if you want to use delegated proving.

It would be more user-friendly if the existing functions (new_mint_transaction(), new_send_transaction(), new_consume_transaction()) could automatically detect and use delegated proving when the client is initialized with a delegated proving URL. However, the recently merged webWorker PR no longer initializes the client with a remote_prover_endpoint, so not 100% what would be the best approach now.

---

What is happening now?

• The only way to submit a transaction with delegated proving is by creating a custom transaction and calling submit_transaction_with_prover() directly.

---

Proposed Solution

• In each function that currently calls .submit_transaction(), add a simple check to see if a delegated proving endpoint is defined.
  • If no delegated prover is configured, continue using the standard .submit_transaction().
  • If a delegated prover is available, switch to calling .submit_transaction_with_prover().
• This way, the same intuitive functions (new_mint_transaction(), new_send_transaction(), new_consume_transaction()) can seamlessly handle delegated proving without additional user intervention.

---

Why is this important?

• Improves developer experience: Gets rid of the requirement to build a transaction from scratch.
• Reduces code duplication: The same high-level functions will handle both standard and delegated proving modes.
• Makes delegated proving usage more accessible and straightforward.

---

Possible Implementation Steps

1. Update new_mint_transaction(), new_send_transaction(), and new_consume_transaction() to check for a delegatedProverURL (or similar config) in the client.
2. If the URL is present, construct the transaction normally but pass it into .submit_transaction_with_prover().
3. If the URL is absent, default to .submit_transaction().
4. Ensure any needed error handling or logging is in place.

---

Additional Context

• This issue was raised because the current workflow is clunky: “the only way to use delegated proving is by crafting custom txs in the browser which means manipulating MASM in plaintext in TS.”
• A draft PR can be opened if this approach is confirmed as the correct path.

---

Please let me know your thoughts. If this sounds good, I can open a draft PR to illustrate the changes.

Note:

Previous versions of this issue mentioned manipulating MASM in the browser. Sort of mixed things up, that is because the create_p2id_note() function in the webClient hasn't been pushed to NPM, and I was testing the 1 to N transfer (which requires MASM strings in TS) with delegated proving.

[bobbinth]

@dagarcia7 - this may have been fixed in #720? But if not, is this something we could address for v0.7.1 release?

• If no delegated prover is configured, continue using the standard .submit_transaction().
• If a delegated prover is available, switch to calling .submit_transaction_with_prover().

I think one of the things we wanted to do is let the user chose if they want to use delegated proving or not on per-transaction basis. Maybe there is an argument that can be passed to these methods to indicate whether to use delegated proving or not?

[igamigo]

I think what @partylikeits1983 is referring to would apply specifically for transaction helpers such as new_consume_transaction(), new_mint_transaction() and new_send_transaction(). These APIs probably exist from when the web client was more closely following the CLI rather than the library.

Currently the API exists for submitting transactions with a prover, but only for user-built transaction requests.

A good workaround could be to have these transaction helpers return a TransactionRequest which the user could then execute and submit as they preferred? This is the way it sort of works now (eg, TransactionRequestBuilder::mint_fungible_asset() returns a builder that you can build into a transaction request and then execute).

[SantiagoPittella]

I like @igamigo ;s approach, using the existing new_*_transaction() methods just as a builder, and then calling "externally" to submit_with_prover.

Also, we might want to consider returning to dyn TransactionProver in the client, allowing the user to set the default prover.

[partylikeits1983]

I think what @partylikeits1983 is referring to would apply specifically for transaction helpers such as new_consume_transaction(), new_mint_transaction() and new_send_transaction(). These APIs probably exist from when the web client was more closely following the CLI rather than the library.

Yes. The functions new_consume_transaction(), new_mint_transaction() and new_send_transaction() are extremely useful abstractions for web applications. Being able to use them with delegating proving means Miden webapp developers can streamline their code.

A good workaround could be to have these transaction helpers return a TransactionRequest which the user could then execute and submit as they preferred?

Would this look something like this in TypeScript:

let delegated_prover_url = "http://18.118.151.210:8082";
let tx_request = await client.new_consume_transaction(
  AccountId.from_hex(aliceIdHex),
  mintedNoteIds,
);
await client.submit_transaction_with_prover(tx_request, delegated_prover_url);

The only thing is that new_consume_transaction() already calls submit_transaction() here:

miden-client/crates/web-client/src/new_transactions.rs

Line 222 in 0e5bbba

client.submit_transaction(consume_transaction_execution_result).await.map_err(

[igamigo]

A good workaround could be to have these transaction helpers return a TransactionRequest which the user could then execute and submit as they preferred?

Would this look something like this in TypeScript:

let delegated_prover_url = "http://18.118.151.210:8082";
let tx_request = await client.new_consume_transaction(
  AccountId.from_hex(aliceIdHex),
  mintedNoteIds,
);

await client.submit_transaction_with_prover(tx_request, delegated_prover_url);
The only thing is that new_consume_transaction() already calls submit_transaction() here:

miden-client/crates/web-client/src/new_transactions.rs

Line 222 in 0e5bbba

client.submit_transaction(consume_transaction_execution_result).await.map_err(

Yes, that's about what I was referring to and agreed, we would have to remove the client.submit_transaction() from the helpers themselves.

[partylikeits1983]

That is a really good approach as it keeps things clean.

Calling

await client.submit_transaction(transaction_request);

or

await client.submit_transaction_with_prover(transaction_request, delegated_prover_url);

after creating the TransactionRequest that would be returned by the new_mint_transaction(), new_send_transaction(), new_consume_transaction(), and new_swap_transaction() helper functions is actually better than the current approach where transaction submission is a bit hidden.