Authors: pop
tldr; topic observation enables the nodes to get notified when there is a new message in
a topic without actually receiving the actual message.
This proposal enables you to tell your peers to notify you when there is a new message in the topic without consuming the bandwidth to download the actual message. When you do this, you are called an observing node in that topic.
Motivation
Topic observation is motivated by the amplification factor on bandwidth consumption due to the mesh degree of GossipSub. When you subscribe to a topic, you would need to download as many copies of messages as the mesh degree. For example, if the mesh degree is 8, you would roughly download 8 copies.
We have IDONTWANT implemented in GossipSub 1.2 which will reduce the number of copies you will download, but it doesn’t guarantee exactly how many.
When you observe a topic, you won’t receive any message. You will only get notified when there is a new message. If you want the actual message, you can request the message from the peer that notifies you first, so you will download only one copy. However, the message request part is out-of-scope of this proposal. This proposal only deals with notifications.
High-level design
When you want to observe a topic, you would need to find subscribing nodes in the topic and tell them you want to observe the topic. Later, when there is a new message, those subscribing nodes will notify you.
Let’s see examples in the figure, node 11 is observing the topic. Node 1, 9, and 10 will notify node 11 when there are new messages. Similarly, node 4 and 5 will notify node 12.
Notice that the relationship is unidirectional rather then bidirectional like mesh connections.
You can also tell your subscribing peers when you don’t want to observe the topic anymore. That is when you want to unobserve it.
Stability
Notice that observing nodes only receive notifications. They neither send notifications nor forward messages. In other words, they only consume, not contribute. So, they are only on the border of the network (as shown in the figure) and don’t provide any stability to the network. It means that there must be enough subscribing nodes in the network to provide stability.
However, the good side of this is that the churn rate of observing nodes doesn’t matter at all. Nodes can observe and unobserve as often as they want.
Scalability
Currently, when your peers want to observe the topic and tell you to notify, you are obligated to notify them without the option to decline. This has a downside that if too many of your peers want to observe, you will have too much overhead to do the job.
However, the notifications consist only of messages ids which we now assume to be negligible. You may argue that if the number of observing peers is high enough, the total size of notifications will be significant. That’s true, but for the first iteration of the design, we should make this assumption to make the protocol simple.
Protocol messages
There are two new control messages: OBSERVE and UNOBSERVE.
You send OBSERVE to your peer when you want to observe a topic and have that peer notify you.
You send UNOBSERVE to your peer to tell that you don’t observe the topic anymore.
After sending OBSERVE to your peer, the peer will send IHAVE to you as a notification, when there is a new message in the topic.
However, IHAVE in this proposal is different from the previous GossipSub versions. In the previous versions, IHAVE is sent only at the heartbeats, while in this version, it can also be sent right after peers receives messages. Previously, you can send IWANT after receiving IHAVE, but in topic observations, you aren’t expected to send IWANT, since IHAVE serves only as a notification.