Storage Contract Requirements

[dryajov]

Storage Contract Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

• The contract MUST register a list of bonded storage nodes that store portions of dataset
  • It MUST assign "pieces" of the dataset to the nodes without the client interaction
    • The client MUST stay online as long as it takes for the contract to activate
      • If the contract's timeout expires before enough nodes have registered with the contract the contract MUST be cancelled
    • The client MUST make the pieces of the dataset available for the storage nodes to download
    • The contract MAY start as soon as there are enough storage nodes registered to guarantee the integrity of the dataset, but before all the required nodes have been registered
    • The client MAY leave the network as soon as the contract is considered started
    • For a storage node to be registered it MUST submit a stake on chain and it MUST provide at least one successful storage proof
  • The contract MUST verify and record "proofs of storage"
    • When a node submits a correct proof on time it MUST be rewarded
    • When a node misses a proof or a proof fails to verify correctly it MUST be penalized by having the payout for the proof withheld
      • When a node misses or fails several proofs in a row, it MUST be evicted from the contract and it's stake or bond along side it's pending rewards should be withheld
      • When a node is evicted from the contract there MUST be a mechanism that enables other nodes to take it's place
        • The new node MUST be able to reconstruct the missing data from the remaining nodes in the network
          • The new node MUST be able to
            • Download the required pieces from the remaining nodes
            • Rebuild it's own pieces using erasure codes
          • The new and existing nodes MUST be compensated for the download of the pieces
            • Existing nodes MUST be paid for the download of the pieces immediately
            • New nodes MUST be reinstated the cost of the download at the end of the contract period, on successful completion
          • The new node MUST be compensated for the resources used to do the rebuilding of the missing pieces at the end of the contract period
  • The contract MUST keep a record of the rewards and penalties of each node
  • The contract MUST pay out the rewards for each remaining node at the end of the contract
  • The contract MUST have a finite timespan - it MUST have an end

This is being worked on in #83

[Bulat-Ziganshin]

it looks very solid. minor point - we specify new node MUST be compensated for the download of the pieces, but don't say the same about the initial nodes.

also, one thing we should keep in mind - initial ECC can be built either by user or by hosts. In the first case this requirement should be specified in this document, in the last case it should be compensated too.

[dryajov]

it looks very solid. minor point - we specify new node MUST be compensated for the download of the pieces, but don't say the same about the initial nodes.

Good catch! Thanks!

[dryajov]

also, one thing we should keep in mind - initial ECC can be built either by user or by hosts. In the first case this requirement should be specified in this document, in the last case it should be compensated too.

The ECC is heavily dependent on the presence of all or most of the data and the dispersal parameter. It could be possible to perform it on some third party node, but then we would need to come up with a proof that the ECC has been performed correctly. Hence, this is something that we are avoiding for now.

[Bulat-Ziganshin]

The ECC is heavily dependent on the presence of all or most of the data and the dispersal parameter. It could be possible to perform it on some third party node, but then we would need to come up with a proof that the ECC has been performed correctly. Hence, this is something that we are avoiding for now.

let's add this point to our notebooks in order to keep in mind, may be to https://hackmd.io/yTRlMInIRi6fG-nk984ULQ

[dryajov]

let's add this point to our notebooks in order to keep in mind, may be to https://hackmd.io/yTRlMInIRi6fG-nk984ULQ

Great idea!

That notebook is mostly for the simulations that we have planed tho, so maybe we create an issue and tag it with something relevant, like design consideration or something along those lines. I don't believe we have a label for that.

[markspanbroek]

Very nice @dryajov, thanks for writing these down! Would you like me to incorporate them in the marketplace design document, or would you rather keep them in this issue?

I have a few minor comments:

The client MUST stay online as long as it takes for the contract to activate

I would change this to SHOULD; a client is free to post a contract and then walk away, knowing that the contract has a chance of not being fulfilled.

When a node submits a correct proof on time it MUST be rewarded

Proposed change: When a registered host submits correct proofs it MUST be rewarded

Not just any node will be rewarded; only registered hosts. Also it doesn't necessarily need to be rewarded per proof; in the current proposal it's rewarded per time-period during which it provides proofs.

[emizzle]

To be included in the writeup on a new design for marketplace #83.