⏫

Spark & DDO deals

Problem 1: How to map Piece to Payload

In the f05 world, a DealProposal includes Label field that (optionally) provides payload CID.

In the DDO world, there is no notion of payload CIDs. All we have is PieceCID and PieceSize.

What options we are considering

IPNI Reverse Index

This is our long-term plan. (See FIPs https://github.com/filecoin-project/FIPs/pull/1089 and the FRC document.)

  • We ask miners to advertise deal payload blocks with ContexID built from the (PieceCID, PieceSize) pair.
  • Spark discovers payload blocks by asking IPNI for a sample of blocks ingested with the given (ProviderID, ContextID) pair.

Problems:

  • No miner SW supports this yet:
    • Curio build ContextID the right way, but they broke the link from MinerId to ProviderID.
    • Boost uses UUIDv4 for ContextID.
    • Venus Droplet uses UUIDv4 for ContextID.
  • It will take months until Boost & Venus implement the required changes and SPs upgrade their operations to the new miner SW version.

Graphsync metadata

This could be a short-term workaround. But is it worth the effort?

  • IPNI advertisements for Graphsync retrievals include metadata with PieceCID.
  • This allows Spark’s lightweight indexer to create a mapping from (ProviderID, PieceCID) to (a single) PayloadCID.
  • Boost advertises Graphsync retrievals by default (source code). Venus Droplet advertises Graphsync retrievals by default (source code).

Problems:

  • SPs wanting to use DDO are forced to advertise retrievals over Graphsync, a protocol which has been deprecated.
  • Curio does not support Graphsync, this workaround will not work for them.

Is there just some Curio endpoint we could use?

E.g. /root/{PieceCID} gives us payload root CID. (Compare this to /cid/{PayloadCID} to retrieve the block content.)

Downsides:

  • More code in Curio (and Boost and Venus Droplet)
  • Easily to cheat by SPs

LET’S USE GRAPHSYNC TO MEET SPs WHERE THEY ARE NOW

Problem 2: Impact on SP compliance with FIL+

Our original plan was to implement Spark v2 as a clean cut switching from f05 DealProposal.Label to Piece-based IPNI reverse lookup, see 2️⃣Spark v2 design & migration.

Such change would break RSR scores for many miners that are currently compliant with FIL+ requirements (their Spark RSR is over 80%).

  • No miner SW supports Spark v2 requirements yet.
  • Becase Spark v2 does not look at DealProposal.Label anymore, even existing deals passing Spark retrieval check will fail Spark v2 checks until the miner SW is upgraded.
  • Spark v2 consider all FIL+ deals as eligible for retrieval testing while Spark v1 was testing a only f05 deals where DealProposal.Label starts with one of the prefixes bafy|bafk|Qm.
    • This is not a problem for SPs that accept only deals with a valid Label.
    • However, SPs with mixed deals, where some have a valid Label and some don’t, may see a drop in their Spark RSR if they optimised their operations to advertise only deals with Label to IPNI.

Spark v1.5: backwards-compatible approach

To start measuring DDO-only SPs, which don’t have any Spark RSR yet, while preserving RSR for f05-only SPs that have (a good) Spark RSR, we can implement a hybrid solution:

  • Keep testing a subset of FIL+ deals only.
    • f05 deals - use the current rules (no change)
    • DDO deals - test only deals where we can establish a link between the deal and the IPNI advertisement (either via Graphsync metadata or ContextID parsing).
  • Pros: Gradual adoption.
    • SPs with f05 deals only are not affected at all.
    • SPs with DDO deals will start getting measured when they upgrade their operations to meet Spark’s requirements.
    • SPs create new miner IDs regularly. We can tell them to create a new miner ID when they want to start accepting DDO deals. Most SPs create a new miner ID for each 4PiB of data anyways.
  • Cons:
    • SPs are in control of which deals are tested by Spark.
      • In the worst case, they can advertise only one DDO deal to IPNI to get a high Spark RSR while not serving retrievals for all other FIL+ deals they are paid for.
      • This can be worked around - e.g. the allocator compliance process can compare # of deals in Sparks DB vs # of active FIL+ DDO sectors - but it’s yet another piece that needs to be implemented and that will be thrown away after Spark v1 is sunset.
    • More implementation work for the Spark/SpaceMeridian team. The component merging f05 and DDO deals will be thrown away after Spark v1 is sunset.