Gossipsub Dynamic Message Diffusion

### Problem

As per the current Gossipsub spec, messages are pushed to all peers within the peer’s mesh, defined by the variable `D`, the mesh size. Inevitably, this results in duplicate messages, which is generally expected and a somewhat desirable property to defend against malicious behaviour or attacks. At the same time, the number of duplicates should be limited to the extent possible to avoid overloading nodes.

Intuitively, given that the rate of diffusion stays stable throughout the 4-second propagation window, we expect to see more duplicates towards the end of the window, when the message has already propagated to the majority of the network.

### Solution Spectrum

**Approach 1:** In order to reduce the amount of duplicates as a result of excessive diffusion at the end of the 4-second window, we propose that dynamic diffusion should be considered. According to the dynamic diffusion scheme, more aggressive propagation of messages takes place at the beginning of the window and slower propagation towards the end. For example, a message is propagated to all `D` peers of a peer’s mesh during the first two seconds and to `D/2` peers during the latter two seconds of the window. However, setting diffusion parameters based on time doesn’t sound like a great choice - makes things rigid and tied to clocks of different nodes in the network, which is generally not a great idea.

**Approach 2:** An alternative way of defining the aggressiveness of message diffusion is through the number of hops that a message has propagated, e.g., a message is pushed to: `D` nodes when `hop_count < 2` from the message producer, `D/2` nodes when `2 < hop_count < 4` and `D/4` when `hop_count > 4`. This, however, means that the message/block producer becomes known to its immediate peers that see `hop_count = 0`, although there could be techniques to obfuscate that a little bit.

**Approach 3:** A much simpler alternative is to just reduce `D` from the current default of `8` down to `6`. This approach won’t solve the issue of more duplicates towards the end of the propagation window (i.e., it’s not dynamic), but will reduce the diffusion velocity throughout the 4-second window and as a result the amount of duplicates throughout. From the Block Arrival times seen at ProbeLab’s dashboard [[link](https://probelab.io/ethereum/block_arrival/2024-47/#message_arrivals_max_min_on_1536s_window_on_topic_mainnet_beacon_block-plot)], there seems to be space to reduce aggressiveness (and duplicates) and (inevitably) increase block propagation time - we see both mean and median block arrival times well below the 4 second mark, hovering on average around 2.1-2.3 secs.

---

The purpose of this issue is to gather feedback on whether investigating this further is desirable, as well as ideas on how to formulate it better (e.g., based on hop count or some other parameter).

[Initial ideas in this issue have been discussed with @cortze @AgeManning @cskiraly and others during Devcon 7.]