RE: RAC versus TCD: Case study 1
This effect won't matter unless someone controls ~ > 10% of the weight on a project. So most crunchers shouldn't have to care at all. From the side of project admins, it maybe wouldn't be desirable to have one huge cruncher make up e.g. 50% of the project's total processing power because if that one cruncher went offline or re-allocated resources, there would be a sizable deficit in available processing power. Same with crunching in time. Project admins want to be able to rely on a stable amount of crunch power. Hence the comment about a more 'robust', or stable, network.
If the crunchers had a say in which projects were more important than others this might make sense, but otherwise this creates a highly centralized magnitude distribution which automatically makes all whitelisted projects equal, regardless of thoughts of the community.
This is what I 100% agree with. It is indeed a flaw in the current system that all projects are 'flattened out' and given the same weight on the whitelist. So some large-scale project with huge computational demand can't even petition for more crunch power than a small project with smaller demands or server capacity. We will have to change this down the road via a consensus mechanism. But I think this point is independent from the point about big crunchers distributing resources.
I've looked at a around 5 or so random samples of CPUs from @parejan's posts here and here and it seems like there can be discrepancies over 100% between the same type of hardware (random example - i3-4160T @ 3.1GHz; 2.52 GRC/day on SRBase, 1.01 GRC/day on TN-Grid, though I looked at samples with low, medium, and high number of results).
I completely agree. However, I don't think the current magnitude distribution addresses that problem. The current incentive is such that I can make more than double on some other project, so maybe I'll go there. As it currently stands, that's the case - there are simply massive discrepancies between how much a person makes running one project vs. another. If everyone followed the incentives, there would eventually be an equilibrium where all projects would get the same amount of computational power, and every piece of hardware would get the same amount of GRC on every project. This would guarantee a "stable" (given stable # of active crunchers/hardware) amount of computational power, but it would mean that people might be crunching projects they don't necessarily want to.
I think that the same piece of hardware should receive the same amount of GRC on any project - unless the community agrees that there should be a ranking, with good justification. A large-scale project should only receive more computational power if that's where people want to send their resources - whether through a decentralized "free-market" choice, or through a community agreed-upon ranking of projects - but not based solely on their need.
Sure. I totally get you here. As it stands, earning potential is not even close to evenly distributed across projects. However, this is entirely due to factors outside the scope of my analysis here.
Here I mean stable in time. I'm not necessarily talking about the time-averaged amount of compute power devoted to each project, just fluctuations about the mean.
Yes, this sounds like a good goal.
//
You're bringing up some good points that will have to be addressed in the future. In short, we need to find ways to relieve the tension among the following:
(1) Interest in projects at the level of individual crunchers,
(2) Interest in projects at the level of the entire Gridcoin network,
(3) (~Equal) project earning potential,
(4) Stable network (minimize fluctuations in project compute power over time), and
(5) Project server capacity (small vs large project).
In my opinion the tool we need is indeed a consensus mechanism on the network to decide how to allocate rewards among projects. But some degree of tension will probably remain regardless, i.e. this is a constraint problem where the optimal solution cannot satisfy everyone.
I am just starting to think through these issues in depth. Pending successful implementation of Gridcoin Roadmap 4.0, we will have to address these issues in Gridcoin Roadmap 4.1 :)
Can you elaborate on this tension?
If I'm reading this comment and the other one you made below correctly - please correct me if I'm wrong - is your goal to stabilize (as much as possible) the amount of FLOP/s that projects receive? Is that what you meant by the tension above?
"Interest at the level of individual crunchers" refers to some average person, e.g. a hobbyist, who wants to crunch on his/her favorite project without having to worry about significantly reduced earnings.
"Interest at the level of the entire network" refers to the community's preference weighted by balance + magnitude, as is the case in polls. In my opinion, major stakeholders in Gridcoin should have at least some say in which projects are prioritized. After all, those who have invested most should have proportionate influence over the future trajectory of the coin. This also gives value to the coins as "influence tokens". This last point seems to be somewhat controversial, but for the time being I support the concept.
Regarding your second comment, yes. I wouldn't want to see FLOPS for any given project fluctuating enormously with time. That might frustrate project admins.
I see what you're saying now. I've posted a couple of times about this from the perspective of incentive structures. I agree that there's this problem regarding a decentralized approach and a centralized approach. I just posted today a possible way to address the issue of getting the same amount of GRC for any given piece of hardware on any project. In those earlier posts there was also a lot of discussion regarding ranking projects. I plan to analyze that separately, and I think I'll address what you mentioned here.
Regarding the consistent amount of FLOPS, yes that's a good point. I didn't think about that in my most recent proposal, but I think it might be taken care of as a side-effect. If you can receive the same amount of GRC by running any project, you're more likely to pick a single project and stick with it, so changes to your total computational power should mostly come from new users coming in.
Yeah, a consistent amount of FLOPS will probably come as a side-effect of other measures. But worth thinking about and checking anyways.
Right on about the post! I will go through it in depth soon. In the short term there are things like the greylist and TCD I want to see implemented (so we're not just talk), but beyond that I def want us to come up with additional proposals for improving the reward mechanism (like you've already started on, then also things like ranking projects).
Agreed.
I think TCD is a good step in the right direction. My proposal is more long term, I think there are more important things to be actively developed right now.
I agree that it's a contentious issue, but it's still worth being looked into.
Also, to your point about the distribution of power ("interest of the network"), I also think that should be looked into. Do you have an ideal distribution in mind?
Probably the main factor is to get the right ratio of 'balance' to 'magnitude' as far as voting weight is concerned. We don't want all balance because then a few really rich people could totally dominate voting. This would be much more difficult to achieve if magnitude has significant weight, since a huge mining infrastructure would be required (especially once the Gridcoin network grows to rival the largest national supercomputers, which it probably will). We also don't want all magnitude because large investors should get at least some say in the future of Gridcoin, even if they don't mine.
Currently, the ratio is 70:30 balance to magnitude. This seems to work OK for now. Maybe there's a better answer though if we did more analysis...