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 
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
* 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
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.
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%
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.
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
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?
