aschmahmann
commented
2 years ago 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.
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:
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.