👈 Meridian Design Doc 03: Evaluation dissected

👉 Meridian Design Doc 05: IE smart contract

See also the thread model Threat Model for SPARK Frauds and the proposal for retrieval attestations in Boost SPARK Content retrieval attestation

(1) Trusted SPs

One of the main issues we face is whether the SPs are returning the file that they should be returning in the response body, and not just returning the headers which includes the signature chain. Specifically, an SP can create a valid signature chain that gives a proof of relay between the Station operator and the SP but can then simply return an empty response body. Then the evaluation of the signature chain will still be valid, even though no response body was returned.

We can simplify the Spark PoC by only using SPs that we can trust to return the right file in the response body.

(2) Proof of data possession

This one seems complex but could lean on the existing code in Filecoin to prove possession of data.

(3) Hash comparisons

The idea here is for the same CID to be used by a handful of Spark jobs and then for the hashes of the files to be compared by the orchestrator to make sure that the file was returned to the client who was then able to hash it.

(4) Pre-computed retrieval proofs with time-lock encryption

Initial setup

1. Let’s say we have a storage deal client that wants to setup retrieval checks at times t1, t2, … tN. This client has access to the raw content being stored.
2. For each tX
   • The client will define a window when the check can be performed. E.g. between 1pm-2pm on 2023-07-31.
   • The client generates a unique nonce value and encrypts it using timelock encryption so that it cannot be decoded before the window starts.
   • The client combines the nonce with the raw content and derives a constant-length proof in such a way that the proof is unique to this check and can be recreated only by having access to nonce and the entire content. (Example algorithm: SHA256(XOR(nonce, content))).
   • The client encrypts this proof using timelock encryption so that it can be decoded one hour after the window ends. (The one-hour delay was chosen arbitrarily, we can tweak it.)

Single retrieval check

1. SPARK client receives a retrieval job definition.
   1. If the job comes from a centralised Orchestrator, then the orchestrator can open the timelock vault to obtain nonce.
   2. If the job comes from a smart contract or a similar decentralised component, then the client needs to open the timelock on its own.
2. The client retrieves the given CID from the given Storage provider and re-creates the proof using nonce and retrieved content.
3. The client submits the proof alongside other retrieval data, e.g. attestation token and telemetry.