IPLD Resolver: Pre-publish messages

[aakoshh]

Part of #475

As a potential speedup, the child agents can preempt later Bitswap requests by publishing the CIDs they anticipate will be requested from them to the parent subnet via Gossipsub, so that the parent agents would already have them when they would normally ask them via #466 .

For we would need to extend #467 to not only track subnet memberships, but also to subscribe to pre-publishes from child subnets. For example parent subnet agents could subscribe to /ipc/subnet/prime/<subnet-id> if they are interested in getting these notifications, and any child subnet could send messages there. The agents would cache these messages up to a certain amount of time, with limits on how much they can keep in memory to avoid being DoS attacked. Or, instead of the parent subscribing to the child, it could subscribe to the parent topic itself, and all child subnets send to that single topic, so parents don't have to actively subscribe to children.

Add a method to #465 if we adopt this extension.

[adlrocha]

@aakoshh, it would be great if we could have this feature in the protocol, and combine it with the gossipsub protocol we need in https://github.com/consensus-shipyard/ipc-agent/issues/72 for the multisig protocol.

Child subnet will broadcast preemptively their messages so they can cache them in their datastore and save a query to the IPLD resolver, and the agents of validators, when they see that is final, broadcast their signatures so they can be collected by the rest of the committee. Let me know if something is not clear and you want to discuss further.

[aakoshh]

Let's look at the two cases separately.

Top-down

This is where a message is intended to go from the parent subnet to the child subnet. In our setup, every validator on the child subnet runs a full node on the parent subnet as well, so they can directly observe the finality of messages as well as resolve the CID from their parent-subnet data stores directly. In this case, parent-subnet validators preemptively publishing top-down messages for the child-subnet is not necessary, they already have the data.

In the top-down case, the child-subnet validators have to agree on when a message is final in the parent-subnet, before they execute it, which is what the voting in #447 has been added for. But, as we just saw, this voting is over CIDs they already have in their posession, no need for publishing anything.

Bottom-up

I this case the child-subnet is sending a message to the parent-subnet, and only a subset of the parent-subnet validators might have the content (maybe none of them do, if the child-subnet validators just run full nodes on the parent-subnet). So far, the child validators could have published a message on the parent subnet, which would have triggered something special happening on the parent subnet nodes to prompt them to reach out to their companion IPC agents, to ask them to resolve the CID in the message to full bytes. This is how we can resolve a checkpoint-metadata record to the underlying messages.

In the case of checkpointing, we discussed that there is no need for an extra round of voting, because the only group of entities who know how to validate a checkpoint have already signed it, and currently there's no way to verify if they are not lying.

The bottom-up case does benefit from pre-publishing the data, however, because it means that the parent-subnet validators are distributing the data between themselves, rather than all go to one of the child-subnet validators.

TL;DR

Gossip	Finality Votes	Pre-publish Content
Top-down	✔️	❌
Bottom-up	❌	✔️