This documentation explains the detail content of a governance proposal on Cosmos Network
Topic : Adjustment of blocks_per_year to come aligned with actual block time
Proposer : B-Harvest(cosmosvaloper10e4vsut6suau8tk9m6dnrm0slgd6npe3jx5xpv)
Propose Date : 2019-03-20
- Adjust blocks_per_year parameter to normalize the inflation rate and reward rate
- Adjustment will be executed when send enabling upgrade happens
- Blocks_Per_Year parameter
- There is a parameter called “blocks_per_year” in genesis file.
- The parameter means “how many number of blocks in a year”
- It is used to calculate block provision, which is the inflation reward for each block.
- Current blocks_per_year value is 6,311,520, fixed in genesis.json
- Current Block Time of Cosmos Network
- 6,311,520 can be derived by below formula :
6,311,520 = 365.25 days * 24 hours * 60 minutes * 60 seconds / 5 second
- 5 second is the assumption that each block is produced every 5 seconds.
- But, current cosmos network has +6.5second of block time
- From more than 9 months of test-net experience, with more than 50 validators, we can expect that the block time will be +6.5second for a long time unless significant changes in software or configure happens.
- Influence On Inflation Rewards
- block provision : total inflation rewards for whole blockchain for each block
- block provision is calculated as below formula :
block provision = (inflation_rate / staking_ratio) / blocks_per_year
staking_ratio = bonded Atom amount / total Atom supply
- Number of block produced in current cosmos network is approximately 23% lower than current blocks_per_year parameter because of +6.5seconds block time.
- Therefore we are receiving approximately 23% less inflation rewards than theoretical reward rate.
- Derivation of difference between theoretical reward rate and “actual” reward rate(Example)
- Total atom supply = 236,382,221 atom
- inflation = 7%
- inflation atom per year = 236,382,221 * 7% = 16,546,755 atom
- block per year = 6,311,520(defined in genesis)
- inflation atom per block = 16,546,755 atom / 6,311,520 = 2.62 atom
- actual block per year with our speed = seconds in a year / actual blocktime = 365.25 * 24 * 60 * 60 / 6.75seconds = 4,675,200 blocks
- actual total inflation atom in one year = 2.62 atom * 4,675,200 = 12,249,024 atom
- actual yearly inflation rate = 12,249,024 / 236,382,221 = 5.18%(1.82p% less than 7%)
- Theoretical reward rate = inflation rate / staking ratio = 7% / 32.40% = 21.60%
- Actual reward rate = actual inflation rate /staking ratio = 5.18% / 32.40% = 15.98%(5.61% less than 21.60%)
- Future expectation
- blocktimes will gradually converge to lower half average when connections get better
- when more validators join, still the moving average will stay as it is because newcomers will not have high power
- when many validators adopt kms and hsm, the average blocktime is likely to increase slightly
- Suggested expectation of average blocktime
- 6.5seconds : 4% less than current moving average, similar to current lower half of distribution
- Suggested new block_per_year
- 365.25 * 24 * 60 * 60 / 6.5 = 4,855,105
- Adjust the blocks_per_year parameter from 6,311,520 to 4,855,015 so that it aligns with current blockchain status.
- Timing of adjustment of the parameter is when we have the upgrade for send enabling.
- The actual inflation rewards received after adjusting the parameter will be lifted about 23% so that the reward rate will be align with theoretical reward rate.
- Increased reward rate will encourage Atom holders to stake their holdings, result in higher staking ratio and more stable network.
- Possible Counter-effect
- Holders who decided not to delegate until audited Voyager is ready will have stronger impact on value delusion.
- But I think at the timing of send enabling upgrade, audited Voyager will be ready and most of holders will be able to easily delegate using Voyager.
- Forum Link
- IPFS Link
Looks good to me! Instead of using approximations for block times though, I think the final proposal we vote on ought to have the average block time taken by considering the average block time between blocks 1000 and whenever the latest block is. (Perhaps with a slight amount of lee-way for the network becoming faster, like 1-10%)
it is a good idea. i will prepare the statistics!
Have such margins among intervals will be very good!
it is good, by the way, how should the discussion about the gas Limit be
Debate on this topic.
Fix param vs fix timeout config for most validators to achieve 5sec blocktime
it sounds very good. I have ever thought the rewards for each block were calculated in real time based on different block_time， In order words, the rewards for each block were different when the block_time was different. now,i realized i was wrong.
Understand that I write this not in opposition of your proposal, but rather from a position of “devil’s advocate”.
While I appreciate the work that has been put into this proposal,I think that we need to consider first not that we should be adjusting the reward to match the current blocktime, but rather that we as a community of validators should be adjusting our timeouts to ensure the chain is running to spec.
I think we have to assume that a particular number was specified because there was an expectation of the chain to operate under those conditions. If those conditions aren’t met, I think it is our responsibility to try to meet said requirements, rather than adjust around it.
Perhaps this proposal should open up discussions as to which timeout settings we should be using to achieve the spec, instead of taking the bandaid fix of just adjusting the reward structure. Naturally there are concerns both ways, but I think as a community we should discuss this further before committing.
I completely agree with your general approach on blocktime Tony.
I want to suggest that we might can try some long term steps after several months to gradually decrease our blocktime as below
First, we provide all delegators about blocktime statistics, including each validator’s recent average blocktime of his or her proposed blocks. This will acknowledge community who is dragging the blocktime so that results in longer blocktime for entire network. Then, we can persuade each validator with higher than 6.5sec blocktime to optimize or change their setup so that we can achieve stable 6.5second blocktime. I believe delegator’s pressure on each dragging validator will give them enough incentive to do so.
After we stabilize the blocktime to 6.5seconds, we can further discuss on decrease it to 6->5.5->5 seconds step by step in a collaborative manner. I expect it will take quite several months. During this steps, we should watch carefully about any possible problems arising due to shorter blocktime.
When we achieve less than 5.5seconds blocktime after about 6 months(expectation), we can readjust the “blocks_per_year” parameter so that it again aligns with the blocktime of the blockchain.
In order to attain this, perhaps we should start discussing what values we should be using to help minimize our individual blocks in an effort to meet the newly proposed block time.
I believe 6.5 seconds should be standard because the governance proposal also uses 6.5 to calculate blockperyear.
Thanks for developing this thoughtful proposal. While I generally support the idea, it brings to mind two questions -
1 - Is it too early to make an adjustment?
2 - Related to #1, would an increase in transactions, i.e. when transfers are enabled, impact block times?
3 - What would be required to implement the change and who has the power to implement the decision? Would a network restart be required?
@7alisman_Firmamint brings up an important performance discussion that shouldn’t get lost. I’ve started a new topic here to continue that conversation.
My private opinions about your question chris.
Validators do not have any incentives to reduce their blocktime. Therefore it is very likely that blocktime will not decrease soon. And send enabling upgrade is an easy convinient timing to adjust it.
From GoS experience, yes it has impact on blocktime but when it spreads like a spam.(many txs in mempool)
Every decision should be made by governance(delegators). Delegators are the only one who has power. Because the adjustment is done during send enabling upgrade, there is no additional restart.
I think this article has done a lot for educating everyone about the problem, my issue is that it presents a solution that doesn’t directly fix said problem. I do agree that we need to get rewards more in line with current blocktimes, and trying to share as much as 2.25 seconds off a round is a bit of a leap in one go.
I’d like to further the discussion however, and start talking about SOLUTIONS. Which timeouts should we focus on, should we establish a new set of “defaults” for the software? Do we need to spin up more nodes to spread our individual geographic footprint etc.
What values are some of the faster block proposers using? What settings offer the greatest reduction in block time without sacrificing inclusion in pre commits?
Would be nice for people to weigh in on their experiences so we aren’t all constantly restarting in an effort to test the values. Firmamint right now, proposes 23-25x a day. Some other validators propose every minute, which translates to 1400+ blocks a day.
Let’s assume Validator A represents a similar stake to Firmamint, and their block times are 7.5 seconds, that is ~25 seconds a day, or a lost of 4 blocks of reward. Lets say Validator B has 6.8 second blocks, at 1400 proposals a day, that is 420 seconds a day or ~65 blocks of rewards. As a result, while their timeouts are much more in line with the expected 6.5 second average, they still represent negative effect 16x worse than Validator A.
Either way, my point is, we do have to get things more in line with whatever we determine is the “spec”, but we also need to recognize that our stake affects the network proportionately as well, and if we all work together to find a happy middle ground it will benefit everyone.
Now, bharvest.io/wallet_en shows each validator’s blocktime with moniker!
Before we try to incentivize shorter blocktime, let’s optimize ourselves!
And, I don’t see 6.5second of blocktime as a “problem” now.
Therefore I think we don’t need to execute “solution” to make it 5 seconds.
I think staying around 6.5second is enough for now.
We can try 5 second when IBC is ready. Any opinion on this?