-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miner compensation #164
Comments
This issue should cater to solving the remaining |
SetupThere 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:
For convenience, we'll use the constant The idea here is that as reputation decay Problem 1: Diminishing miner rewardsWhile 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
As a consequence, as 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.) Problem 2: Miner control of meta colonyGiven 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. Problem 3: CLNY inflationA third problem comes from the need to forecast and budget for miner rewards. As miner reward If no CLNY could be recycled, then the amount of reputation As such, it seems as though we need to allow for a variable CLNY minting rate, to handle cases where 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? ConclusionsThere 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. |
ContinuedAfter 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. 1: Modeling reputation's "steady state"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
With equality if all CLNY is paid out in every period. With this, we are interested in the per-period decay,
Here we note that the sum is a geometric series, which we solve as per usual:
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. 2: Modeling recycled CLNYThe 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
Again, with equality if all of the rCLNY is given out as reputation. What can we say about
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. CaveatI 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. Inflation risksThe 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? ConclusionsIf miner rewards are strictly a function of reputation decay, than variable minting is unnecessary and perhaps undesirable, as it risks destabilizing the reputation state. |
Continued IIOk, I have an idea. Bookkeeping for miner rewardsIdeally, we would like a few things:
I think we can have all of these things, if we do the following:
Essentially what this does is ensure that we never pay more than P CLNY out to miners; if we pay the minimum payment This will necessitate an additional storage variable (likely in |
Concluding conclusionsTL;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:
|
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 So for the first version of the network, I would propose a scheme where the miner reward is 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).
The text was updated successfully, but these errors were encountered: