Open area opened 6 years ago
This issue should cater to solving the remaining todo
s in rewardStakers
function here
There are some details and edge cases around miner rewards which @area has asked me to look into in advance of this implementation. Here is a summary of the various considerations as I understand them:
WP Sec 7.8 states the following:
M
is a function of the total reputation R
in the meta colony:M = R(1 - e^-k)/4 = RKP
For convenience, we'll use the constant K = (1 - e^-k)
as a stand-in for the deK
ay rate and P = 1/4
as the P
roportion of the reputation we want the miners to have.
The idea here is that as reputation decay RK
is a proxy for the amount of reputation, and repeatedly awarding miners reputation equivalent of P
of this decay will eventually lead to a "steady state" in which miners consistently hold P
of the meta colony reputation.
While under hypothetical "normal" conditions (specifically, an active meta colony) this should all be fine, the situation breaks down if the meta colony ceases non-mining work. To understand why, consider a situation where no non-mining work occurs in the meta colony. In this situation, the amount of reputation awarded to the miners in each mining cycle will be P
the reputation awarded in the previous cycle:
R_{t+1} = R_t - R_tK + R_tKP
= R_t - R_tK(1-P)
< R_t // Since P < 1
As a consequence, as t
approaches infinity, R
will approach 0. In other words, this 25% approach will eventually lead to 0 reputation in the meta colony, and therefore 0 mining rewards, removing the incentive for miners to mine reputation for all colonies.
This is clearly undesirable, as we would like the colony network to continue to function independently of the work occurring in the meta colony. (As an aside, the introduction of the developer incentive mechanism would significantly lessen this risk, as that would create a complementary source of reputation distribution.)
Given the aforementioned problem with making miner rewards a function of reputation state, we might consider making miner rewards a fixed percentage of newly minted CLNY, independent of reputation state. If in every period we mint X CLNY, then miner rewards will be XP CLNY. This mechanism seems to avoid the previous problem, as rewards will continue to be disbursed regardless of non-mining work.
This approach, unfortunately, has the opposite problem of the previous. Whereas before, miner reputation and thus reward will tend to 0 over time, here miner reputation will tend to 100% (as all other reputation holders will eventually decay to 0).
A question for discussion is whether 100% miner control of the meta colony is necessarily a bad thing. One might imagine it would increase the risk of instability, as this group may be incentivized to act against the interests of the network as a whole (for example, by allocating more CLNY for themselves). Alternatively, this group may simply lack the skills and experience to make good decisions on the part of the network. That said, in a world in which there is no non-mining activity in the meta colony and miners receive rewards regardless, there does not seem to be a way to avoid this 100% outcome in the limit.
A third problem comes from the need to forecast and budget for miner rewards. As miner reward M
is a function of the reputation state R
, and the amount of reputation is bounded by the amount of CLNY flowing through the meta colony, M
is indirectly a function of CLNY.
If no CLNY could be recycled, then the amount of reputation R
would be upper bounded by the CLNY minting rate, and we could guarantee that CLNY minting would be sufficient to cover M
. Given CLNY recycling, however, R
is no longer bounded by CLNY minting, and so M
is similarly unbounded.
As such, it seems as though we need to allow for a variable CLNY minting rate, to handle cases where M
increases above the current minting rate. There is a possibility (I am still working through some equations 🤓) that the recycled CLNY will always pay for the increase in M
(and thus allow both CLNY recycling and a hard-coded minting rate), but I haven't proven it yet.
It is also not quite clear to me what the impact of a variable inflation rate would be in the context of CLNY, which unlike BTC and ETH is designed to be burnt. Does variable inflation pose less of a risk to a token which is meant to flow from "summit to sea" (i.e. be minted, allocated, and burnt) compared to a token meant to remain in circulation in perpetuity?
There are a number of open questions I am continuing to investigate, but so far it seems as though:
@homotopycolimit has made some comments in #research around the specific procedure for raising the CLNY minting rate (i.e. CLNY vote or mixture CLNY/rep vote), but that's somewhat beyond the scope of this immediate discussion.
After a little more work I believe I can show that any recycled CLNY will never create a total decay greater than the recycled CLNY itself, which means that we can have a fixed inflation rate while allowing for recycling of CLNY.
Also, I have an opinion around the risks of having a variable inflation rate.
First, we should model the way that meta colony reputation accumulates and decays over time, and show that a steady state is indeed reached.
Let R_n
be the reputation state at period n
. Let's assume no bootstrapping of reputation, or rather that reputation never increased by more than CLNY in any period. Let CLNY
be the per-period minting rate, K
be the decay rate (think ~.2 or so) while \bar{K}
be equal to 1-K
. Given that the current reputation state R_n
is the sum of all past decays, we can say that:
R_n <= \sum_{i=0}^n CLNY \bar{K}^i
With equality if all CLNY is paid out in every period. With this, we are interested in the per-period decay, KR_n
, which determines the amount of CLNY needed to pay miner rewards. What can we say about KR_n
?
KR_n <= K \sum_{i=0}^n CLNY \bar{K}^i
= K CLNY \sum_{i=0}^n \bar{K}^i
Here we note that the sum is a geometric series, which we solve as per usual:
<= K CLNY 1/(1-\bar{K})
= K CLNY 1/K
= CLNY
And there we go. As long as no more than CLNY reputation is distributed in every time period, the per-period reputation decay will never exceed CLNY. This is asserted in the WP Sec 7.8 but here's a proof, which is nice.
The above model was worked out en route to answering the more pressing question: what happens if we "recycle" CLNY (allow people to send CLNY back to the meta colony)? In this case, the amount of CLNY distributed per period is unknown (limited only by the total CLNY in circulation). What effect does this have on the decay rate (and therefore the mining rewards)?
Fortunately, the model looks strikingly similar to the one above. Instead of looking at the reputation state R_n
, we will concern ourselves with the total decay D_n
of one injection of recycled CLNY (rCLNY
). The main difference between these formulate is interpretation: in the first, we were interested in R_n
, the current reputation state as a sum of many mintings of CLNY. Now, we care about D_n
, which is the sum of all past decays of a single recycling.
D_n <= \sum_{i=1}^n K rCLNY \bar{K}^i
Again, with equality if all of the rCLNY is given out as reputation. What can we say about D_n
?
= K rCLNY \sum_{i=1}^n \bar{K}^i
<= K rCLNY 1/(1-\bar{K})
= K rCLNY 1/K
= rCLNY
Hooray! Even in the case of recycled CLNY, the total increase in decay (and thus miner rewards) will never exceed the amount recycled. Therefore, if we want miner rewards to be 1/4 of the decay, we can simply set aside 1/4 of the rCLNY for mining rewards. Increasing the minting rate should not be necessary.
I believe these results hold (I need to check) only in the case where miner rewards is exclusively a % of reputation decay. If miner rewards are independent of reputation decay, this may not be the case.
To see why, consider a case where some CLNY is set aside for miner rewards and the rest for work. If a fixed amount of CLNY is paid to miners every period regardless of reputation state, then the CLNY set aside for miners could be spent before any CLNY is paid out to workers. Thus, when the CLNY is finally paid out to workers (and is thus incorporated into the reputation state, and thus contributes to decay), there may not be any CLNY left in the mining reward pool to pay for the increase.
The last thing to discuss is the risks of inflation, i.e. why we might want to avoid including it if possible.
One of the main problems with inflation is that it devalues existing assets denominated in the inflating currency. If I own a house, and the local currency inflates, the value of my house goes up. No problem there. But if I have $100,000 under my mattress, and the dollar inflates, my savings have lost value. IRL, this discourages people from holding assets denominated in the inflating currency.
For small amounts of inflation, these phenomena are not a big deal, but for large amounts of inflation this can be very destructive. Hence central bankers.
In the case of CLNY, the risk of inflation is that it would "devalue" existing reputation. If we mint 100 CLNY per period, reputation will exist on the order of 10^2. If one day we 10x the minting to 1000 per period, reputation will also go up one order of magnitude. New reputation will quickly eclipse past reputation, leading to a disconnect between the reputation state on-chain and the expectations of the colony participants (who expect their reputation to decay at the rate of K).
I just had this thought, but it seems like the inflation rate and the decay rate are playing similar roles in the meta colony. I wonder how deep that similarity goes... is a variable decay rate essentially equivalent to a variable inflation rate?
If miner rewards are strictly a function of reputation decay, than variable minting is unnecessary and perhaps undesirable, as it risks destabilizing the reputation state.
Ok, I have an idea.
Ideally, we would like a few things:
P
) of the total reputation state.I think we can have all of these things, if we do the following:
M_{min} = X
)A
as follows: A = X - RKP
.A
is positive (i.e. RKP < X), add A
to some running total T
and pay out X
.A
is zero or negative (i.e. RKP > X), subtract A
from the running total T
(note that T cannot be less than 0), and then pay out the larger of either X
or RKP - T
.Essentially what this does is ensure that we never pay more than P CLNY out to miners; if we pay the minimum payment X
in some periods, we make a corresponding deduction in RKP
in other periods.
This will necessitate an additional storage variable (likely in ColonyNetwork
somewhere keeping track of a running advance.
TL;DR: everything can work out in the long run without needing a lever for minting CLNY, but a lot of that hinges on the developer incentive mechanism functioning well.
To summarize everything:
Under "normal" conditions (ongoing work in the meta colony leading to significant amounts of reputation payouts), we would like reputation miners to hold about 25% of the total reputation. We do this by making miner rewards a function of the reputation state.
Another nice thing about this 25% rule is that we can show that, as long as we set aside 25% of incoming CLNY for miner rewards, we will always have enough CLNY to pay miners. In other words, the maximum miner reward as a function of reputation state will never be more than the amount of CLNY which enters the meta colony.
Unfortunately, in the case where there is little to no work in the meta colony (an important edge case worth planning for in advance), a simple 25% rule will eventually lead to 0 miner rewards, stopping reputation mining entirely (for all colonies). This is probably the worst outcome.
To handle this, we can impose a small "minimum miner reward" to be paid out regardless of the meta colony reputation state. The major risk here is that eventually miners will come to hold 100% of the meta colony reputation. There's no way around that possibility if we want to guarantee some minimum miner reward, although the incorporation of the developer incentive mechanism will make this vanishingly unlikely by adding a second source of automated CLNY payments independent of meta colony work.
Unfortunately, by paying out a "minimum miner reward", we lose the guarantee that 25% of incoming CLNY will always be sufficient to meet the miner reward requirements, thus necessitating the need to mint additional CLNY to cover mining rewards.
Fortunately, we can get around this via some bookkeeping -- by keeping track of the difference in minimum payouts and reputation-state payouts, we can adjust payments accordingly such that the running total of payouts is never more than 25% of the running total of incoming CLNY, thus obviating the need for a minting lever.
So, it seems like some of this analysis, while fun and interesting, was premature -- it doesn't look like a fixed minting rate is a top priority, and we can expect to mint CLNY manually for the time being. Also, I didn't realize that CLNY for miners is minted directly in the reward
function and is thus independent of other CLNY minting.
So for the first version of the network, I would propose a scheme where the miner reward is max(MIN, decay/4)
, with the minimum being determined along the lines of https://github.com/JoinColony/colonyNetwork/issues/356#issuecomment-431276175 and the overall supply being managed manually by the team for the time being.
Once the network matures it would be valuable to circle back around to this issue as the need for a regular and reliable supply of CLNY becomes more important.
As per the sprint planning call yesterday, the only logic left here is to make the total reward amount a function of the reputation state, noted in this TODO Since we'll be the only reputation miner to start with, this can be icebox-ed away from the Colony Contribute backlog but @kronosapiens can you please double check with @jakzilla to be sure.
Section 7.8 of the whitepaper describes the amount of reputation that reputation miners get from submitting correct hashes, and needs to be implemented. With the merge of #156, they will only get a fixed amount of reputation in an incorrect skill and a fixed amount of tokens.
A special 'mining' skill must be created in the Common Colony, and the reputation miners awarded this skill.
Approximations will need to be used for the exponential decay in equation (3); so long as it displays the correct quantitative behavior, it will be accepted. The exponential factor in equation (2) can be implemented with a Taylor expansion (see appendix B).
In order to implement equation (3), the time that tokens were staked must be recorded; if a user stakes additional tokens, then the new time calculated should represent the weighted average of the staked tokens. This time does not need to be updated when the users are awarded the newly minted tokens as a reward for mining; consider this a benefit of mining (for now, until someone comes up with a reason this is a bad idea).