Extension of block gossiping/announcement with extra non-block payload

[nazar-pc]

In our protocol in order to verify block header client needs a piece of information that is already known (a piece of blockchain history), but not necessarily already present in node's memory (might need to fetch from the network).

Since we want block verification to be fast, we don't really want to make request to the network every time we receive a new block (it creates a lot of tricky scenarios that can cause problems and be leveraged by an attacker), it would be great if extra piece of information was transmitted alongside with the block, so that node doesn't have to fetch it.

In order to bypass this issue for now we include this piece of information directly in the block header, which means every header is 4096 bytes bigger than it would have been otherwise, so this is not great.

Right now block gossiping (and transactions for that matter) is tightly coupled with networking implementation, doesn't use sc_network_gossip and not really extensible/replaceable in any way without huge networking rework (unless I miss something).

So I'm curious what would be the best approach to make something like this happen with Substrate upstream. The simplest version I see is to extend existing block gossiping somehow to have an extra field that client libraries can populate with useful payload.

Any thoughts on what should we do in this case?

[bkchr]

You can already extend the block announcement with some extra data: https://github.com/paritytech/substrate/blob/master/client/network/src/service.rs#L1000

Then you can set a block announce validator: https://github.com/paritytech/substrate/blob/master/primitives/consensus/common/src/block_validation.rs#L55

It can be set here https://github.com/paritytech/substrate/blob/master/client/network/src/config.rs#L101

[nazar-pc]

It doesn't seem possible to inject extra data from block import notification, it is hardcoded to be None:

substrate/client/service/src/lib.rs

Line 188 in 55cd07a

network.service().announce_block(notification.hash, None);

And similarly I'm not sure how do I access it in block import pipeline on the other side (or should I handle it externally with validator?).

[bkchr]

This is not propagated to block import pipeline. You can call announce_block on your own with some data, this is for example also done in Cumulus this way.