Early demand, and effect on storage costs, after launch

Features
24

I appreciate the difficulty that comes with designing these aspects of the network, but I think the NC variable (the total number of client accounts) is a bad one in this formula:

StoreCost = FR * NC / GROUP_SIZE

Compare a scenario where X amount of clients each consume on average Y amount of resources per day, with a scenaro where 5*X amount of clients each consume on average Y/5 amount of resources per day. The resource usage is the same in both scenario’s, but the StoreCost is 5 times higher in the latter than in the former.

What about this alternative:

  1. Close groups must track the total amount of SafeCoin issued as rewards, and must track the total amount of SafeCoins absorbed from PUTs
  2. Based on the amount of issued SafeCoins and the total amount of SafeCoins in circulation, a target figure of total amount of SafeCoins absorbed can be computed
  3. On every PUT, if the actual amount of SafeCoins absorbed is lower than the target figure, the PUT cost is increased, else if the actual amount of SafeCoins absorbed is higher than the target figure, PUT price is decreased.

Let’s put it in a formula. Step 1 and 2:

I = total SafeCoins issued
A = total SafeCoins absorbed
TA = target total SafeCoins absorbed
S = supply of SafeCoin (0.0-1.0)

TA = I * S

S makes sure that the rate of increase in SafeCoin supply (i.e. inflation) tapers off as we approach the cap. At the cap, S == 1.0, so then the target total SafeCoins absorbed is exactly equal to total SafeCoins issued. Since there may be times when the farming rate algorithm suddenly has to increase rewards, we probably want to keep a buffer of reserve SafeCoins for such times. If we want to keep 10% of SafeCoins in reserve, the formula becomes:

TA = I * (S + 0.1)

Step 3:

MB/SC = Megabytes bought per SafeCoin

if (TA > A) {            //fewer SafeCoins have been absorbed than we want
    MB/SC--;             //So increase the PUT price to start absorbing more of them
} else if (TA < A) {     //More SafeCoins have been absorbed than we want
    MB/SC++;             //So decrease the PUT price to start absorbing less of them
}

A great benefit of this approach is that we actually have control over inflation now. Unlike in BTC where the inflation rate is a function of time (block count), with this algorithm the inflation rate is a function of usage of network resources. More usage (growth of the network) increases the inflation rate, less usage decreases the inflation rate.

Since we start with 30%(?) of SafeCoins already in existence, I should be initialized at 0.3 * 2^32, and A should probably be initialized so that TA == A where S = 0.3.

MB/SC can be initialized at a guesstimate number, the algorithm would quickly correct it to the right value.

3 Likes