Why Are Incentives Important in the GridCoin Reward Mechanism?

in #gridcoin6 years ago

Introduction

 

Hi GridCoin Community:

In my last post, I wrote about why the current GridCoin reward mechanism - magnitude distribution - may not be the most optimal. In a recent post, @fortex pointed out what I think is a good example of distorted incentives in magnitude distribution (to be clear, I do not know what @fortex's thoughts on this are, that's just my interpretation).

In my original post I went straight ahead into listing the problems and potential solutions regarding the magnitude distribution. However, I did not explain well why the incentive structure is important for the GridCoin community. I would like to address this problem in a math-oriented way in the future, but in this post I want to explain why I think changing the incentive structure is important, and get some feedback as to where research efforts should go.

There are three main reasons:

  1. Fairness
  2. Public Relations and Marketing
  3. Resource Allocation

The first two are practical, and the last one is more of a matter of where GridCoin is heading in the long term, but all three are interconnected. While it may take a long time before any improvements, of any type, are implemented, I think it is beneficial to continue and contribute to this discussion, which has been going on for a while.


Fairness

 

If GridCoin rewards users for contributing their idle processing power (IPP) to distributed computing projects, why should I receive a different reward for different projects? Here are two good reasons:

  1. My hardware architecture is better suited to some projects than others
  2. The community agrees that some projects are more deserving of computational resources than others

