Farming reward variables
Explanations and questions
Here I go through the variables, and reason about all of them.
I will probably be overly explanatory, but I prefer that over not being inclusive. I’m hoping that anyone can pitch in with whatever thoughts they have around any part of this.
Variables
d = data percent stored of available
u = unfarmed coins
s = sections count
m = 1 / s
n = neighbor sections' median vault count [1, 200]
x = 1 / n
p = ds + 1
g = ln(p^3.2)
Farming reward
R = gxmd(d + u + 1)
Store cost
C = 2R
d = data percent stored of available
This indicates the storage supply/demand on the network, by showing how many percent of provided is used.
When we move closer to 1 (100%), demand is increasing faster than supply, when we are moving closer to 0, supply is increasing faster than demand.
100 % filled could be true for 1 node and 1 GB, but also for 100 nodes and 100 TB each. So this variable does not take actual storage size into account.
The idea of including this value, is that we want the network to adjust the amount of safecoin paid, based on the demand/supply of the storage, therefore stimulating already connected nodes to add/remove storage, as well as leaving or joining of nodes in the network.
This variable assumingly gives the network a certain capability of assigning value to safecoin based on scarcity of storage. The network adjusts payment for a (relatively) fixed amount of data (]0,1] MB), based on market forces. The bounded range for possible values of data size covered by a PUT, is what makes this a rough valuation of storage, in terms of safecoin per storage size unit.
Questions:
- Do we properly capture supply and demand by this variable, and using it the way we do?
- Is it desirable that the network reflects market estimation of storage value in the reward?
- If so, is it satisfyingly reflected, or do we want to do better?
- Are there any reasons to consider the assumptions above to be wrong?
- Is it necessary to include this variable in the reward?
- What do we gain by including it?
- What do we lose by not including it?
- Are there any unintended consequences of including it?
u = unfarmed coins
The theoretical max of ~4.3 bn coins will exist as farmed and not farmed - i.e. unfarmed. (We include the ICO coins in the farmed category - they were pre-farmed.)
As this model employs recycling, a healthy network that is being actively used, would never see all coins being farmed. The number of unfarmed coins could even increase at times.
This is due to the fact that we recycle the coins spent on PUTs (uploading data to the network) - and transfer them from farmed to unfarmed.
By including this variable the way we do, we represent scarcity of safecoin. The reward is decreased as the level of unfarmed coins decrease - i.e. scarcity grows.
The idea of adjusting reward based on scarcity is partly to dampen any trends of depletion, and it also prevents unfarmed coin from actually depleting.
It seems it is also reflecting the market valuation of the coin, in the sense that if there is a higher consumption of data, than that of storage, it indicates that users value the coin too high to be prepared to pay the storage cost - hence giving a decline in recycling of coins.
Since storage cost C = 2R, if we se a downwards effect on R when amount of unfarmed coins decrease (less is recycled while accessess to data is still in demand, i.e. new rewards are constantly paid from it), it means we will reach an equillibrium where C is low enough for users to be prepared to spend safecoin to upload data.
Questions:
- Is there any reason we would not want to adjust reward based on scarcity of the coin?
- Is it necessary to correlate R to scarcity of coin, when we have recycling of coin?
- What positive/negative effects do correlation between R and scarcity of coin give when combined with recycling, and when recycling is not used?
- Are there any reasons to consider the assumptions above to be wrong?
- Is it necessary to include this variable in the reward?
- What do we gain by including it?
- What do we lose by not including it?
- Are there any unintended consequences of including it?
s = sections count
The number of sections in the network.
Due to the bounded range of possible members in a section (given by the split & merge rules), it is a fairly good indicator of network size in terms of number of nodes.
We assume that network size is an indicator of safecoin value by this logic:
When few vaults are running, we assume there are little economic margin associated with it. Many machines running, would indicate that it is very attractive to run a machine, and thus we assume that it is lucrative, with high margins.
Additionally, we assume that a larger network is an indicator of increased adoption and breakthrough of the technology and evidence of its larger usefulness and value. We don’t need to know in what way, the sheer increase in number indicates that it is more useful in any number of ways, collectively making it more valuable to society, and thus any currency which is required for utilization of the network, is more valuable.
A higher section count is desired as it supposedly increases performance and security.
More sections means more elders so better distribution of consensus and workload (assuming elders is constant and not proportional)
More sections means less coins reside in each section so is safer from attack and less need to expand
More sections means more total age (more events to age from) which affects security and reward distribution
As reward increases when section count drop, it also increases motivation for new nodes to join, and therefore section count to increase.
The idea is to reflect market valuation of the entire network in the reward, and stimulate security.
Questions:
- Are there any reasons to consider the assumptions above to be wrong?
- Is it necessary to include this variable in the reward?
- What do we gain by including it?
- What do we lose by not including it?
- Are there any unintended consequences of including it?
n = neighbor sections’ median node count
This is the median count of nodes in all of a section’s neighbor sections. It is thought to be a good enough estimation of median node count in the entire network. The lower the number of n, the higher the reward R, thus increasing motivation of inflow of new nodes when nodes for some reason are leaving the sections. When sections decrease in size (i.e. their node count decrease), their security also decreases, therefore it is motivated to inversely correlate the reward R with n, as to stimulate new nodes to join.
If node count drops drastically and uniformally across neighbours, so that they begin to merge at the same time, this effect would disappear for a while, as the median node count again is high after merges. If node count would continue to decrease after merges, it would again kick in.
Questions:
- Are there any reasons to consider the assumptions above to be wrong?
- Is it necessary to include this variable in the reward?
- What do we gain by including it?
- What do we lose by not including it?
- Are there any unintended consequences of including it?
m = 1 / and x = 1 / n
Both of these are just a different representation of s and n to make the definition of R visually simpler.
p = ds + 1 and g = ln(p^3.2)
This is just a way to manipulate the curve to look in a certain way (specifically: to get R = 1 nanosafe when - according to our guesses now - parameters might indicate world dominance).
It is based on the assumptions that it is desirable to have a specific R at a specific network size, and that with a bigger size we want R to be lower. Those assumptions has not yet been proved I think.
Additionally, it is tied to the assumption that about 100 billion vaults would indicate absolute world dominance of this technology.
Estimates of around 75 billion IoT devices in 2025 https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/, could indicate that 100 billion vaults is an insufficient long term estimate of what world dominance looks like.
Questions:
- Is it desired to avoid such constants and hard coded values?
- Is it possible to avoid it?
- Can we make it more dynamic?
- Is it good enough to rely on network upgrades for adjustments to these?
Summary
It seems that several of the variables try to capture market valuation in one form or another.
- Are they in fact reflecting different aspects of valuations, or are they in the end overlapping?
- Do we need to capture it in all those ways?
- Does this combination of variables give additional value to the model?
- Would a subset of these give more, same or less value to the model?
- Are there any other aspects of market valuation we could or want to capture?
Also, we are including the concept of security, and try to stimulate it as well with the reward.
- Do we want to stimulate security with the reward?
- Does current use of variables do a sufficient / insufficient job at this?
- Are there any other aspects of security we could or want to capture?
And finally:
- Are there any other influences we would like to include in the calculation of reward and store cost?
(I’m sorry if you already know this and I misinterpreted, but just in case: the notation is a short to cut out the zeros, so 1,543345E-5 means 0.00001543345)
