[GossipSub 1.3] Topic observation

[ppopth]

Overview

The proposed extension is intended to enable the nodes to get notified when there is a new message in a topic without actually receiving the actual message.

Four new control messages are introduced: OBSERVE, OBSERVED, UNOBSERVE, and UNOBSERVED. They are primarily used to notify the peers that the node wants to observe/unobserve if there is a new message in the topic.

Motivation

There are many use cases of topic observation:

• For a node that just wants to get notified when there is a new message in the topic and doesn't want to consume too much bandwidth by directly subscribing to the topic.

• For a node that wants to subscribe to the topic, but has some bandwidth constraint. The node can observe the topic and see which peer notifies it first and later send the IWANT to get the actual message. This ensures that the bandwidth used is approximately the size of the message.

The downside of topic observation is that the observing node is not part of the mesh network, so it only consumes the messages, but doesn't contribute to other peers by forwarding the messages.

Relevance to Ethereum

This is useful for the upcoming PeerDAS upgrade (EIP-7594), since it allows a node to get notified when a message is available without bandwidth overhead.

Without this extension, I previously tried to address this Ethereum-specific problem in https://github.com/ethereum/consensus-specs/pull/3717

[Wondertan]

The downside of topic observation is that the observing node is not part of the mesh network, so it only consumes the messages, but doesn't contribute to other peers by forwarding the messages.

What if an observing node propagated the IHAVE message further to its "observe mesh" peers under a particular condition(like having data locally)? Then, nodes would still be able to contribute to the topic, but keeping bandwidth usage low traded for higher latency.

[ppopth]

What if an observing node propagated the IHAVE message further to its "observe mesh" peers under a particular condition(like having data locally)? Then, nodes would still be able to contribute to the topic, but keeping bandwidth usage low traded for higher latency.

Sending IHAVEs to other peers means you commit that you will send the message to those peers if they send the IWANT back, which requires too much bandwidth.

[Wondertan]

Sending IHAVEs to other peers means you commit that you will send the message to those peers if they send the IWANT back, which requires too much bandwidth

"Too much" depends on how big your "observe mesh" is which when configurable can lead to acceptable bandwidth usage. There is no way to contribute to the topic without spending some bandwidth.

[ppopth]

"Too much" depends on how big your "observe mesh" is which when configurable can lead to acceptable bandwidth usage. There is no way to contribute to the topic without spending some bandwidth.

That's right. It's configurable. But, it will be configured by who?

If it's a global parameter like the normal GossipSub mesh degree, that contradicts with the purpose of topic observation and you will have some bandwidth requirement beforehand. In fact, how is it different from normal GossipSub with low mesh degree to save the bandwidth?

If you can make it configurable independently by each node, that would be great.

[ppopth]

Now I'm not quite sure if we should allow observing nodes to send IWANT. That seems irrelevant. If you want to get the message, you probably should use an out-of-band channel like Req/Resp that is used by Ethereum.