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
Summary
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%)
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
Proposal
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.
Effect
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.
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 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.
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?
