[Need Reconsider] Warm up StoreCache entries from in‑memory BlockView to avoid redundant RocksDB scans

[eval-exec]

Feature Request

Is your feature request related to a problem? Please describe.

In the block-accept path (ChainService#verify_block) we already have a full BlockView in memory, including cached tx hashes (BlockView.tx_hashes).
Yet StoreCache entries (e.g. block_tx_hashes) are only populated lazily via read‑through and can trigger a RocksDB iterator scan later.

Why it matters

• get_block_txs_hashes is used by reward calculation during contextual verification, and a miss triggers a DB scan of COLUMN_BLOCK_BODY (store/src/store.rs).
• We already have the hashes in memory when the block is considered as a new block, so this is avoidable IO and CPU.
  

  ckb/store/src/store.rs

  Lines 149 to 174 in 532bc22

  	fn get_block_txs_hashes(&self, hash: &packed::Byte32) -> Vec<packed::Byte32> {
  	if let Some(cache) = self.cache()
  	&& let Some(hashes) = cache.block_tx_hashes.lock().get(hash)
  	{
  	return hashes.clone();
  	};
  	let prefix = hash.as_slice();
  	let ret: Vec<_> = self
  	.get_iter(
  	COLUMN_BLOCK_BODY,
  	IteratorMode::From(prefix, Direction::Forward),
  	)
  	.take_while(|(key, _)| key.starts_with(prefix))
  	.map(|(_key, value)| {
  	let reader = packed::TransactionViewReader::from_slice_should_be_ok(value.as_ref());
  	reader.hash().to_entity()
  	})
  	.collect();
  	if let Some(cache) = self.cache() {
  	cache.block_tx_hashes.lock().put(hash.clone(), ret.clone());
  	}
  	ret
  	}

Describe the solution you'd like

Warm up StoreCache.block_tx_hashes before a block is verified/accepted using the in‑memory BlockView:

• Insert block.hash() -> block.tx_hashes().to_vec() into StoreCache.block_tx_hashes.
• This avoids a later DB scan and should improve latency/IO during sync.

Related optimization opportunities
Other struct StoreCache entries are also read‑through and could be warmed from in‑memory data when available:

• block_proposals: proposals are already in BlockView.
• block_uncles: uncles are already in BlockView.
• block_extensions: if available at insert time, can be cached directly.