I present this paper on how we could change the ways Gridcoin rewards its users. By no means is this a definitive solution, and I may have overlooked something. There are some issues with the rewards structure today, and I wish to address them here with some of my solutions that I think could work.
I'm not a developer on the Gridcoin Research wallet, but I know most of the inner workings of the BOINC rewards structure and how stats are collected, processed and summarized
Todays Problem
One problem that the Gridcoin face today is that the rewards mechanism is skew. Instead of rewarding users, we are rewarding projects.
Today we have 24 whitelisted projects, each receiving an equal amount of distributed rewards between them. It’s first after this distribution that we calculate the user's payment based on their work on that very project. There is no accounting for the scale of the project or other projects for that matter.
The user is therefore not rewarded based on their share of the sum of the network, but rather on their share of the project. As Gridcoin scales up and adds more projects, the larger the difference in users on each new project the more significant is the problem. Something that we have seen already happening today with some of the smaller projects.
Keep in mind that credits between projects are not comparable. A credit score on Project A is not the same as a credit score on Project B. BOINC was not designed to be equal between projects. Gridcoin chose this distribution model since it would make all projects equal and split the magnitude rewards regardless of the Total RAC of the project. Which was a noble idea.
Example Case:
- Project A has 100 users.
- Project B has 10 users.
- Each user only runs either Project A or Project B.
When the rewards are handed out, the 100 users in Project A must share the same amount of rewards as the ten users in Project B. It does not mean that the users in Project B did more work or even more challenging work. The rewards to the users are not equally shared because of the fundamental principles of how BOINC RAC works. The smaller projects users gain more handouts since there are fewer that shares to split the project rewards.
Today’s Rewards distribution:
(Users RAC/Projects RAC)*(115000/Project Count)
Pros: Makes small projects more likely to gain new crunchers due to, possibly, larger rewards
Cons: Uneven shares distribution among users that chose common projects
Possible Solution #1
One, possible, solution that I would like to bring up to the table is to change the way we distribute the rewards. Instead of dividing by the total amount of projects we should spread by dividing project users with total users.
We still can’t compare one projects Score with another, but we can give larger rewards to projects with more users.
Example Case:
- Project A has 100 users.
- Project B has 10 users.
- Each user only runs either Project A or Project B.
When rewards are handed out, the 100 users in project one will have 100/110 (~91%) shares to give out instead of, as before 50/50 (50%). We still can’t be sure that these 100 users have done more work or any at all, but they are a larger group and should gain more shares to divide among themselves.
Proposed Rewards distribution:
(Users RAC/Projects RAC)*(115000/(Project Users/Total Users))
Pros: Rewards are distributed more evenly throughout the network based on total users
Cons: Smaller projects gain no benefit, but are not in any way less likely to gain new users since their share per user is equal.
Implementation Difficulty: Very Easy
Possible Solution #2 (w/ WU Checking)
As I stated in the previous solution, we still can’t be sure if the 100 users are doing any work at all. A large project with many users doesn’t mean they do much more work, they can still have no work, and this is a big problem.
We’ve had this discussion up a lot. We’ve talked about many possible options, like greylisting projects or some automated solution with checking if projects have work units.
One solution is to check the project's data to see if users are submitting work back to them. The users RAC decay if no job gets submitted, and it is more likely that a smaller project with fewer users would have a higher risk of running out of WUs (ex. SRBase) than larger projects (ex. WCG or SETI@Home). It does not mean they can’t have outages and be without work as well.
The RAC score consists of two variables, expavg_credit, and expavg_time. The credit is the score the project server has made for the user based on their work and the time is when the project calculated the score. The current RAC is calculated by a formula known as the RAC Decay and relies on these two variables.
One solution to this problem is possible. By adding a second check to the Neural Network consensus mechanism to check for increments in the variable expavg_time. This project variable will tell you how long ago it was updating the users expavg_credit variable.
When we collect and evaluate the score for a user, we should not only go by the RAC score (after RAC Decay) but also see if the expavg_time has changed. If the time has not changed, it means the project server has failed to hand out work to the user, or the user has chosen to discontinue the project. In any case, we can reliably know that the user has not submitted any work and thus their score should be evaluated more carefully. How large the age of the submission should be, is up to another discussion, however.
By adding this variable to the check, we can single out users that are not contributing to the project, and at the same time also safely identify projects that are failing to hand out new work to their users.
Proposed Rewards distribution:
(Users RAC/Projects RAC)*(115000/((Project Users w/ Increased ExpAvg_Time)/Total Users))
Pros: Would eliminate the need for greylisting. Inactive or passive projects can remain whitelisted without the need to worry about projects to run out of work units.
Cons: Except for a larger change in the NN mechanism, none that I can think of now.
Implementation Difficulty: Medium
It would require the network to record the expavg_time in the chain as well, so we can verify it on consensus. It would require quite a change in this mechanism, however.
UPDATE
It's come to my attention that the rewards distribution has actually been based on (Project_Users/Total_Users) before, and has been exploited. After some thought it would be far to easy to exploit this way of distribution sharing.
Thank you for reading my proposal
Please discuss this topic either here, or on:
GitHub: Link
CryptoCurrencyTalk: Link
Vote for me as Witness
Enjoying what I do and contribute to the community, please vote for me as a Witness or a Steemit Proxy Voter.
By voting for me as a witness, you will support an active witness on Steem and BitShares. I believe a witness should keep up-to-date on current happenings and be a conduit between the many users and the system.
Read my Witness Posts: BitShares, Steemit
Support my Projects: Project Minnow Witness, Gridcoinstats.eu, Crypto.fans
Steemit: sc-steemit 
BitShares: sc-ol 