perf(rpc): isolate block template construction

[p0mvn]

Problem

getblocktemplate is an async RPC, but its final response was built synchronously on a Tokio async worker by calling BlockTemplateResponse::new_internal directly.

new_internal constructs a coinbase transaction whenever it is not given a usable precomputed coinbase. For shielded miner addresses, that work includes Sapling proof construction and can take seconds. With #291, the first construction in a process can also initialize the shared prover by parsing the bundled Sapling parameters. While this synchronous work runs, the Tokio worker cannot poll unrelated RPC futures, and concurrent template requests can increase async-runtime latency.

The long-poll implementation already uses spawn_blocking when precomputing a provisional coinbase, but final response construction was still synchronous in two cases:

• the normal template response, which always passes None and builds its coinbase inline;
• the tip-change response, where the provisional coinbase is discarded if the predicted height no longer matches, causing new_internal to build a replacement inline.

Solution

Run BlockTemplateResponse::new_internal through tokio::task::spawn_blocking in both final response paths. This moves any coinbase proof generation and first-use prover initialization onto Tokio's blocking pool while the RPC future yields its async worker.

Network and MinerParams are cloned into owned values because a blocking task must own Send + 'static inputs. The remaining response inputs are already owned and are moved into the task. The existing precomputed-coinbase fast path and all response semantics remain unchanged.

This is the separately scoped follow-up to the blocking-RPC concern raised on #277 and is independent of the shared-prover optimization in #291.

Test plan

• cargo fmt --all -- --check
• cargo test -p zakura-rpc --lib methods::types::get_block_template
• cargo clippy -p zakura-rpc --all-targets -- -D warnings

[v12-auditor]

Note

Complete: Audit complete. V12 found one issue worth reviewing.

Open the full results here.

Finding	Severity	Details
F-101584	🟠 High	Unbounded Template Work Exhaustion getblocktemplate is an RPC method when the RPC listener is enabled, and the patched handler now sends both the long-poll tip-change response and the normal template response to tokio::task::spawn_blocking. The RPC server builder installs logging, metrics, tracing, body-size middleware, and cookie middleware, but the inspected code does not add a per-method semaphore or request-concurrency gate before these blocking tasks are scheduled. Once the closure is scheduled it owns the cloned network, miner parameters, chain info, and selected transaction vector, so a client disconnect or request cancellation after the spawn point gives the closure no cancellation signal. The closure runs BlockTemplateResponse::new_internal, which converts selected mempool transactions into templates, can build a coinbase transaction, sums fees, and computes default roots over selected transactions; the surrounding code documents that shielded coinbase construction can take seconds. An RPC client can therefore flood or cancel getblocktemplate calls to accumulate template construction work on the shared blocking pool, and the same pool now also gates the branch that was supposed to return an instant empty template on a chain-tip change.

Analyzed one file, diff 819ef11...3eab659.

[p0mvn]

Blocked on next tag

[evan-forbes]

depending on if the rpc is exposed for non-miners, then we might want to go ahead and fix the exhaustion issue brought up by v12

will defer to author on when, if, and where we do that. could also be a flup