Merging heartbeat & task

[erhant]

This discussion is born out of the recent updates to Waku message rate-limits. The idea here is to reduce the amount of messages we emit, without sacrificing any features, and minimizing the latency as much as possible.

Current Setting

Normally, we follow the heartbeat-task approach, which can be summarized as:

1. Admin makes a heartbeat
2. Compute responds to heartbeat (always)
3. Admin sends a task
4. Compute responds to task (if selected)

This means that for every heartbeat a message is spent on both sides (Admin and Compute), and the rest of the messages are spent for tasks. Each task is given in separate messages.

Proposition

Alternative is a round-based messaging protocol with only one type of message that includes an array of tasks (with their own bloom filters). Every $t$ seconds (with respect to RLNv2 nonce limit per epoch) the Admin node publishes an array of tasks under a single payload, and broadcasts it.

All compute nodes iterate over the received array of tasks (if they are not busy with a task already) and if they are included within the bloom filter of any task, they start to work on it. Otherwise (meaning that they have not been included in any filter) they simply respond as if this was a heartbeat for them.

This way, there is only ever 1 message sent by the Admin node and that is guaranteed to be at every $t$ seconds. Likewise, the number of messages sent by the compute node is bounded by this value: they either respond to heartbeat or respond to a task, never to both (similar to previous setting).

[erhant]

@anilaltuner this is what we had talked about on the board yesterday