Optimizing trust parameters

[hannahhoward]

What

We need to consider various factors in deciding how much to trust metadata results from graphsync peers -- and how far to look ahead in terms of bitswap requests:

• The issues raised in Making metadata requests to multiple peers #3
• How much data has already been verified (we can look ahead farther the farther we get into a request)
• How far ahead we're staying of selector verification (basically, if selector verification catches up entirely, we need to make more requests)

Once we establish the initial version (based on a fixed look-ahead vlaue) we'll probably to go through a few cycles of iterating on this in the testbed.

[aschmahmann]

Once we establish the initial version (based on a fixed look-ahead vlaue) we'll probably to go through a few cycles of iterating on this in the testbed.

A reasonable idea is probably to ratchet up trust based on receiving good information about a given CID manifest. Having a fixed look-ahead is tricky since it tends to be either attackable (large look-ahead) or not very useful (small look-ahead).

However, this might need a protocol change in Bitswap to be able to ask a peer about a given CID (i.e. a WANT_HAVE/WANT_BLOCK request) along with a maximum size allowed for the given block. Without this the trust here becomes difficult.

For example, say I want to download a linear DAG of 10k blocks that are each 1kb. Every time I send out an untrusted block request I could be getting back up to 2MiB (the maximum block size, for those interested in block sizes see https://pl-strflt.notion.site/Block-Limits-IPLD-and-IPFS-344484bbfa3a475180cb2a9ea1cc9a0d). This means I have to download 2000 blocks linearly before I can start looking ahead a little more. However, if I can assert that a CID is a certain size in the Bitswap request I can scale out the amount of (at the time) untrusted data I download in a more controlled manner. This would require the manifests of CIDs to come with sizes as well.