BlockTemplate Manager Tracking issue #33758

What to review

• #33421

Plan

• Introduce the Block Template Cache (Manager) #33421 Implement a cache layer. All newly created block templates should be stored along with their respective configuration options. Client requests for block templates will specify the maximum age of the template; that is, how fresh they want the template to be:
  • If a template with matching options exists in the cache and the interval has not elapsed, a cached template is returned.
  • If no template exists or the interval has elapsed, a new template is generated, stored in the cache, and returned.
  • After insertion, the oldest template is evicted if the cache exceeds its maximum size.
  • There is also an option to bypass the cache.

The cache has a configurable maximum size (default: 10). It also subscribes to the validation interface's BlockConnected notification. It clears the cache when a new block is connected or disconnected, preventing stale templates from being served. Cache lookup requires an exact match on all BlockCreateOptions fields. Each client (mining, fee estimation, P2P sharing) builds its template once and reuses it continuously unless network conditions change (time or fees). Cross-client sharing is deferred for now, we cache N templates per client; a single shared cache for all clients can be pursued later.

• Block template requests from node components and other block template-related operations will be handled via this cache #33421.

• Enable detecting the fees inflow of the block template either via i) #34803, which propagates mempool fee rate diagram mutations, modification to createAssembler to return the index at which we start skipping, due to the block template tail-end bin packaging issue or ii) using mempool and txgraph directly https://delvingbitcoin.org/t/determining-blocktemplate-fee-increase-using-fee-rate-diagram/2052/2

• Prune WaitAndCreateNewBlock and move its implementation to the block template cache under GetNext that detects mempool inflow in a smarter way than building block template every one second. This method will use the block template cache for decisions to build a block template. This approach is cleaner and should allow reusing the logic in getblocktemplate, thereby removing the global state. https://github.com/bitcoin/bitcoin/blob/292ea0eb8982faef460c210bd4215d603f487463/src/rpc/mining.cpp#L776 https://github.com/bitcoin/bitcoin/blob/292ea0eb8982faef460c210bd4215d603f487463/src/rpc/mining.cpp#L859-L861 This will also allow pruning WaitTipChanged and exposing information to retrieve the metadata of the last built block template, enabling the removal of additional global state. https://github.com/bitcoin/bitcoin/blob/292ea0eb8982faef460c210bd4215d603f487463/src/node/miner.h#L186-L189
• Wire the cache into createnewblock and getblocktemplate RPC and other components, etc. If there are no changes to the tip or inflow, there is no reason to rebuild an identical template. The current guard in #34075 is a time delay; only after that delay, a rebuild occurs regardless of inflow. This step conditions rebuilds on both elapsed time and actual fee inflow. The same logic applies to others if available as well e.g. P2P template sharing.