These are completely valid concerns, and the current magnitude distribution, which gives all projects equal magnitude, does not address either of these problems.

  1. Hardware architecture: I want to crunch a project, but my hardware is not suited for that task. Example: I want to crunch Milkyway@home, which requires FP64 (Floating Point 64) precision calculations (for an excellent tutorial on this, see Vortac's post(s)). However, I only have a measly GTX 1080 Ti (just kidding, great card), which is not going to perform well on Milkyway@home at all for the reasons mentioned in @Vortac's post, compared to an HD 7970. How can we compare contributions from a GTX 1080 Ti on one project, with an HD 7970 on another, not to mention adding CPUs into the mix? None of these problems are addressed by the current magnitude distribution.

  2. The more popular a project is, the less GRC you are going to receive for crunching that project. I consider the popularity of projects a natural "ranking" in a sense (though there are good arguments against this line of reasoning); actually ranking projects is another matter entirely. This means that projects which the community effectively feels are more worth crunching will reward crunchers less, not more - thus incentivizing users to crunch smaller projects that the community "effectively" feels are not as worth it. Now, there are good arguments for making sure smaller, less popular projects get enough computational power, as well as for ranking in general. This was discussed extensively in my last post, and I hope it is discussed more in the future.

Public Relations and Marketing

 

Another one of the purposes of GridCoin is to increase the number of active users contributing to distributed computing. When someone is considering joining, I think they want simplicity and security.

Some examples:

  1. Clear Rewards: How much GRC (at least approximately) will I get with piece of hardware X?

  2. Security: Is there any way I will not get my fair share of GRC? Can the system be cheated/rigged?

  3. Plug and play: The reality is, the easier it is to use BOINC and GridCoin, the more people will be attracted. If my rewards are not (strongly) related to the project I want to crunch, I consider that a good thing. It means I can focus on the project and not the GRC.

Resource Allocation

 

For me, one of the main questions is, how do we grow GridCoin and change the way large-scale, distributed computing is done? I think eliminating significant magnitude distortions smooths the way for this process. For example, I wish I could crunch for Climate Prediction and earn GRC for it (actually, I think this would be a great way to bring new members in), but it's not even whitelisted - for valid reasons, but still, it's just an example; there are other projects which fit the bill. For a potential future example, see @gregan's post.


Conclusion

 

Disclaimer: Currently, in choosing my projects, I take into account both how worthy the project is, and how much GRC I could make from it (with the exception of Moo! Wrapper, which I crunched after running out of Milkyway@home WUs, not seriously inquiring into what it was actually doing). I just think eliminating or reducing this incentive as much as possible is desirable.

Please comment! In the future I would like to analyze this problem from a mathematical point of view. In particular, I would like to explore the different implications of a completely decentralized GRC reward mechanism, which awards users solely on the amount of work done by their hardware, a more centralized reward mechanism, in which some projects are given preference over others, and what realistically achievable versions of these mechanisms look like.

What do you think? Centralized or decentralized? Or keep it as it is now? Or something entirely different? Why? The more feedback I receive, the more relevant these efforts will be.

Sort:  

I agree with you that it would be great to have a table telling me how much GRC I can get out of my hardware. What we would need for that is an easy way to compare the amount of computations one has done.

For that, Boinc provides RAC and Credit. As far as I know, the goal is to get away from RAC to the Credit difference one has achieved between two superblocks to calculate the reward. This will simplify the reward calculation because then we might be able to simply calculate GRC/Credit (will change over time with changing team credit, but slowly) and give better information.

The problem now is, how do we compare different projects? The Credits generated on each project for the same computation is - mildly put - not the same. It is impossible to compare Credits for project1 to Credits for project2. Therefore we would either need a reference system for each project that we know completes the same computational work on each project and use this system to calculate the reward for everyone or we need another factor. What I think will be hard, is finding one. It can't be CPU-time, since my 5 years old pentium processor can crunch much longer on the same task as my threadripper. I have no idea what it cold be, ideas are welcome.

Gridcoin is not based a hashing function that calculates several thousand/million/billion hashes per second on a machine and can therefore be easily compared. We rely on real life computation and that is the beauty and the burden of Gridcoin.

As for giving different amounts of GRC to different projects, I still don't particularly like that. Who determines the amount? Who determines the value of each scientific field? I don't like the idea of either a centralised power nor of voting. Because the voting is based on a tiny share of all users (a lot of people just don't vote) and would therefore not reflect a well balanced base.

To conclude this: I personally like that I have to tweak around projects to find the optimal reward. It is of rewarding to find a project that gives me 10% more mag and therefore GRC. I think we should leave Gridcoin the open place it is now for scientific computations and not start to value it.

We rely on real life computation and that is the beauty and the burden of Gridcoin.

A poet :)

Thanks for the response @applepiie!

Therefore we would either need a reference system for each project that we know completes the same computational work on each project and use this system to calculate the reward for everyone or we need another factor. What I think will be hard, is finding one. It can't be CPU-time, since my 5 years old pentium processor can crunch much longer on the same task as my threadripper. I have no idea what it cold be, ideas are welcome.

I completely agree, I plan on exploring this in future posts, to the extent that it's possible at all.

As for giving different amounts of GRC to different projects, I still don't particularly like that. Who determines the amount? Who determines the value of each scientific field? I don't like the idea of either a centralised power nor of voting.

I share the same concerns, but I'm approaching it from a different perspective. The magnitude distribution right now is effectively highly centralized. The current protocol is such that all whitelisted projects are given the exact same magnitude. If a user wants to crunch a more popular project, they are effectively punished for it by receiving less GRC. Meaning, if I personally find a project more worthy of my computational power, it's possible that the magnitude distribution punishes me for it.

The current incentive mechanism rewards those who want to make more GRC, not crunch for their favorite projects. The reason I bring up ranking projects is because projects are already unintentionally ranked, as so if they are going be ranked anyway, it should be done intentionally and there should be a good reason for it. Again, I'm not sure if ranking is the best approach, I'm just trying to point out that as it stands, there is a very clear yet blind ranking.

Because the voting is based on a tiny share of all users (a lot of people just don't vote) and would therefore not reflect a well balanced base.

This is currently happening with the delisting of Moo! Wrapper. As far as I can tell, the current whitelisting proposal doesn't address these problems either:

Poll is successful if "Yes" gains greater than 50% of vote share and vote participation is above a weight of 7.5%

and that poll is currently passing with 50 in support (99.35% share), 2 against (0.65% share). I'm not sure how to address this problem either, other than encouraging community participation.

I think we should leave Gridcoin the open place it is now for scientific computations and not start to value it.

Completely agreed.

Overall good post.

The problem with Fairness is that it's unobtainable, as it's too fuzzy. But you have broke it down (a good step) to more defined problems:

  • hardware and rewards - people will change hardware and system will level up / adjust itself; several decades of computer age and nobody found a perfect benchmark for different computer hardware / software / architecture comparisons;
  • popularity - there are several problems; only a minority votes; people tend to join already popular trends; communities tend to be wrong - there was a consensus that Earth is flat and in the centre of the World; non-popular projects could be completely marginalized; humans are notoriously bad in evaluating what is useful and what is not;

ad Resource Allocation
It's unclear to me what you mean in this paragraph.

The problem with Fairness is that it's unobtainable, as it's too fuzzy

I agree that perfect fairness is probably unobtainable; however, I think there is room for improvement in the current magnitude distribution that would make it a lot more fair.

ad Resource Allocation
It's unclear to me what you mean in this paragraph.

I meant that I think more people would be brought into the GridCoin network - i.e. more computational power, more projects, and higher value in GRC - by talking more about the projects that are being crunched - what can we do for science? For health and safety? For all of humanity?

I think there is room for improvement in the current magnitude distribution that would make it a lot more fair.

Most likely there is. Do you have any detailed proposal? It's a bit related to whitelisting problem and I'm recently giving it quite a bit of thought.

As of right now, the main possibilities I have in mind are the ones I laid out in my last post; either rewards effectively based on FLOPS/hardware - as accurately as we can get - or rewards based on an intentional ranking of projects. Further investigation might reveal other possibilities than I just can't see now. But the de facto ranking that we have now I think doesn't make any sense.

I'm recently giving it quite a bit of thought.

Would you mind sharing?

rewards effectively based on FLOPS/hardware

Can you try to put this into numbers? For example just nvidia 1080 vs amd 7970 vs intel i5-6600K ?
After that we can research whether coding such a solution is feasible.

Can you try to put this into numbers?

That's the plan :)

the more the output, the more the reward. I don't pity people with slow outdated hardware. I want GRC to motivate people to push science. The tougher the competition the better for science.

about the value of the project. its up to the user to judge as long as its whitelisted (need to change the criteria for whitelisting)

for popular project with little incentive. its basically. you are in because you believe in the science or just monetary rewards. but not both.

tiering projects and incentivizing popular project will create unfavorable user distribution.

Are you following the TBD project in development?

Right now we are subsidizing the less popular projects by giving them the same weighting as popular projects. This is an important role for Gridcoin to play and we should not completely throw out the baby with the bathwater. However, at the same time projects with more scientific merit should be given a bigger share of resources IMO. If we apply some type of multiplier/weighting factor (2x, 3x, for example) for top scientific and well administrated projects maybe that would be enough to incentive the top performing science projects while avoiding poaching too many from less popular projects.

Thinking about a ranking system, it should be dynamic and ever changing since projects run out of WUs all the time. Perhaps a voting screen could be placed on the gridcoin wallet startup screen in order to encourage people to vote, and vote frequently. Perhaps all rankings could reset after a period of time in order to keep things fresh.

I do love the idea of calculators etc. and I think it should be doable on a per project basis. It may get messy when it comes to comparing cross project.

Also just thought of another idea just to throw out there: What if you could burn gridcoins in order to purchase a temporary boost to your vote. This could open the door for commercial boinc projects.

I think it either you believe in the project or you are in just for profit. people contributed to BOINC because they believe in it without compensation. why should we change that?

I think that there should be some incentive to have more computational resources devoted to projects that are scientifically the most successful.

@ilikechocolate raises a good point that there is already an unofficial ranking of projects in that some are more lucrative than others (either due to special hardware requirements or popularity). Or purely due to popularity, some projects are more competitive than others, which is another type ranking.

I think there is a good argument to be made that we should rank projects on a variety of factors including the above but scientific/social impact as well.

I think we should change our whitelisting process. For me. if it pass the whitelisting they are all equal in value. just choose which suites you. money or the scientific goal.

so if a boinc project want to tap on the grc community they should up thier standard. so in this case. all projects that are whitelisted have thier merits. and thus all proejct are in eqaul value.

Hmm...what if there were multipliers applied for RAC or MAG (whichever way would be easier) for people who broadly allow their hardware to work on all projects vs focusing only on a single project. It solves the distribution of processing power and simplifies the process for newcomers on how to jump right in to the frenzy.

The option would have to use some kind of preset settings to try and avoid computational waste (think 1080ti churning Milkyway WU's) and if the user really wants to use their hardware on very specific projects only they can use the advanced option (like today) and manually select projects. This way newcomers and people too lazy to figure out the performance side of crunching can still efficiently work up magnitude, learn about each of the whitelisted projects, and contribute a little bit everywhere. The hardcore people that know their quad 7990 rig is better off sitting on Milkyway 100% can still crunch that way too...

Hi @zedy44, welcome!

Regarding your suggestion, a few points:

  1. Would that mean that people who want to crunch particular projects would be not receive such a boost?

  2. I'm not sure how this solves the distribution of processing power. Can you elaborate?

Join me Thursday in talking about incentive structures and how blockchains offer a path to entirely new systems!

Thursday 8:00pm eastern. Will you be around? It's the 0x18h podcast -- would love to put together a cohosted block with you on this subject.

I should be able to make that time slot. Are you suggesting a cohosted block for this upcoming session, or in the future?

this week if you want, let's talk on discord. pm me there