Storage DFMS

Storage DFMS

  • Docs
  • API
  • Help
  • Blog

›Built-In Features

Getting Started

  • What is ProximaX storage?
  • External economy of the drive

Built-In Features

  • Drive
  • Contract prolongation

Roles

  • Replicator
  • Verifier

Protocols

  • Cross block protocol
  • Fair streaming

Guides

  • Create drive

Drive

A drive is a multisig account created by user that consist of cosigners (replicators, without owner not is user). Think of the disk account as the different boxes that contain copies of your file.

Properties

Drive have next properties:

Owner
User, that creating this drive.

Duration
How long will exist this drive (counted in blocks, required).

Billing period
How often are payments made (counted in blocks, optional 1 month).

Note
Billing period must be a multiple to duration (duration mod billingPeriod = 0)

Billing price
Reward to replicators for participation, which is paid once in billingPeriod (in storage units, optional replicas*driveSize).

Drive size
Size of drive (required).

Replicas
How many replicas the user wants (required);

Min replicators
Minimum count of replicators for starting execute drive (optional replicas);

Percent approvers
How many signatures must be made for accept transaction (optional 100 or 66);

Drive lifecycle

Create the drive

First of all, a user (later the owner) needs to create a new multisign account that will using like drive account. For creating drive owner should to define some field like drive size, amount of replicas, duration, price and other. When drive have created the owner should transfer the amount XPX to the balance that in future will be exchanged on storage unit for payments to replicators.

The example:
User wants to create a new 1000MB (driveSize) drive for 12 month (duration). To do this, he determines that he wants 4 replicas, but drive can start when 3 replicators joined. Also he determines that 100% signatures (percentApprovers) are needed for accepts the transaction. Every 1 month (billingPeriod) 100 (billingPrice) will be distributed between replicators (if drive have 4 replicators then every replicators obtain 25 (billingPrice / count of replicators).

Join to the drive

Any user can view and, if the conditions are satisfactory, join him. When user send join transaction to drive account all participants seeing it and sign it. When join transaction from the replicator have signed, he makes a storage units deposit and then he becomes part of multisig.

Note
Replicator`s deposit equal to drive size.

Drive will has pending status when minimal amount of replicators will have joined. The main replicator will be selected (most often this is the first joined replicator) and he must create transaction to exchange XPX to storage units on drive account. After XPX exchanged to storage units and if it amount on the balance enough drive contract starting up, the status of the disk will change to "in progress". Replicators will obtain reward every billing period automatically and initiate new exchange XPX storage units after ending billing period.

Over time, any number of replicators could join to replicators in drive storage contract. Group of nReliable replicators provide a better quality of Cross Verification. New replicator that joins when the drive has no file may move to the standby mode. In general case, at the time of joining replicator has to fill its memory with all files in the current state of the drive. For this purpose, it initiates the Dir command and downloads each file from Dir results. Payments for data transfer will be rewarded according to the use case Upload.

Actually, drive preparation has no strict time bounds. It is just an initiation of the drive storage contract. If some replicator will join to drive storage contract later its final reward will be calculated considering its time of joining.

Interacting with drive

During the execution of the drive contract owner can interact with drive like on other cloud storages. It is meaning that he can do uploading, removing, changing, renaming, moving, downloading files and can structuring them creating and removing directories.

All commands above create new drive file system that have next properties:

  • Drive key
    Key of drive, that will change.
  • New root hash
    Hash sum of local drive.
  • Old root hash
    Hash sum of local drive before change.
  • Add actions
    New files that added. This is an array of a structure that consists of:
    • File size
    • size of file.
    • File hash
    • hash sum of file.
  • Remove actions
    An array of hash sum of each file that removed.

The command above is the same for the following actions: upload, delete and modify files. Let's look at each action in more detail. In case uploading new file user pays streaming price (file size * (N of replicas - 1)) in streaming units.

Note
(N replicas - 1) because the user has shared this file with at least one replicator.

End drive

When duration of drive end starting so calling "contract prolongation". In this period owner can decide if he need continuation of the drive contract or it is can finished. Also drive can end until deadline if owner decide that he no longer needs storing files.

Status of drive

StatusMeaning
NotStartedDrive created but not generated in blockchain network
PendingDrive wait for minimal replicators or enough amount of storage units on drive account
InProgressDrive contact executing
FinishedOwner finished drive or drive duration is end
← External economy of the driveContract prolongation →
  • Properties
  • Drive lifecycle
    • Create the drive
    • Join to the drive
    • Interacting with drive
    • End drive
  • Status of drive
Storage DFMS
Docs
Getting Started (or other categories)Guides (or other categories)API Reference (or other categories)
Community
User ShowcaseStack OverflowProject ChatTwitter
More
BlogGitHubStar
Facebook Open Source
Copyright © 2019 ProximaX