Sharing block templates

The exploration of Minisketch's utility in block relay processes reveals its efficiency, particularly highlighting that the complexity it introduces is quadratic in relation to the set difference rather than the queue size. This discovery emphasizes the significance of consistency over volume in data reconciliation efforts. Initially, the concept of reconciling the entire mempool continually was considered. However, this approach faced challenges due to policy discrepancies and conflict races, which resulted in bandwidth loss until the resolution via mining. To circumvent these issues, the strategy shifted towards reconciling announcements, which proved to mitigate the persistent difference problem, aligning the bandwidth and decoding costs of mempool and inventory (inv) reconciliations more closely.

In optimizing communication between peers, alternatives to full reconciliation have been identified. For instance, utilizing a recent template from the same peer to construct edits presents a more efficient solution. These edits are not only quick to produce but also reduce the data size, leveraging existing information. Furthermore, employing Minisketch for predictable edits could enhance communication, although its necessity might be limited to specific instances like the initial update or post-new-block updates. The discussion extends to the drawbacks of using salted shortIDs in reconciliation protocols, such as those employed in compact blocks. The necessity for short IDs in compact blocks was paramount for efficiency, but it led to the consideration of 128 bit identifiers to avoid the constraints imposed by TCP window sizes. However, the process of hashing the mempool, especially when transactions are missing, consumes a significant portion of reconstruction time.

A future-oriented perspective suggests that nodes might benefit from maintaining clones of a small number of peers' mempools, specifically targeting the top two or three blocks without imposing policy restrictions. This approach would allow for the inclusion of transactions that may conflict with the node's own mempool, aiming to minimize the impact of policy differences and conflict races on block propagation delays. Implementing such a system would entail each peer holding in memory the last shared mempool tip plus additional ones for a select few peers. This method promises to expedite block relay through highly efficient means while keeping memory usage to a minimum, potentially requiring only a few megabytes per selected peer due to the sharing of transaction objects.