Create block read-ahead cache.

[evoskuil]

Create read-ahead block validation cache. Cores underutilized (10%) with full block download and continuous validation. With enough cores at priority, validation should be able to keep pace with download (assuming no long gaps).

Use circular hash table by block hash, populate by distance from last validated. Due to reorgs and async download vs. confirmation, validated blocks can get stuck. Use bitmap by height and prune below current confirmed height on each addition. Perform on add so cast applies to download vs. confirmation, though logically should be on confirmation removal.

Create circularity by adding new downloads if there is space by configuration. Can configure based on byte size, but then should cache from message deserialization (do on all?). Otherwise limit cache by count (initial implementation). When validation is keeping up this will eliminate block read byte cost.

Prime cache from store. Trigger on validation block query where the cache isn’t full (and isn’t currently priming). When faster than validation this will eliminate block read time cost. Fan out reader across intended read set by thread count. Which thread pool? Threading in database?

The cache can support all block queries by hash and be implemented in the store, as a block analog to the output cache. Support by height creates an atomicity constraint, though could be avoided by obtaining hash from height before reading the block.