fix: replace blocking-in-async ops in validator, remote prover, and ntx-builder#2041
Open
Ollie202 wants to merge 8 commits into0xMiden:mainfrom
Open
fix: replace blocking-in-async ops in validator, remote prover, and ntx-builder#2041Ollie202 wants to merge 8 commits into0xMiden:mainfrom
Ollie202 wants to merge 8 commits into0xMiden:mainfrom
Conversation
…wn_blocking/block_in_place Proof verification, VM execution, local signing, and local proving are CPU-bound operations that were running directly on Tokio worker threads, stalling the async runtime. Wraps them in block_in_place or spawn_blocking to isolate blocking work from the async executor. - validator: wrap proof verification and VM execution in block_in_place - validator: wrap local SecretKey signing in block_in_place - remote-prover: wrap LocalBatchProver::prove in spawn_blocking - remote-prover: wrap LocalBlockProver::prove in block_in_place Closes 0xMiden#1976
Mirko-von-Leipzig
requested changes
May 4, 2026
Collaborator
Mirko-von-Leipzig
left a comment
Mirko-von-Leipzig
left a comment
There was a problem hiding this comment.
Please don't use block_in_place
Replaces all uses of tokio::task::block_in_place with spawn_blocking across the validator and remote-prover crates, as requested in review. spawn_blocking is preferred because it works with both multi-threaded and current_thread runtimes (including #[tokio::test]). For the TX executor which uses an async API that may not yield, a dedicated current_thread runtime is created inside the spawn_blocking closure to drive the future to completion.
Author
On it👍🏻 |
Ollie202
changed the title
LocalTransactionProver::prove generates a ZK proof which is CPU-intensive and does not yield. Wrap it in spawn_blocking with a current_thread runtime when no remote prover is configured.
The filter_notes and execute steps call executor.execute_transaction / NoteConsumptionChecker.check_notes_consumability, which are CPU-intensive and may not yield between await points. Move data-store creation + filter + execute onto a dedicated blocking thread via spawn_blocking. Use Handle::current().block_on() (not a new runtime) so that the gRPC data-store callbacks made by the VM are driven by the existing I/O driver on the parent runtime threads.
Author
|
Updated across three commits -- ready for re-review: Mirko (@Mirko-von-Leipzig): All Krisztian (@kkovaacs): The PR now covers all the blocking-in-async areas from #1976 except the store (which is in #2008):
The only remaining item is store RocksDB blocking ops, already tracked in #2008. |
kkovaacs
reviewed
May 5, 2026
Move the tokio runtime handle capture to before the spawn_blocking closure so it is explicit that the same runtime is used for execution.
Author
|
Moved |
kkovaacs
approved these changes
May 5, 2026
Contributor
kkovaacs
left a comment
kkovaacs
left a comment
There was a problem hiding this comment.
The ntx-builder execution part with the async-in-blocking context is a bit ugly but I don't have a better suggestion for now...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partially addresses #1976 (store blocking ops remain in #2008)
Problem
Proof verification, VM execution, local signing, local batch/block proving, local transaction
proving, and ntx-builder VM execution were running CPU-intensive work directly on Tokio worker
threads. As noted in the issue (with dial9 profiling evidence), this starves the async runtime
and degrades throughput.
Changes
crates/validator/src/tx_validation/mod.rsTransactionVerifier::verify(proof verification) moved tospawn_blockingexecutor.execute_transaction(VM execution) moved tospawn_blockingwith a dedicatedcurrent_threadruntime since the validator data store makes no real async I/O callscrates/validator/src/signers/mod.rsSecretKey::sign(sync ECDSA wrapped in async fn) moved tospawn_blockingbin/remote-prover/src/server/prover.rsLocalBatchProver::provewas already fixed;LocalBlockProver::provemoved tospawn_blockingLocalTransactionProver::proveleft as-is -- delegates to the VM async APIcrates/ntx-builder/src/actor/execute.rsLocalTransactionProver::prove(ZK proof generation) moved tospawn_blockingfilter_notes+execute(VM execution with data-store callbacks) moved tospawn_blockingwith
Handle::current().block_on()so gRPC data-store calls use the existing I/O driverNot covered
Store blocking ops (RocksDB) are being addressed separately in #2008.