CBR Proposal: Update 1 - Addressing Some Concerns
CBR Proposal Update
The community has been full of conversations and questions for the past two weeks. This post will attempt to summarize a few main points discussed during this time. Feel free to take this opportunity to ask more questions!
Results of the Poll
There was some confusion about whether there will be an averaging of the poll results.
As stated in the "Action" section of the proposal, the winning value will be the coded value. There will be no averaging of results.
Concerns
Beyond general questions that have been answered on the poll threads, the main concerns have dealt with the possible centralization and Earned Research Reward (ERR) distribution problems that CBR will produce.
These concerns can be broken into two concepts:
- Netweight / Competing for blocks
- Actual Block Creation
The netweight concern is that the difficulty CBR will bring to the network will discourage crunchers from maintaining an online balance (because of capitulation, MRC, or increased pool use). This would centralize the blockchain's netweight into those fewer large balances kept online to compete for blocks. This would also reduce the number of nodes connected to the network.
Centralized block creation is a similar concern, but involving the actual creation of blocks. With a higher difficulty, will only those with large balances be able to stake blocks?
Tied in with both of these concerns is the question of how to get crunchers their ERR. Limiting ERR distribution to staked blocks is an issue without CBR, and will become a problem when CBR is implemented.
Current Reality
Gridcoin currently operates by forcing (not incentivizing) crunchers, generally low to medium balance wallets, to maintain an online balance. If crunchers do not maintain an online balance, they will not stake a block. If they do not stake a block, they will not receive their ERR.
At the same time, holders of GRC who do not maintain a magnitude are given their 1.5% APR regardless of whether or not they maintain on online balance.
When taken together, these points mean that the blockchain's netweight is generally secured by crunchers. This means many nodes of small to medium balances are competing to create blocks. In general, block creation is also distributed among these many nodes.
This structure of forcing low to medium balances to secure the network while providing idle-incentive for larger balances creates a system that allows for complete centralization of block creation whenever a large balance comes online. As soon as there is a moment where block creation is "owned" by one entity, even if block creation is entirely distributed 99% of the time, the blockchain is at high risk of manipulation. This is a major factor in much of the support for CBR. We need an increased and stable netweight so high balances cannot come online and centralize block production at will. We need many high balance wallets and many low to medium balance wallets competing to stake blocks.
Additionally, while the ethics behind forcing crunchers to stake to receive their ERR while large holders receive idle rewards can be argued, the technical scaling issues cannot. We have ~960 blocks produced a day, or a maximum of 960 ERR distributions a day. This will not scale.
So far, the main solution to the ERR distribution problem appears to be Manual Reward Claims(MRC), though MRC is by no means a definite development. Other solutions may pop up.
If we assume MRC is implemented, however, centralization concerns will be heightened: If crunchers are not forced to to stake, why will they contribute their low to medium balances to network security?
Addressing the Concerns
First, let's outline a few potential developments underway that might help address these concerns:
The most recent CBR poll stated:
Do you think the Stake Weight Problem is something that should be fixed in 2018, and how?
Yes, Constant Block Reward With Continued Exploration Into More Long Term Solutions
One of those potential long term solutions is developing a secure DPoR protocol.
@Brod is working on beacon minting which is essentially a type of DPoR. If proven secure and implemented, beacon mint will help crunchers stake based on the balance they hold in their RSA. Beacon mint is still in the early development and testing stages, so do not expect its implementation any time soon, if at all.
https://github.com/gridcoin/Gridcoin-Research/wiki/DPoR-Payments#beacon-minting
https://github.com/gridcoin-community/Gridcoin-Tasks/issues/172
@Ravonn believes they have found a way to remove the 6 month limit to GRC held in an RSA by forwarding that GRC to a new beacon. Let's call this beacon forwarding. [source?]
If beacon minting works out, both centralization concerns will have been addressed as crunchers will be given a greater likelihood to stake based on their contributions to distributed computing tasks. Beacon minting also pairs nicely with MRC if we build MRC to serve as an alternative to ERR distributed by staking.
If beacon forwarding works out, the requirement to stake before 6 months have passed will be gone, though it will still be arguably unreasonable to ask crunchers to wait 6+ months to receive their ERR.
If neither of these improvements are implemented, the concerns behind CBR and MRC (or some other scaling and ERR distribution solution) can still be addressed.
Netweight centralization can been condensed into the question: With increased netweight and competition, and if they do not need to stake to receive their ERR, why would someone keep a low balance wallet online?
They will still receive rewards when they do stake. A 1,000 GRC balance staking twice a year (difficulty 18) is 2% effective APR (CBR value of 10). Use @jamescowens rule of thumb math, ETTS in days = (10000/balance)*Difficulty, to determine time to stake for balances at different difficulties.
Using the above formula, and assuming a difficulty of 20, we can estimate that a balance of 25,000 GRC will stake every 8 days. That may be a reasonable stake time to incentivize network participation. We can safely assume that there are a significant number of participants with 25,000 GRC or more. source When put in larger context of alternatives such as DPoS, masternodes, and an insecure network, a network secured largely by balances greater than 25,000 GRC is both decentralized and secure.
Based on activity on other PoS blockchains, it is likely that many participants will keep their GRC online regardless of balance.
When it comes to actual block creation, the argument is:
Secure network with semi-centralized* block creation (CBR) VS. insecure network with absolutely centralized block creation when a large balance comes online (current %APR).
*The semi-centralized block creation of CBR is still likely to be more decentralized than PoW, DPoS, and masternode systems.
In the end, CBR centralization concerns are valid, however not as dangerous as maintaining the current %APR and ERR distribution systems. Additionally, the problems CBR presents can be addressed through future developments such as beacon mint or other improvements to PoS being worked on throughout the larger blockchain community.
These problems are in no way unique to Gridcoin. They are discussed in many PoS communities.
We look forward to further discussion on the subject.
If you find yourself with any other questions or concerns, please do not hesitate to ask!
You can vote on the CBR Proposal and Poll until June 6th.
We need to convince network participants that even staking their 1000 GRC balance is worth it as it disrupts larger stakeholders. Even though at an individual level this seems insignificant, a large number of small stakeholders would have the desired effect of breaking up larger stakeholders rewards. Perhaps publishing stats on it would help.
I also still think PoST is worth a review as if I understand it correctly, smaller holders chances of stake are improved (needs a smarter brain than mine to confirm).
I'm just joining the project and learning about Gridcoin from a friend. I bought a little over 2k GRC and sent it to my wallet to stake and just got my first payout (I assume) from running network projects. Am excited to learn more!
Welcome, lots of nice people in the community to help you out if you need it.
sleeper account...
What do you mean?
Can someone please clarify the 1.5% APR and how it applies to staking?
Does this mean everyone who holds GRC in a wallet will get 1.5% interest even if they don't keep the wallet online? And when is the 1.5% interest paid?
Or is staking a requirement to get the 1.5% interest?
How is the 1.5% interest paid out (stake reward)? For example let's say I have 2000 GRC in my wallet today and it takes 12 days to stake would I get 20000 GRC *.015 (interest rate)/365 (years in a day) *12 (days to stake) = 0.98GRC as my reward or interest?
So under the current system if a whale that stake multiple times a day they are only getting 1.5% interest based on the last time they staked? Can someone please explain how the stake rewards works if a whale stakes multiple times a day?
My understanding with the new CBR every time someone stakes their will be a certain amount of GRC (not based on wallet balance) . But the wallet balance will determine how often you stake?
Sorry for the noob questions but I seem to be getting conflicting information form different sources.
Everything you said here is actually pretty accurate.
When you stake.
You can use the same formula you used above only you would have a decimal for days to stake.
Thanks @noah-blaker for confirming. Now another question: What was the purpose of having the 6 month time limit to stake or you you do not get your earned research rewards (ERR)?
There might be another reason but this is what I understand:
Beacons are a type of "contract" that tells the Neural Network to track statistics for a user. Each user tracked adds additional calculations and increases the total size when making a superblock. If there were no expiration on these contracts, the amount of users being tracked but no longer crunch can build up and this can cause issues with superblocks eventually.
The solution to this problem was to have beacons expire after an amount of time. Issue is, if your beacon expires before you stake all Research Rewards being tracked are lost. What @Ravonn proposes is a system where your old Research Rewards can be forwarded to a new beacon once your old one expires. That way no rewards are lost.
Ah yes, makes sense that you don't want a bunch of unused "contracts". But why can't we have it such that if your wallet is kept online then the the wallet automatically updates the beacons (eg. saying "hey i'm still here don't expire") and if your wallet is not online and a gridcoin user is no longer crunching or using gridcoin then it will automatically will expire after 6 months. Will the new "beacon forwarding" proposal by @Rvonn be like a "manual beacon reset" to let the system know that you are still wanting to stake?
The wallet actually does automatically renew beacons. Beacons expire after 6 months and your wallet will try to automatically renew your beacon after 5 months.
Problem is, the newly renewed beacon is an entirely new beacon. As if it were a brand new beacon with no previous Research Rewards. Beacon Forwarding makes it so the newly renewed beacon carries over rewards from your last beacon.
Relatively of-topic. Do you think a stacking pool it's viable? Idea being a service that let's you send your grc there and getting a proportion of the rewards... It requires trust in another party so no large investor would ever want to use such service, but it makes a lot of sense if you just want to stake your 1000 grc. Assuming no PoR rewards are taken on account.
As I understand it, it's absolutely possible that we'll have staking pools built into the network in the future. They would be absolutely trustless and not require a 3rd party.
Yup. Some blockchains are actively working on making this a reality, which is awesome.
This is above my comprehension level.
i'm against anything that makes it harder for new users to stake. from the last talk we had about this, i understood that we needed to do more testing before putting this up for any kind of vote.
this development feels as though it's being rushed through with a narrative that our coin is currently insecure. i tried to address this during the hangout on Saturday, but it was sidestepped. does anybody else feel as though we have a choice as to whether or not this happens? vote weight has been proven to be a problem regarding previous important development polls.
also, i'm not sure what's up with the current trend of... marketing developments. can't a good idea be a good idea on its own? everything is being forced down our throats lately. "we need this, guys... we have a great team working on this thing.." kind of allows people that had nothing to do with the actual coding to attach their names to things...
just my 2 cents. <3
I hardly think this is being rushed at all. This is the 3rd poll we've had regarding CBR (1 2 3), and each time CBR support has been overwhelming in both vote weight and vote count.
I do understand however that this will make it more difficult for newbies to stake and therefore get their Research Rewards, and that has been addressed with the assumption of the implementation of MRC (1). You could argue that it would be ideal to implement MRC before CBR, but in that case in the time we have MRC but not CBR, there is almost zero incentive to run a node. At least to me, that is not a risk I'm willing to take.
We could of course release both CBR and MRC at the same time, and I would defer to the devs opinion if that's an appropriate course of action. I'm unsure if that would be considered to big of a change for 1 release.