I like where this proposal is going. I want to check my understanding. Tell me if this is an accurate summary:
/////
Currently, each BOINC project has its own (approximate) conversion from FLOP --> credits. GRC rewarded to a cruncher is proportional to the cruncher's credits divided by the total network credit on the project. However, there are at least two major shortcomings in this approach:
- Practicality. The conversion from credit to FLOP is opaque, and different for each project. This leads to difficulties in estimating rewards, and also in assessing the total output of the Gridcoin network.
- Fairness. Within a project, GPUs are favored over CPUs. An example where this creates problems is PrimeGrid, where there is no incentive to crunch on some very cool CPU subprojects because the GPU subprojects dominate.
By establishing network wide, energy-based conversion factors taking FLOP --> GRC for each CPUs, FP32, and FP64, we solve both of these problems.
/////
Practical aspects of implementation are of course more complex, e.g. preventing unfair manipulation. BOINC has already grappled with this issue for a long time, see: https://boinc.berkeley.edu/trac/wiki/CreditNew.
Their solution is a huge mess. It seems to work OK, but a simpler implementation would be well worth the effort, I think.
Yes that's an accurate summary. One point I'd like to emphasize is regarding this:
A result of the model I described is that a cruncher would get the same amount of GRC with the same piece of hardware on any project, not just within the same project. (This could be changed by ranking projects, but that's a separate issue from this one). One of the goals is to remove the financial incentive to crunch one project over the other, and make that more of an issue as to how much people actually value that project. That doesn't remove financial incentive completely (nor am I suggesting that), just the incentive to move from one project to another based solely on the amount of GRC you can earn.
Got it, thanks for clarifying. That certainly would be convenient to solve more than one issue at once, i.e. without having to introduce an additional variable for ranking projects. On the other hand, this would mean users could only speak with their own mining output, and not with their balance. But right, that starts heading into a different debate...!
Totally agreed, it's a complicated topic. That's why in this post I only focuses on a direct FLOP -> magnitude relationship, which I think solves many different problems simultaneously, but not that one.