Deadlock: futures::executor::block_on inside tokio runtime in TrustedHttpContextProvider

[QuantumExplorer]

Description

TrustedHttpContextProvider::get_quorum_public_key() in rs-sdk-trusted-context-provider/src/provider.rs (line ~626) calls futures::executor::block_on() when a quorum key is not found in cache and refetch_if_not_found is true. This call happens from within a tokio runtime context (the SDK's FFI layer enters the runtime via wrapper.runtime.block_on(async { ... })), which causes a deadlock.

Root Cause

The ContextProvider trait has a synchronous interface (fn get_quorum_public_key(...) -> Result<...>). When the quorum cache misses, the code falls back to:

futures::executor::block_on(self.find_quorum(...))

find_quorum makes HTTP requests via reqwest. Nesting futures::executor::block_on inside a tokio runtime context deadlocks on single-threaded runtimes or panics on multi-threaded runtimes.

Trigger Conditions

1. SDK created via dash_sdk_create_trusted — quorum prefetch is async and the SDK handle is returned immediately (race condition)
2. App issues a query requiring proof verification before the prefetch completes
3. get_quorum_public_key is called, cache is empty
4. futures::executor::block_on called inside tokio → deadlock

Also triggered if a proof references a quorum hash not in the pre-fetched set.

Impact

• App hangs permanently (denial of service)
• Intermittent — depends on timing of prefetch vs first query
• Affects iOS SDK and any other FFI consumer using the trusted context provider

Suggested Fixes

1. Use tokio::task::block_in_place + Handle::current().block_on() for the synchronous fallback
2. Or restructure ContextProvider trait to support async operations
3. Or block SDK creation until prefetch completes (ensure SDK is ready before returning handle)
4. Or set refetch_if_not_found = false when operating within a tokio context and rely solely on the prefetched cache

Related

• dash_sdk_create_trusted returns SDK before prefetch completes (rs-sdk-ffi/src/sdk.rs:504-537)
• The diagnostic HTTP requests to google.com at lines 511-521 should also be removed

Found By

Security audit of v3.1-dev branch.