Current Problem with Rewards on Gridcoin and proposed solutions
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 
Issues with my Proposals :(
As @cm-steem points out, there are a few issues with the proposals.
expavg_timethat I present i my second proposal would mean yet another variable in the chain (cause it has to be stored there for verification) that can be abused.Teraflops are great... but BOINC isn't shaped for that :)
I can agree that calculating Teraflops in the equation would be very beneficial, but unfortunately isn't BOINC built to do it that way. An entirely new rewards structure within BOINC is required for that. Something that has been proposed within their community for a while though.
I'm still positive that we can find a good way and I'm not afraid to be proven wrong. The discussion will continue as we progress.
At least you are trying @sc-steemit, you cant fault a person for that!
What will be the difficulty of implementing teraflops calculation? It is not necessary changing current BOINC credit system, but just adding a feature for adding teraflops stats.
In case that is implemented, I suggest divide rewards by platform, that way CPU projects wont be excluded.
TFLOPS are not tracked by BOINC directly. Also, a GPU would hopelessly outcompete 100 CPUs of the same generation.
I know TFLOPS are not tracked by BOINC directly, but we may ask developer team to add that feature. Not changing current credit rewards, that may be very controversial, just adding a new stat. If they reject our suggestion, we may fork BOINC client, that would add additional work for Gridcoin developers but not sure how much.
Rewards may be split in two pools, one for projects CPU and GPU capable and other for CPU only projects. It would work pretty much the same as current whitelist project in that facet.
The BOINC community is currently discussing a new credit implementation, so you could get involved there and put the request on the table. Still, I think tracking FLOPS is far too easy to game by the user.
About forking the BOINC client, I am strongly opposed to that. The point of BOINC is that it is a decentralised piece of software independent from GRC, that anyone can use to set up their own research project server, and let people contribute with the client. Having our own client will introduce another variable that differentiates us from the current BOINC community.
For the GPU vs CPU pools, what about projects that allow you to use either? For example, I could run a SETI astropulse job on a CPU for several days, or on a GPU for an hour. Both have contributed the same amount of compute by the end.
Thanks for your explanation.
For projects that allow using both CPU and GPU you could still mine with your CPU but that wont be recommended as reward would be much lower, the same that happens with current system. I think this is good because that encourages efficient use of computing and protects Gridcoin against potential PoW attacks by GPU miners.
i share the opinion that tracking flops is not the direction we should turn to. This would turn the balance that we are now having completely upside down, things like crunching with a raspi or so ( even now this is not making any revenue :) ) would then be completely off the table. We would then be in the GPU "mining" corner just like every other POW coin (except them with asics which is even worse :) )
For sure a reward mechanism should reward the actual work that has been done on WUs, the variability and flexibiltiy of all the BOINC sytem is what makes it very complicated to find a easy solution. Thanks alot @sc-steemit for bringing up this discussion
You missed the point that even with solution #2 you still don't know wich project did more work. In terms of computations done/Tflops. The 10 users of project B could still have 1000 computers crunching while only 100 computers work on project A. So in my opinion still not a solution to the problem. In fact it will make it even more difficult to compare the projects. You will have to take two variables into account (number of users and Tflops) to find the most profitable project.
I think both of these options are improvements on the current protocol.
However,
I think the ideal protocol would compare Flops volunteered by each user. This would eliminate the need to compare projects altogether: A user is rewarded in relation to the number of Flops they volunteer to BOINC instead of some ratio of RAC. I'm not sure how easy that would be to implement.
In the meanwhile, I think option 2 in this proposal holds the greatest long term potential.
I'm looking forward to this conversation = )
That would eliminate the reward for non computationally intensive projects :( We do not have any at the moment but hopefully some will come back in the future (looking at you @peppernrino).
good point. sc and cm also mentioned that it would require a new BOINC credit mechanism.
I think we need to decide what "THING" we want to give value to. Right now, that "THING" is proportional RAC across all projects. How is credit awarded to BOINC users? I mean, how does a project determine the value of a WU? And how would this translate to non-computationally intensive projects -- such as sensor projects?
With my current understanding, I think we should work toward rewarding the physical contribution toward a project. If it as a computationally intensive project, for example, we try to reward flops in proportion to other contributors. If it is non-computationally intensive, say it is a sensor project, maybe we reward the time the sensor is active along with flops contributed. I'm not sure, just rambling = ).
We probably want "research contributed" as our metric, which is what we do today with the RAC. What I don't like about the current setup is that there is a need to rush between projects in order to maximize profits. I would much rather see a system where you are rewarded more or less equally regardless of which project you choose. You can then pick the project you feel deserves your computing power without having to see your magnitude plummet just because of it.
I'm trying to think of a system where each project is given a slice of the total available magnitude based on how much it has progressed since the last superblock. Then that slice is divided to each of its members based on how much they contributed, kind of like how it would work if you had a pool of pools. The flaw I can't solve is how to determine how much a project has progressed. You can't just base it on percentual credit increase since that favors new projects.
Something along those lines at least. It's still broken but that's where I want to end up. In a world where you don't have to chase the smallest project in order to profit.
I don't think there is any way to find out how many Flops a certain user makes on a project. If we could , that would be a very good measurement.
For projects that are none computational, we could have two different ways of setting rewards, if they are computational or non-computational (WUProp was one for example).
I hope you mean the flops contributed and not the boinc specs of the host. Otherwise it's only a matter of creating hosts and doing/contributing nothing. And what about iops?
yes, flops contributed
FLOPS contributed being the defining metric will skew research entirely towards only GPUs being profitable.
By inflating the userbase with spam account creation (would also require grc nn registration) you could skew thew mag reward calculation. This was once an issue present in the Gridcoin client back in classic days before we switched to proportional rewards & equal boinc project mag allocation.
This issue is present in both your proposals, I think that we should allocate mag in a non-equal manner, determined by a proof-of-burn mechanism in which users can direct more mag to their favourite project in return for a substantial quantity of GRC destroyed.
We should certainly take each project's work unit & server component status into account though, perhaps as some form of greylisting which would prevent allocation of additional rewards during downtime whilst allowing for the claiming of owed rewards for said project.
Doesn't the current system somehow allow users to look for the most profitable projects. Not that I think that is ideal. If it is about profits a situation as you describe wouldn't arise (at least not that extreme) since the system should equalize itself.
Well you can make some educated guesses, like in the example if project A has 100 crunchers, and project B has 10 (assuming all crunchers are active) you have a better chance of getting higher rewards on project B. Of course that assumes the projects are both populated with 'average' crunchers, if project A is populated only by users on one laptop each, and project B is populated only by users with 10 servers, then its not so obvious which project your contribution would net you a greater share of.
Of course, ususally there are a range of users with different capability hardware on projects, so counting the number of crunchers is generally a good guide as to where to point hardware for profitability.
Yes, but there the RAC helps out doesn't it? Just the number of crunchers is a simplification. Also the type of projects GPU/CPU is involved.
RAC unfortunately is not comparible from one project to another (though that was the original idea of RAC), so unfortunately its not much help.
Yes if you have a project woth GPU work, pointing a CPU at it will not make hardly any GRC (but still does science).
Ah. Yes indeed. Never really considered that. So the advise to look for projects with the lowest teamrac is incomplete? Several sources point in that direction. For example the pool. Is there a way to get to the RAC calculations of the projects?
Im not going to say the pools advice is wrong, Im a long time Gridcoiner and come from a time before pools existed, so I only ever solo mined. The pools are run by good people and Im sure they arent giving bad advice.
I just wanted to add the big miner angle to this discussion. As I am a single user, running over 100 rigs, a reward distribution that factors in the total users would decimate my POR. This being despite that fact that I am doing a colossal amount of computation work.
Wow interesting. What exactly is Gridcoin about? Is it worth taking a look at for investing purposes?
Talk soon!
Where to start :D
Gridcoin is a very interesting coin because it rewards computation done on the BOINC platform. The BOINC platform is a program for distributed work that has been around for 15 years this year, and lets anyone in need for computational power to start a project and hand out work units to users.
Before Gridcoin came, this process was purely voluntary and gave no reward in return. Many people run BOINC because of the many humanitarian aspects of the concept. Many of the projects researches on cure for HIV/AIDS, Cancer and TB (WCG) while others try to make an accurate map of the milkyway (MilkyWay@Home) or search for Aliens (SETI@Home).
Gridcoin rewards equally amongst the people on the Gridcoin BOINC Team, which will soon not be required, for the work done amongst the users that has advertised their BOINC ID on the Gridcoin network.
It's a Proof-of-Stake wallet, which means that the wallets own footprint is minimal while being able to divert resources to the important BOINC platform. The community is passionate about the projects and there is today a large group of volunteer developers in the community helping out with various tasks.
The community has a good presence on Steemit under the #gridcoin tag.
Wow my dude, thanks for that in-detail response. I wish I was clear with my thoughts after reading that, but it seems quite over-whelming for a fresh reader haha! So what is the point that you are promoting it? Are you an investor in the coin? Or are you using the platform? Also, I'm guessing from what you just said, it's relating to the medical field.. Curing major diseases right.. So does that mean you need to be like a doctor to earn the rewards?
Just interested :) Talk soon!
I'm just a normal bloke really. Got some invested coins and doing some of the distributed work on the BOINC platform. And no, you don't have to be a doctor to earn rewards :)
I'm just very interested in the concept of helping researchers in their work while also earning some cryptocurrency in the process. It's a coin in development with a community of passionate people.