In decentralized systems, one of the key challenges is creating the right economic incentives that then lead to the desired outcomes without centralized control. Our ultimate goal at Datum is to create a high level of utility and trust for developers to build applications on top of the Datum Network. In order to achieve this, we need a healthy and self correcting ecosystem of Storage Nodes.

Our initial design goals for the Storage Node ecosystem are an attempt to create incentives for node operators to get in early, expand as the network grows, and provide a secure and robust network.

Below are the initial Datum Network design goals that influenced the Storage Node economic incentives outlined later in this article.

We welcome feedback on both the design goals and implementation of incentives. We also anticipate that the incentives will evolve and rebalance over time once we see how the network performs on the Mainnet and receive feedback from the community.

Design Considerations

Over capacity protection

Protect against an overabundance of new nodes driving down the average earnings per node

As capacity in the network grows, it gets more expensive to create a new node

Under capacity protection

Protect against the network running out of storage capacity

As the amount of data stored on the network gets closer to max capacity, it gets cheaper to create a new node or increase capacity of current nodes

Single node takeover prevention

Protect against a single node providing a disproportionate percentage of storage capacity for the entire network; make sure the network distribution is healthy

Node staking (which determines a node's storage capacity) gets increasingly more expensive as the size of the node deviates from the rest of the network

Healthy geographic distribution

Ensure nodes are spread out geographically in a way that creates network robustness

Meet developer and legal requirements for geographic storage of data; i.e. GDPR compliance

Dynamic storage and transfer fees

Storage Nodes earn fees for storing and transferring data

Nodes compete on setting the price for storage and transfer

Nodes must meet basic service level assurances in order to compete on price

Nodes will likely provide different levels of service to meet developer needs; e.g. high availability and low latency of data access, etc.

Robust, secure data storage

Ensure a minimum of 3 copies of data replicated across 3 nodes

Incentivize rapid data replication across nodes

Incentivize geographic recovery of lost nodes to ensure the network remains geographically balanced; e.g. if a node goes down in Europe, there's a higher reward for creating a new node in the same region before nodes are created in other regions

Ability for developers to set the desired number of replica nodes to meet pricing and service level needs

High availability of data

Incentivize nodes for remaining online at all times

Penalize nodes for loss of connectivity or lost data

Create incentives for nodes to challenge each other to prove their data is accessible without creating incentives for bad behavior like DDoS'ing other nodes

Mainnet Launch

For the initial Mainnet launch (3 September, 2018), not all of the design goals are fully implemented for 100% decentralization.

Transfer fees, dynamic data replication, and dynamic pricing will be implemented in the near future. Geographic distribution is manually controlled by Datum through the Storage Node Operator application process. This is due in part so we can comply with GDPR rules at Mainnet launch while we implement the necessary features for decentralized compliance.

Over capacity, under capacity, and single node takeover protection are implemented using power law curves to automatically adjust staking prices.

Data replication across three nodes is implemented at the SDK level vs network level. Dynamic data replication and incentives will be launched in the near future. Nodes will be able to earn rewards for replicating data and challenging other nodes to prove data accessibility.

An initial limit of 100 nodes is set to ensure fairness in initial staking prices and earning per node. This limit will be significantly increased as the network usage grows. The limit will eventually be removed once we fine tune the power law curves that govern the node incentives.

Running a Storage Node

At Mainnet launch, node operators must complete the following steps in order to be one of the first 100 node operators:

Fill out the Storage Node Operator application form for applicants in China, please fill out this form instead) Run a node on the Testnet Get selected by the Datum team to run one of the first 100 nodes; selection criteria is based on order of completed application and geographic distribution of nodes Stake a minimum of 1,000 DAT Tokens

Storage node documentation and docker images will be published this week.

Staking DAT Tokens

Nodes must stake DAT in order to participate in the network. The staked DAT provides an economic incentive for node owners to ensure reasonable uptime and performance of their nodes.

The amount of the staked DAT Tokens determines the following:

The amount of data a node can store (capacity) The likelihood of receiving more data to store

A higher stake relative to the network average results in a higher chance of being selected to store new data. This allows for individual node operators to buy in different levels based on their desired earnings potential.

The amount of data stored determines the earnings of each node. Both storage fees and transfer fees* are rewarded to the node.

*At initial Mainnet launch, transfer fees are not yet collected but will be in the near future.*

A minimum of 1,000 DAT Tokens Stake is required to become a node on the Mainnet.

Tokens are staked by sending DAT Tokens to the storage contract listed at the end of this article. A node owner can withdraw staked DAT Tokens by initiating a withdraw call to the storage contract. Staked tokens can then be withdrawn 30 days after initiating the withdraw call.

In the current phase, the Datum Network supports staking for Storage Nodes. In the future, we will introduce staking for Master Nodes who will secure the Datum Blockchain using a DPOS consensus.

See the Datum Storage Node Tokenomics spreadsheet for details on staking.

