*This document still uses quite a bit of internal jargon. For a public document, all these terms will need to be either explained or omitted. Also, it is work in progress.*

# Storage Rewards

## Introduction

The Storage Rewards are part of the larger storage incentive system, specifically aiming to provide the following incentives for the storer nodes:

* To prioritize the storage of chunks with valid postage stamps.
* To maintain stable overlay addresses.
* To stay online and synced
* To share chunks within the neighborhood.
* Not to create sybil nodes with shared storage.

These incentives are provided through the on-chain re-distribution of the payments for postage stamps and by penalties for not following the protocol. Note that this mechanism requires that syncing -- the delivery of chunks to all storer nodes in their corresponsing neighborhood -- works reliably and reasonably fast.

## Preliminaries

The storage rewards are awarded at regular intervals called *epoch*. Each *epoch* consists of three non-interlapping *phases*, labeled **stake**, **prove** and **claim**. The BZZ amount redistributed in each epoch is equal to the rent subtracted from postage payments during the epoch. (*Maybe the penalties from the previous epoch should also be redistributed?*)

Epochs should be sufficiently long for rewards to dominate transaction costs.

In order to participate, storer nodes must *stake*, i. e. lock some amount of BZZ in a smart contract. The share from the reward is proportional to the staked amount. So is the potential loss due to penalties.

All participating nodes must provide cryptographic evidence to storing all the chunks with valid stamps within their neighborhood's area of resposibility. Nodes sharing at least *d* most significant bits in their overlay addresses are said to be within the same neighborhood. The depth *d* is available from an on-chain oracle and is defined as follows:

Any two nodes with at least *d* identical most significant bits in their overlay address must be connected. For any sequence of *d* bits there are at least *r* fully synced storer nodes with overlay addresses sharing these as their most significant bits.

## Stakes

Stakes are recorded in an on-chain binary trie where a path from the root to one of the leaves corresponds to an overlay address. At the root of each sub-trie (including the entire trie), the total stake *s* is recorded. Thus, for every prefix *p*, one can look up the summary stake *s*(*p*) of all nodes with *p* as their most signifcant bits of their overlay addresses. In particular *s*(*ε*), with *ε* denoting the empty string, is the total stake of all staking nodes. Similarly given *n*, the *d* most signifncant bits of the overlay addresses of all nodes in neighborhood *N*, *s*(*n*) is the total stake of all nodes in neihborhood *N*. Nodes with zero stake are not represented in the stake trie.

Changing the stake of one particular node requires the update of all the stakes from the root to the corresponding leaf in the stake trie. Assuming a uniform distribution of overlay addresses, the expected number of updates is the base 2 logaritm of the number of staking nodes.

Since up to *d* the trie branches on every bit, and aggregated stake values are only ever looked up for prefixes shorter or equal to *d*, it may be worth using a simpler data structure instead of a proper trie, directly recording aggregated stakes in a map *s*(*p*) for all prefixes *p* up to some *D* ≥ *d*. This makes updates in stake values more expensive (requiring O(*D*) updates), but lookups much cheaper, O(1).

Staking nodes can initiate changes in the stakes only during the **stake** phase of each epoch. In order to encourage stable overlay addresses and consistently honest behavior, there needs to be some friction in withdrawing of the stake. The extreme case, when stakes cannot be withdrawn at all has the severe drawback that in a "bidding war" (see below) it limits how far honest nodes are willing to go at the present value of future profits.

In order for penalties to be meaningful, there is a minimal stake *m*.

### Bidding Wars

The security assumption that honest nodes have a majority stake in every neighborhood is a rather strong one. Attackers might attempt to outstake a particular neighborhood in which case honest nodes might need to raise their stakes beyond the budget of the attacker.

If stakes are not recoverable, it turns the bidding war into a "dollar auction" in which many of the outcomes are undesirable. If stakes are fully and unconditionally recoverable in every epoch, it allows for "hit and run" attacks where the attacker gains majority stake in a neighborhood, takes one epoch reward and promptly withdraws in the next stake phase. Thus, for practical security, stakes should be recoverable, but with significant delay, during which they are still vulnerable to penalties.

## The "prove" Phase

During the **prove** phase, the every participating node should submit a blockchain transaction with cryptographic evidence of storing everything within their neighborhood's area of responsibility, i. e. all the chunks with valid postage stamps and addresses sharing the *d* most significant bits with the node's overlay address.

One practical solution is to divide the **prove** phase into **commit** and **reveal** sub-phases all participants must provide the same response to a cryptographic challenge that can be reliably calculated only with access to all stamped chunks within their neighborhood. From the point of view of the contract, it is a Schelling game; the response with the majority of stake behind it is considered to be the correct one. Having the contract verify the actual response would provide a disincentive to sharing chunks within the neighborhood. The security assumption is that honest nodes have majority stake.

For example, a simple challege would be providing proof of storing of the chunk (or several chunks) closest to some anchor *A*_*n* in every neighborhood *n* coming from an on-chain random oracle: Let *p_n* denote the *d*-long prefix of in neighborhood *n* padded to 256 bits, *M* a mask consisting of *d* zeroes and 256 - *d* ones, and *b* the block hash of the last block before the **prove** phase. Thus, *A_n* = *p_n* | (*M* & *H*(*p_n* XOR *b*) ) where *H* is the Keccak hash function.

Another possibility is using *b* as *A* in the neighborhood where *p_n* = *b* & *M* and redistribute to only one neighborhood in each epoch. It would allow for shorter epochs and reduced transaction costs, but would introduce additional variance into storer revenue.

Failure to sumbit evidence or submitting the wrong evidence results in a penalty in the form of reducing the node's stake by some penalty coefficient *r* < 1. If it results in the stake to go below *m*, the stake is zeroed.

## Claiming the Reward and Penalizing Misbehavior

In case of a successful **prove** phase, in the following **claim** phase, every staked node in the neighborhood that revealed a response identical to that of more than half of the neighborhood stake can submit a transaction claiming their share of the reward, which is calculated as (reward) × (own stake) / (neighborhood stake revealing the same response)

In order to verify this, the contract needs to build a *response* → *stake* map and a *node* → *response* map during the **reveal** sub-phase of the most recent **prove** phase, accumulating the stakes of each node revealing a particular response. If nodes are allowed to claim in a later epoch, the epoch identifier should also be part of the key of these maps.

A node can be penalized, if they failed to reveal the majority-stake response during the **prove** phase. While penalizing other nodes is in the interest of all other nodes, there is a "tragedy of commons" situation with the transaction costs of doing so. It can be remedied with refunding the transaction costs to the reporting address, which might require an on-chain exchange between BZZ and the native token.

Maps built during the **prove** phase should be reclaimed at the end of the **claim** phase.

*to be continued*

## Discussion of Incentives

Staked nodes are directly incentivized to store all stamped content within their neighborhood's area of responsibility by the reward.

Maintaining stable overlay addresses can be incentivized by adding friction to moving the stake to a different overlay address.

Staying online is incentivized by requiring each node to submit evidence, which requires both monitoring the block-chain and maintaining an up-to-date local storage, which, in turn requires being synced.

The sharing of chunks within the neighborhood is incentivized by the Schelling game. It is in each node's interest that all other nodes in the neighborhood arrive to the same response to the cryptographic challenge.

Splitting the stake between several sybil nodes does not increase the profits (it remains the same), but does increase transaction costs. Also, it does not change the penalty in case of failure in the *prove* phase.

*to be continued*