|
| 1 | +# IPLD Resolver |
| 2 | + |
| 3 | +The IPLD Resolver is a library that [IPC Agents](https://github.com/consensus-shipyard/ipc/) can use to exchange data between subnets in IPLD format. |
| 4 | + |
| 5 | +## Checkpointing |
| 6 | + |
| 7 | +The most typical use case would be the propagation of checkpoints from child subnets to the parent subnet. |
| 8 | + |
| 9 | +### Checkpoint Schema |
| 10 | + |
| 11 | +One possible conceptual model of checkpointing is depicted by the following Entity Relationship diagram: |
| 12 | + |
| 13 | + |
| 14 | + |
| 15 | +It shows that the Subnet Actor in the parent subnet governs the power of validators in the child subnet by proposing _Configurations_, which the child subnet is free to adopt in its _Epochs_ when the time is right, communicating back the next adopted config via _Checkpoints_. |
| 16 | + |
| 17 | +At the end of an epoch, the validators in the child subnet produce a checkpoint over some contents, notably the cross-messages they want to propagate towards the parent subnet. Through the cross-messages, the checkpoint indirectly points to individual messages that users or actors wanted to send. |
| 18 | + |
| 19 | +Once enough signatures are collected to form a Quorum Certificate over the checkpoint (the specific rules are in the jurisdiction of the Subnet Actor), the checkpoint is submitted to the parent ledger. |
| 20 | + |
| 21 | +However, the submitted checkpoint does not contain the raw messages, only the meta-data. The content needs to be resolved using the IPC Resolver, as indicated by the dotted line. |
| 22 | + |
| 23 | +### Checkpoint Submission and Resolution |
| 24 | + |
| 25 | +The following sequence diagram shows one possible way how checkpoints can be submitted from the child to the parent subnet. |
| 26 | + |
| 27 | +It depicts two validators: one only participating on the parent subnet, and the other on the child subnet; the latter has to also run at least a full node on the parent subnet. Both validators run one IPC Agent each. |
| 28 | + |
| 29 | +The diagram shows that at the end of the epoch the child subnet validators produce a Quorum Certificate over the checkpoint, which some of their agents submit to the parent subnet. |
| 30 | + |
| 31 | +After that, the parent subnet nodes reach out to their associated IPC Agent to resolve the messages referenced by the checkpoint, which the Agent does by communicating with some of its child-subnet peers. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | +This is just a high level view of what happens during message resolution. In the next section we will delve deeper into the internals of the IPLD Resolver. |
| 36 | + |
| 37 | + |
| 38 | +## IPLD Resolver Sub-components |
| 39 | + |
| 40 | +The IPLD Resolver uses libp2p to form a Peer-to-Peer network, using the following protocols: |
| 41 | +* [Ping](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/ping) |
| 42 | +* [Identify](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/ping) is used to learn the listening address of the remote peers |
| 43 | +* [Kademlia](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/kad) is used for peer discovery |
| 44 | +* [Gossipsub](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/gossipsub) is used to announce information about subnets the peers provide data for |
| 45 | +* [Bitswap](https://github.com/ipfs-rust/libp2p-bitswap) is used to resolve CIDs to content |
| 46 | + |
| 47 | +See the libp2p [specs](https://github.com/libp2p/specs) and [docs](https://docs.libp2p.io/concepts/fundamentals/protocols/) for details on each protocol, and look [here](https://docs.ipfs.tech/concepts/bitswap/) for Bitswap. |
| 48 | + |
| 49 | +The Resolver is completely agnostic over what content it can resolve, as long as it's based on CIDs; it's not aware of the checkpointing use case above. |
| 50 | + |
| 51 | +The interface with the host system is through a host-provided implementation of the [BitswapStore](https://github.com/ipfs-rust/libp2p-bitswap/blob/7dd9cececda3e4a8f6e14c200a4b457159d8db33/src/behaviour.rs#L55) which the library uses to retrieve and store content. Implementors can make use of the [missing_blocks](../src/missing_blocks.rs) helper method which recursively collects all CIDs from an IPLD `Blockstore`, starting from the root CID we are looking for. |
| 52 | + |
| 53 | +Internally the protocols are wrapped into behaviours that interpret their events and manage their associated state: |
| 54 | +* `Discovery` wraps `Kademlia` |
| 55 | +* `Membership` wraps `Gossipsub` |
| 56 | +* `Content` wraps `Bitswap` |
| 57 | + |
| 58 | +The following diagram shows a typical sequence of events within the IPLD Resolver. For brevity, only one peer is shown in detail; it's counterpart is represented as a single boundary. |
| 59 | + |
| 60 | + |
| 61 | + |
| 62 | +# Diagram Automation |
| 63 | + |
| 64 | +The diagrams in this directory can be rendered with `make diagrams`. |
| 65 | + |
| 66 | +Adding the following script to `.git/hooks/pre-commit` automatically renders and checks in the images when we commit changes to the them. CI should also check that there are no uncommitted changes. |
| 67 | + |
| 68 | +```bash |
| 69 | +#!/usr/bin/env bash |
| 70 | + |
| 71 | +# If any command fails, exit immediately with that command's exit status |
| 72 | +set -eo pipefail |
| 73 | + |
| 74 | +# Redirect output to stderr. |
| 75 | +exec 1>&2 |
| 76 | + |
| 77 | +if git diff --cached --name-only --diff-filter=d | grep .puml |
| 78 | +then |
| 79 | + make diagrams |
| 80 | + git add docs/diagrams/*.png |
| 81 | +fi |
| 82 | +``` |
0 commit comments