rfc: implement some kind of gossip

[0xdeafbeef]

Problem

Currently, we have the number of collators >= number of light nodes. But in a real network, it will be the opposite - thousands of light nodes and < 100 collators.
Nodes are ranked based on their latency. So if some nodes form a cluster (e.g., same datacenter), there is a high chance that they will have each other as neighbors. This will eventually stop block walking. The worst case is if there is a collator in the same cluster. It will be ranked as a top neighbor and flooded with block requests.

Solution

Gossip known master block ids (u32 + PeerId)

Each node should broadcast the latest master seqno after the block strider step finishes (master block and shard blocks are processed and saved). This message should be signed with the peer's private key to prevent illegitimate node tampering.
Each node can build an index consisting of master block id → peer id. Storing the last 5 block id → peer id pairs should be enough.
If all node neighbors do not have the latest blocks, the node should use this index during neighbor reranking. We may rank non collating nodes higher for better load balancing.

Additionally, we may store this information in DHT.

This implementation will result in negligible traffic amplification compared to full block gossip.

Drawbacks

This solution will add lag in block fetching. Worst case lag is:

$\sum_{i=1}^{n} t_i$

Where:
$n = \text{number of peers between you and validator}$
$t_i = \text{polling interval of i-th peer}$

Security

1. Message Signing: Gossiped messages should be signed as mentioned above to ensure authenticity and integrity.

2. Implement a rate limit to prevent flood attacks.
   $$\text{Maximum allowed messages per second} = 2 \times \left(\frac{\text{Number of master blocks}}{\text{second}}\right)_{\text{from config}}$$

Alternatives / prior art

• Bloom Filter-based Gossip with sliding window over last 1 hour