Storage Node Earnings

The amount a Storage Node can earn is based on the amount of data stored over a 30 day period.

See the Datum Storage Node Tokenomics spreadsheet for details on earnings and staking prices.

Storage Pricing

At Mainnet launch (31 August, 2018), the price of storage is as follows:

500 DAT / 1GB stored / month / node

Min replication across 3 nodes

100 DAT / 1GB transferred**

A developer storing 1GB of data on the network pays the following amounts in DAT:

100 DAT to transfer 1GB onto the network

1,500 DAT per month to store 1GB across three nodes (500 DAT / node)

Additional transfer fees** to access the data (100 DAT / 1GB of transfer)

A Storage Node that stores 1GB of data earns the following fees per month:

500 DAT from storage fees ~500 DAT from transfer fees** assuming moderate access to data of 5GB transferred

**Transfer fees are not collected at initial Mainnet launch but will be implemented in the near future.

The earnings per node running at maximum storage capacity are equivalent to 10–15% per month (depending on transfer fees) compared to the node stake.

Dynamic Storage Pricing

In the near future, the storage pricing will be dynamic. Storage Nodes will be able to set their own pricing in a competitive market place. This will will likely lower storage costs for developers as the Datum Network usage grows.

Quality Assurance

If a node fails to provide reasonable service levels, fees will be assessed against the node’s DAT stake. Part of the node’s stake will be burnt (tokens destroyed) according to the below algorithm over a 24 hour period if a node goes offline or loses data (fails Proof of Storage).

The intention is to provide reasonable incentives for nodes to remain online by using sufficiently large penalties. We want to avoid situations where node operators could hypothetically go offline yet continue to earn storage fees.

The quality assurance penalties are calculated based on the amount of data stored on a node. This means the penalties for new nodes (who are still figuring out how to best run their node) are not as significant for nodes who have lots of data.

A node is considered to have “failed” if the Datum SDK is unable to get data from a node and then reports the node to the smart contract. The node then has the opportunity to prove to the smart contract that it still has the data before it is marked as inactive and penalized.

The penalties for not being able to prove data accessibility increase in severity over a 24 hour window. A node must come back online and prove data accessibility in order to reset the window.

Proof of Storage challenges are issued once in each of the following time windows over a 24 hour period:

Hour 0 — first failure, start of 24 hour window

Hours 2–6

Hours 6–12

Hours 12–24

This means the penalties are spread out over time, allowing for node operators to restore service to their failing nodes in a timely manner. A maximum of five failure penalties can be assessed in the 24 hour window.

When a node comes back online and completes a Proof of Storage challenge, the penalty assessments are stopped and the 24 hour window is reset.

Node Failure Penalties

1st Fail — 10%

2nd Fail — 20%

3rd Fail — 30%

4th Fail — 50%

5th Fail — 100%

See the Datum Storage Node Tokenomics spreadsheet for details on earnings and penalties.

Penalties are calculated against the amount of anticipated monthly income for the node (relative to the amount of data currently stored on the node) but deducted from the staked tokens. If a node is offline for 24 hours or more, an amount greater than the anticipated monthly income will be deducted. This is meant to ensure best practices among node operators in monitoring their nodes and recovering from failures in a timely manner.

At the time of Mainnet launch, failures are only detected by the Datum SDK when a developer is attempting to retrieve data. The severity of the penalties takes this into account as the likelihood of being challenged multiple times within a 24 hour window is dependent on how often the data is being accessed by an application (and then divided by at least 3 since there are other nodes storing the same data).

Example Failure Scenario

A user tries to access data stored on a node (via the Datum SDK) but the node is unresponsive. The SDK reports the node to the smart contract. The smart contract provides a Proof of Storage challenge to the node.

The node is offline and therefore unable to provide Proof of Storage. The smart contract looks at how much data the node is storing and assesses a 10% penalty (1st failure penalty) against how much DAT the node would earn from storage fees over the next 30 days. The penalty is automatically deducted from the node’s DAT Tokens Stake balance.

Let’s say the node is storing 1GB of data. The anticipated earnings for 30 days for 1GB is 500 DAT. The first penalty is 50 DAT (10%).

For the next two hours, the smart contract will not issue any more Proof of Storage challenges to the node. This gives the node operator some time to restore service before the next penalty window.

After two hours, if the node has not come back online and completed a Proof of Storage challenge, the 2nd penalty is assessed of 20% (100 DAT).

The node now has 4 hours to come back online and complete a challenge before the 3rd penalty is assessed.

Let’s say the node completes a PoS challenge 5 hours after the first failure detection. As soon as this happens, the 24 hour window is reset. If the node has another incident (let’s say 1 hour later), then the penalty would be back to 10%.

Links

Datum Storage Node Tokenomics Sheet

Connect with Datum

Follow us on social media:

Facebook

Twitter

LinkedIn

Steemit

Telegram (English) (Russian) (Chinese)

For PR inquiries: media@datum.org