perf: remove blocking calls from POI queries

[MoonBoi9001]

Summary

Two optimizations for POI query handling in the index-node resolver:

1. Make resolve_proof_of_indexing async - Removes synchronous block_on call that was blocking tokio worker threads while waiting for database queries. POI queries now properly yield to the async runtime.

2. Parallelize publicProofsOfIndexing requests - Changes sequential for-loop to future::join_all for concurrent execution of batch POI requests.

Changes

• server/index-node/src/resolver.rs
  • resolve_proof_of_indexing: fn → async fn, block_on(fut) → fut.await
  • resolve_public_proofs_of_indexing: sequential loop → future::join_all
  • Added future import from graph::futures03

[lutter]

The first commit is great and something that absolutely needs to happen. For the second commit, I am not quite clear on what the motivation is - are PoI requests slow? The worry I have is that when graph-node is under a lot of load, parallelizing these requests makes the situation worse. The code limits the number of requests to 10, which is good, but I'd still like to understand what the motivation for this change is.

[MoonBoi9001]

The motivation is POI verification tooling for dispute investigation.

When investigating POI discrepancies (e.g., for arbitration disputes), we need to compute POIs across large block ranges to identify where divergence occurred.

With sequential processing, throughput is bottlenecked at ~2k POIs/second even though the database connection pool has capacity. The publicProofsOfIndexing endpoint accepts batch requests (up to 10), but processing them sequentially means we're not utilizing available parallelism. Checking every block sequentially on a network with 100m blocks takes 13+ hours at ~2k blocks/second.

[MoonBoi9001]

The worry I have is that when graph-node is under a lot of load, parallelizing these requests makes the situation worse.

The third commit addresses this, now pre-fetch all block hashes in a single batch query before parallel processing, reducing DB round-trips.

[lutter]

With sequential processing, throughput is bottlenecked at ~2k POIs/second even though the database connection pool has capacity. The publicProofsOfIndexing endpoint accepts batch requests (up to 10), but processing them sequentially means we're not utilizing available parallelism. Checking every block sequentially on a network with 100m blocks takes 13+ hours at ~2k blocks/second.

Have you tried a binary search for PoI's? I assume you are looking for the point where the PoI's for some subgraph diverge between two indexers. Instead of a binary search, you could actually request multiple PoI's across some range (start with [0, current subgraph head]) and then refine the range so that the point of divergence is always in the range. That should yield results very rapidly.

[MoonBoi9001]

Binary search works well for finding divergence points between two indexers. This PR speeds up computations for finding which block a given POI actually corresponds to if it doesnt correspond to the block that it is claimed to (can be used to prove an indexer claimed rewards for block N, but only synced to block X). Under the assumption that an indexer force closes with a valid POI for a block x < n, but submits that block x POI for block n.

[lutter]

Thanks for the explanation - if you use this to find the block for which a given POI was generated, how about we add a route in the resolver that just does that? That might be much faster than just speeding up POI lookup.