Architecture

❓ Diagram

sequenceDiagram
  participant sp as SP
  participant cs as Contract: Service (FilOz)
  participant cv as Contract: Verifier (Spark)
  participant ct as Contract: Tasker (Spark)
  participant checker as Checker
  loop Signup
    sp->>cs: Subscribe
  end
  loop Schedule retrieval test
    sp->>cs: Check until retrieval task available (gas)
    sp->>ct: Request retrieval test (USDFC,gas)
  end
  loop Perform retrieval test
    checker->>ct: Get task list
    checker->>sp: Perform retrieval test
    checker->>cv: Submit retrieval result
    cv->>ct: Remove retrieval task
    cv->>cs: Share retrieval result
  end

Concerns:

• What if the SP schedules incorrect work
  • Will be penalized

• What if the SP schedules in a way that’s convenient for them
  • This is missing surprises for the SP, the SP knows what is being tested and when

• If we can’t ship code to the SP, what could we do?

👉 What if let the service schedule retrieval tests / don’t ship code to the SP

sequenceDiagram
  participant sp as SP
  participant cs as Contract: Service (FilOz)
  participant checker as Checker
  participant cv as Contract: Verifier (Spark)
  loop Signup
    sp->>cs: Subscribe
  end
  loop Perform retrieval test
    checker->>cs: Check until retrieval task available (gas)
    cs->>checker: (commp, hostname, USDFC)
    checker->>sp: Perform retrieval test
    checker->>cv: Submit retrieval result
    cv->>cs: Remove retrieval task
    cv->>cs: Share retrieval result
  end

Components

SP

The SP is running Curio, which includes PDP Tool and knows how to request retrieval tests from the Tasker smart contract. When it does request one, it includes a fee in the smart contract call, to pay Spark for the retrieval test.

Contract: Service (FilOz)

The Service smart contract is created by FilOz, and uses both the PDP Verifier and the Spark Verifier smart contracts to inform about performance of deals stored on the SP.

Contract: Verifier (Spark)

The Verifier smart contract is created by the Spark team. It receives retrieval results from the Checker node, marks retrieval tasks as done in the Tasker smart contract, and shares the retrievability results with the Service smart contract.

Contract: Tasker (Spark)

The Tasker smart contract is created by the Spark team. It acts as a job queue between SPs and the Checker node. SP add retrieval tasks to its internal state, and the Checker node polls that state to get a task list. Tasks will be removed from the task list by the Verifier smart contract, when it receives retrievability results.

Checker

The Checker node is a single retrieval checking instance. It gets tasks from the Tasker smart contract, performs all these tasks, and submits results to the Verifier smart contract.

FAQ

Why are there no rounds?

Since the Checker node is trusted, no fraud detection needs to be done. Task selection can be trusted. SLAs require all deals to be tested, therefore there needs to be no sampling of deals.

Why does the SP not schedule periodic retrieval tests?

Instead of scheduling periodic retrieval tests, the SP schedules as single test, when the time has come. This makes the Verifier most flexible (you can build on-demand and periodic business logic on top), and our architecture simpler. A periodic retrieval testing offering can later be added on top, on demand.

This is also how PDP works. By keeping our logic close to PDP, we leverage their learnings, don’t need to reinvent the wheel, and can give them better feedback.

How is Spark rewarded?

Whenever the SP requests a retrieval test, it includes a small amount of USDFC (stable coin). The Tasker smart contract will reject any calls not including the right amount of USDFC. The per-test price is still to be decided.

Open questions

• Should the SP ask the PDP Service contract or the Spark Verifier contract about which deals need to be tested?

• How can we ship software to SPs?

• How can payment channels be implemented?