prove({ prover: newLocalProver() }) is 18-49x slower than prove() with no argument

[Mustdzyl]

Passing a prover to prove() is around fifty times slower than leaving the argument off, for the same transaction.

I hit this while timing proving for an app, and the gap was large enough that I assumed my measurement was wrong. It reproduces on the same request object, in the same page, back to back.

Repro

const script = await client.compile.txScript({
  code: "use miden::core::sys\nbegin\n  push.1 drop\n  exec.sys::truncate_stack\nend\n",
});
const request = new TransactionRequestBuilder().withCustomScript(script).build();

// A — no prover argument
let staged = await client.transactions.executeRequest(account, request);
await staged.prove();

// B — explicit local prover
const prover = TransactionProver.newLocalProver();
staged = await client.transactions.executeRequest(account, request);
await staged.prove({ prover });

Timings on macOS, 8 cores, Chrome 152, @miden-sdk/miden-sdk@0.15.9 single threaded, testnet:

A  prove()                            1925 ms   1267 ms
B  prove({ prover })                209043 ms  62244 ms

A second run on the same setup gave 2940 / 2726 ms for A and 53242 / 49823 ms for B. The later B call is faster than the first in both runs, so this is not degradation over time. The ratio lands between 18x and 49x depending on the run.

Both paths are local. I checked that by pulling the network down after the client was ready and the transaction executed, then calling prove() with no argument: it completed offline in 1742 ms. So the fast path is not delegating to a remote prover.

Where the paths diverge

proveResult in the SDK sends the two cases to different calls, and defaultProver is null unless the app sets one:

const prover = opts?.prover ?? defaultProver;
return prover
  ? await inner.proveTransaction(result, prover)
  : await inner.proveTransaction(result);

The two branches resolve different provers: custom_prover.get_prover() versus client.prover(). newLocalProver() builds LocalTransactionProver::new(ProvingOptions::default()). I could not work out from here what client.prover() resolves to, so I am reporting the measurement rather than guessing at the cause.

This may be the same routing asymmetry described in #312, though that one is about batch() and the main thread, and here both calls go through the worker wrapper.

Why it matters

newLocalProver() reads as the ordinary way to prove locally, and an app that wants local proving will reach for it. Nothing in the README or the API surface suggests the argument changes performance by this much. A note in the docs would help even if the behaviour is intended.

Environment: macOS, Chrome 152, node 24, pnpm 10.18, SDK 0.15.9, testnet.

[Mustdzyl]

I was wrong about the cause here, and the numbers have a plain explanation. Correcting it rather than leaving it open.

for_testnet() in the Rust client configures a remote prover, so the two paths were never comparing the same thing:

pub const TESTNET_PROVER_ENDPOINT: &str = "https://tx-prover.testnet.miden.io";

pub fn for_testnet() -> Self {
    tx_prover: Some(Arc::new(RemoteTransactionProver::new(
        TESTNET_PROVER_ENDPOINT.to_string(),
    ))),

So prove() delegates and prove({ prover: newLocalProver() }) proves locally. A 20 to 50x gap between a network round trip and a real STARK proof is expected, not a defect.

What misled me was a test I trusted too far. I pulled the network down with CDP and prove() still finished in 1742 ms, which I read as proof that the default path was local. Proving runs in a Web Worker, and page level network emulation does not reach the worker, so the call went out anyway. An earlier fetch hook I wrote had the same blind spot for the same reason.

The test that settles it is a bogus prover URL:

await MidenClient.createTestnet({ proverUrl: "https://sahte-prover-yok.invalid" });
// prove() -> 143 ms, TypeError: Failed to fetch

Against the default it takes 1702 ms and succeeds, so the default is reaching a prover over the network.

There is one thing left that I still think is worth something, so I will leave the issue open unless you would rather I close it. None of this is visible from the JS side. createTestnet() reads like a local client, newLocalProver() reads like the ordinary way to prove locally, and nothing at the call site says the default sends the transaction to a service. On a chain whose whole argument is client side proving, a developer choosing between those two is also choosing where their transaction goes, and right now they have to read the Rust builder to find that out. A line in the web client README next to createTestnet() would cover it.

Apologies for the noise on the diagnosis.