Ranking GridCoin Projects + Introduction to Nash Equilibrium

in #gridcoin6 years ago (edited)

Hi everyone:

Following up on my previous posts, I'd like to explore the possibility of whitelisted ranking projects. This is the centralized approach to solving the incentive problems I have been writing about; I investigated the decentralized approach in my last post through a direct FLOP -> GRC proposal.

First, I analyze how projects are currently ranked and its implications, and then explore some other possible ranking metrics.


How Are Projects Currently Ranked?

 

This post is largely a response to/exploration of the idea proposed in @donkeykong9000's post "Gridcoin Multi-tiered White List". The proposal was to split the projects into three tiers, and allocate some percentage of GridCoin to each - e.g. 75% for the first, 15% for the second, 10% for the third.

Currently, all projects are in the same tier - i.e. they are given equal magnitude. This classification is rigid (cannot be changed to account for the opinions of the community), and highly centralized. One of its effects is that some users are able to earn 2-3 times more GRC by running some projects over others, only because more popular projects will yield less GRC for the same hardware.

A multi-tiered system would likely reallocate more GRC to the most crunched projects, but it would not necessarily reward users more for crunching projects in the first tier over projects in the second or third tiers. For example, if the projects in the first tier receive 75% of GRC, but also receive 90% of computational power, crunchers will be incentivized to move their hardware to projects in tiers 2 and 3.

If we views crunchers as competing agents trying to maximize their profits, then this mechanism would eventually lead to a Nash Equilibrium* where 75% of computational power would be received by the first tier, 15% by the second, and 10% by the third. While it is clear that most GridCoin crunchers are not purely in it for the GRC (otherwise, the same thing would happen with all of our currently whitelisted projects - they would all receive the same amount of computational power, and the same piece of hardware would receive roughly equal amount of GRC across all projects), I still think reducing/eliminating this incentive would greatly benefit the GridCoin community.

I would like to refine the model proposed by @donkeykong9000.


* Nash Equilibrium

 

is a solution concept in game theory in which competing agents cannot improve their performance by changing their strategy, while simultaneously knowing the strategy of all other agents. In other words, suppose there are two agents, A and B. Agent A has a strategy, knows B's strategy, and cannot benefit by changing their own strategy. At the same time, agent B has a strategy, knows A's strategy, and cannot benefit by changing their own strategy. These two agents are said to be in Nash Equilibrium. The same principles can be extended to more than two agents.

Applied in this context, suppose GridCoin crunchers are in competition to receive the most GRC possible with their hardware. They will move towards the most profitable projects - this is everyone's strategy. As I mentioned above, this will eventually result in a situation where each tier will receive a percentage of total computational power equal to their share of the GRC. In this scenario, if any cruncher tried increase their minted GRC by crunching a different tier (for example, going from tier 1 to tier 3), then tier 3 would suddenly have more computing power - thus decreasing the original GRC distribution that it had, and tier 1 would suddenly have less computing power - thus increasing the original GRC distribution that it had. Since the original distributions for both of them were equal, there is no incentive to make this move, and this cruncher cannot improve their situation. Since this would apply to every cruncher, no cruncher can improve their positions by switching to a different tier; furthermore, every cruncher knows the strategy of every other cruncher - thus the system is at Nash Equilibrium.

I emphasize that I am aware this is not actually how most crunchers in GridCoin act - we are far away from NE (many ideas in game theory often are far away from reality). This is just a tool that I am using to analyze the incentive structures we have in place.


Other Possible Rankings

 

There is a distinction we need to make regarding ranking projects: are we rewarding the projects, or are we rewarding the users who crunch those projects? This may seem like a trivial difference, but you will see in a moment why this leads to different distribution structures.

Taking @donkeykong9000's proposal a step further, rather than having three tiers, let us have as many tiers as there are projects - i.e., every project is in its own tier, so there is a weak ordering between the projects (weak since projects might end up being ranked equally; a strict ordering would imply that no projects could be equal to each other).

Every person who participates in the poll would assign an individual Quality Score (QS) - say between 0 and 100 - to each project. An overall QS would be derived from these individual QS, creating a ranking. At this point, I have thought of three possibilities to act on this ranking. The first one assumes that after the ordering, all projects should be treated equally - i.e. there should be no consideration given to the differences in size between the QS of projects, just to the actual ordering that comes out of them. The second one takes the actual QS numbers into consideration; these first two suggestions are effectively magnitude multipliers, and they reward the users who crunch higher QS projects. The third proposal distributes GRC strictly proportionally to the QS of the project, and rewards projects.

  1. We currently have 26 whitelisted projects. Suppose we want users who crunch the #1 project to receive 2x as much GRC as those who crunch the #26 project for the same amount of computational work. Along the way, we want the crunchers for any project to receive the same increase in proportion of GRC for every consecutive pair of projects. In this example, that would mean:

    • that users crunching project #26 would receive a magnitude multiplier of 1 (no change)

    • users crunching project #25 would receive 2.7% more than those crunching project #26;

    • users crunching project #24 would receive 2.7% more than those crunching project #25

    • ...

    • users crunching project #1 would receive 2.7% more than those crunching project #2

    • Overall, this would lead to users crunching project #1 receiving (1.027)^26 = 2x more GRC than those crunching project number 26

    • For the sake of accuracy, the number is actually 2.70180507088%

  2. Another possibility to is to normalize to the lowest QS ranked project and use the resulting numbers for the GRC multipliers. For example, suppose there are three projects, ranked at 100, 75, and 50. If we normalize to the lowest ranked project, these numbers become 2, 1.5, and 1, respectively. Then these numbers would simply multiply the GRC for users crunching the respective projects.

  3. A third possibility is to divide the QS of each project by the total QS for all projects. For the example in (2), the total QS = 100 + 75 + 50 = 225. So the first project would receive 100/225 = 44.4% of GRC, the second project would receive 75/225 = 33.3% of GRC, and the third project would receive 50/225 = 22.2% of GRC.

