[GOVERNANCE] Adjustment of blocks_per_year to come aligned with actual block time


#1

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

  1. Summary
  • Adjust blocks_per_year parameter to normalize the inflation rate and reward rate
  • Adjustment will be executed when send enabling upgrade happens
  1. 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
  1. 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.
  1. 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.
  1. 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%)
  1. 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
  1. Suggested expectation of average blocktime
  • 6.5seconds : 4% less than current moving average, similar to current lower half of distribution
  1. Suggested new block_per_year
  • 365.25 * 24 * 60 * 60 / 6.5 = 4,855,105
  1. 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.
  1. 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.
  1. 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.
  1. Forum Link
  1. IPFS Link

#2

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%)


#3

it is a good idea. i will prepare the statistics!


#4

Have such margins among intervals will be very good!


#5

it is good, by the way, how should the discussion about the gas Limit be


#6

Debate on this topic.

Fix param vs fix timeout config for most validators to achieve 5sec blocktime


#7

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.


#8

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.

Tony M
Firmamint.io


#9

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

  1. 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.

  2. 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.

  3. 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.