As we add rewards for SP retrieval checks performed by SPARK, we must design a robust fraud detection mechanism to combat malicious nodes. In this document, we describe the threat model - what are the adversaries and possible attack vectors.

IMPORTANT

We assume SPARK will check retrievals using the recently introduced HTTP transport only. Checking Bitswap and Graphsync retrievals are out of the scope.

A job (a retrieval check) is defined as a pair (cid, address). The client is expected to retrieve cid from address using the HTTP protocol.

See Workflow of a single retrieval check performed by SPARK for a detailed description of job scheduling and retrieval workflow.

Adversaries

• A malicious Storage Provider that wants to inflate its reputation artificially.
• A malicious SPARK client that wants to be rewarded for work they did not do.
• A malicious SPARK client operated by an SP that flags other SPs as unreliable, thus harming their reputation.
• A Storage Provider that runs its own fleet of SPARK clients that are colluding together to game the system and improve the reputation of the SP.

Attack vectors

• An SP can easily get a /24 block of 256 unique IP addresses. They can spin 256 SPARK instances and run a modified client that checks only jobs retrieving from this SP and reporting all other jobs as failed (cannot reach the SP). They are still earning SPARK rewards and boosting their own reputation.
  • CryptoEconLab is best positioned to solve this.
  • We should bring this up in our sync meeting with senior leadership.

Client-side

1. The client does not perform the retrieval check and reports a fake successful retrieval.
2. The client does not perform the retrieval check and reports the retrieval as not successful.
   • Pretend that the server cannot be reached or did not respond.
   • Pretend that the server returned the wrong payload (content verification failed).
3. The client performs the retrieval but reports different results than observed in order to harm the reputation of competing SPs.
   1. Skew metrics like TTFB, TTLB and download speed (bandwidth).
   2. Pretend that the server cannot be reached or did not respond.
   3. Pretend that the server returned the wrong payload (content verification failed).
4. The client starts the retrieval check, waits for the response headers and discards the response body (CAR stream with content) in order to save bandwidth.
5. The client does not verify the integrity of the received content (whether the blocks in the CAR stream build up to the requested CID).
6. The client retrieves the given CID but from a different SP.
7. The client dials the given provider but retrieves a different CID.