The first and second proposals reward crunchers, and the third proposal rewards projects. From an incentive point of view, the first two proposals would encourage every user to crunch the highest ranked project, and if everyone's goal was to maximize GRC, then everyone would crunch the top-ranked project. As I mentioned before though, this is not the case. If it bothers you that someone can receive 2x more GRC for crunching the most popular project, this is precisely what concerns me about our current GRC distribution - it is the case that some crunchers receive 2-3x more for the same hardware - except right now, that is because those projects have the least amount of computational power contributed to them; here the community agrees some crunchers receive more for particular projects.

The third proposal rewards projects rather than crunchers. While the incentive problems I mentioned earlier in this post (as well as those in my original posts) are still present - since this is basically an extension of @donkeykong9000's proposal - those effects are greatly reduced, thus closing the gap between how users are rewarded for crunching different projects. In other words, at Nash Equilibrium, every project would receive computational power equal to their share of minted GRC.


Conclusion

 

I think there are good arguments both supporting and opposing ranking projects. It is a controversial topic in the community and if it ever actually came up to a vote, I do not know how I would make my decision - it would depend heavily on the details of the proposal. I am making this analysis since there is already quite a lot of interest in ranking projects, and I would like to inform the discussion by analyzing different ways we could that. There are many other ways to rank projects that I didn't discuss here.

What do you think? Should we rank projects, or not? If we should, what do you think the best way to rank them would be?

Sort:  

I don't think that changing the rewards to support popular projects is a good idea. There is a reason that these projects are using BOINC and it isn't because the platform is easy to use or particularly reliable.

If we want to encourage more BOINC projects and encourage them to join the gridcoin whitelist we need to provide incentives for small and new projects to make the effort.

There could be a mixed solution in place. Let's say 25k is guaranteed equally between projects and 25k 'tiered'.

I agree on some points and disagree on others.

I don't think that changing the rewards to support popular projects is a good idea.

My concern here isn't supporting popular projects per-se. It's addressing the massive discrepancies in minted GRC that some users receive for crunching particular projects, which I think hinders the long-term growth of GridCoin.

There is a reason that these projects are using BOINC and it isn't because the platform is easy to use or particularly reliable.

True, but that explains why people came to use BOINC. The issue of being on the GridCoin whitelist is separate - if my understanding is correct, some project administrators weren't even aware that their projects were on the whitelist. The BOINC credit reward mechanism wasn't designed with GridCoin in mind.

If we want to encourage more BOINC projects and encourage them to join the gridcoin whitelist we need to provide incentives for small and new projects to make the effort.

I think a huge, free increase in computational power at no cost is a pretty big incentive - I don't think we need a reward mechanism which specifically encourages crunching smaller projects. That being said, I also have concerns regarding ranking, which is why I laid out a decentralized approach in my last post, and I'm open to other ideas.

For existing projects with an established user base, the changes necessary for Gridcoin are small and usually already in place. That is why some originally didn't know about being on the whitelist.

In terms of encouraging new projects, setting up a new project is a significant investment of time and resources. There is nothing free about the computational power. I would know since I have tried to start a BOINC project before, for my research, and failed.

In terms of encouraging new projects, setting up a new project is a significant investment of time and resources. There is nothing free about the computational power.

This is a really good point. I agree that we should incentivize new projects to join us. I'm not sure that the solution is by giving more GRC to crunchers who crunch those new projects, though.

Nicely written. This seems like the best evolution of the multi-tiered white list idea.

Since we do want to encourage excellence in science without discouraging new/unpopular projects, I like the solution outlined in the first proposal where project #1 receives 2X GRC compared to project #26.

How close do you think we could get to a Nash equilibrium with these solutions?

The other side of the coin is, how do we tally the votes for the ranking? It would have to be based on the current voting system with a lot of weight going to who has the most coins. Is this the best way?

How close do you think we could get to a Nash equilibrium with these solutions?

In the first two, at equilibrium everyone would be crunching the top project, that's the problem. In the current setup, there's massive discrepancies, but eventually at NE each project would get exactly the same amount of computational power. Here, theoretically, there's no limit, though in practice it would probably cause similarly-sized discrepancies between projects that we have now (depending on the multiplier factor), but it would be intentional and subject to community input.

In the third, what's likely is that NE wouldn't be reached and the same scenario that we have now would occur - some users could/would still get more GRC than others. The difference here is, 1) it's more random - i.e. not easy to predict which will get more - as opposed to the current setup where by default less popular projects give more GRC, and 2) the massive discrepancy in received GRC between these projects would be greatly diminished, so while crunchers might still get more GRC with their hardware on some projects rather than others, these effects would be greatly reduced. If this system actually reached NE, every project would get computational power equal to its share of the GRC.

The other side of the coin is, how do we tally the votes for the ranking? It would have to be based on the current voting system with a lot of weight going to who has the most coins. Is this the best way?

Good question. I consider the voting-weight issue a completely separate one from this, since these proposals could theoretically be implemented with any given voting system, including the one we have.

Buen post, saludos.

Congratulations @ilikechocolate! You have completed some achievement on Steemit and have been rewarded with new badge(s) :

Award for the number of upvotes

Click on the badge to view your Board of Honor.
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @steemitboard!


Participate in the SteemitBoard World Cup Contest!
Collect World Cup badges and win free SBD
Support the Gold Sponsors of the contest: @good-karma and @lukestokes


Do you like SteemitBoard's project? Then Vote for its witness and get one more award!