IPLD Resolver: Content

[aakoshh]

Part of #475

IPC agents running on the parent subnet need to pull data from IPC agents (also) running on the child subnet(s). To do so, we have multiple options:

• A custom point to point protocol as described in P2P: Subnet content resolution protocol #475, where a parent agent asks a child agent for the CID it sees in a checkpoint already present in the parent ledger. The child agent makes a JSON-RPC call to the IPC gateway actor in the child Lotus instance ledger, asking to gather all Messages indirectly pointed to by the CID (it directly points at a list of CIDs in the ledger), and return the fully fledged cross message bundle.
• A generic Bitswap protocol instance either from libp2p-bitswap or iroh-bitswap (which I haven't yet looked at; it's potentially more feature rich but bigger), in which case the parent agent asks the protocol instance to recursively resolve a CID and insert the whole sub-graph into the Blockstore.

In this issue, I would like to start with option 2 as it's more general purpose and seems to fit the situation:

• We have a recursive data structure (the checkpoint), aggregating a list of messages
• We can rely on enveloping to avoid transmitting messages multiple times if the node already has them
• It's more granular, so it should scale to larger checkpoints with hundreds of messages in it (although passing it between the agent and Lotus is out of scope here)
• Currently Forest already uses Bitswap to resolve messages in Gossiped blocks, although it's a bit of a misuse because it waits for the results, and during historical syncing it uses a different protocol
• Unlike Forest, we can afford to wait until the query completes
• Doesn't require support from the Gateway actor

To support Bitswap, the child agent will need a way to pull arbitrary CIDs from the blockchain node it is connected to. If this is not desired, if we want to limit it to just checkpoint content, then we can potentially keep using the Gateway actor to only resolve CIDs if they are checkpoint related.

Ideally the parent agent can also check if it has a CID already, to avoid asking if it does, which is part of the recursion, by implementing BitswapStore::missing_blocks. Naively we could let the agent use a memory based store that always has nothing in it and pull all CIDs, but the parent might already have the messages - for example if they ran nodes across multiple subnets and shared the storage, or if we used Gossipsub to pre-load the CIDs onto the parent agents.

In this issue, create a Content behaviour wrapping a Bitswap behaviour that:

• Has a resolve method to fetch a CID from a list of peer IDs. The RequestResponse protocol underlying the Bitswap will try to connect to any peer IDs it isn't connected to at the moment, for which the Swarm will ask Add sorting imports #34 for addresses.
• From a higher level component, call the resolve method with a list of peer IDs based on what IPLD Resolver: Membership #467 knows are agents serving data in a subnet.
• Poll the Bitswap behaviour and when it signals that a query is completed, raise an event to show that a CID is ready in the block store.

The implementation of the BitswapStore is out of scope here, that will be the integration point with the IPC agent, or Fendermint.