Cosmos-sdk: Ensuring block provisions are normalized with inflation rate

[sahith-narahari]

Summary

We need to ensure block provisions are normalized with inflation rate without depending on blocks_per_year parameter of genesis file

Problem Definition

The block provision depends on blocks_per_year parameter of genesis file, which is difficult to be determined at the start of network as block time varies based on validator setups and geographical distribution. This was fixed in cosmoshub with a proposal by b-harvest to alter blocks_per_year as a temporary solution.
More details regarding this can be found from proposal 1 here -> https://ipfs.io/ipfs/QmXqEBr56xeUzFpgjsmDKMSit3iqnKaDEL4tabxPXoz9xc

As cosmos-sdk is being used to build various application chains with different validator count and groups, every chain will need a proposal to ensure block provision rewards are normalized with inflation. This should be solved in the sdk so other chains building on cosmos don't have to address this everytime.

Proposal

I couldn't figure out a workaround for this as it needs a change in how rewards from inflation are calculated.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alexanderbez]

What exactly are you proposing @sahith-narahari? Why do you need a proposal for every chain? Should not every application determine the appropriate parameter value estimation of blocks_per_year?

[sahith-narahari]

I would like to add two things here, one is expectations can go wrong (as it's hard to estimate how distributed validator set of a network will be or how many will use setups with increased latency like kms in case of gaia). Testnets also can't be used here, as most validators use minimal setups across testnets over mainnet.

Second being it's hard for network to decide upon the number of validators it will have across the lifetime of a chain. For example, a chain may start intially with less validators(say 50) but may reach 100 over time. Now if we estimate blocks_per_year with 50 intially, we'll endup paying new validators less and vice versa.

[alexanderbez]

I'm sorry, I still don't understand the proposal or what concrete items you're suggesting are...

Both max_validators and blocks_per_year are tunable -- they can be changed on-chain and in a live and automatic manner through parameter change proposals. What exact issue are you trying to solve?

e.g. Gaia started with 100 and it was voted to increase to 125. The same was true for blocks per year.

[sahith-narahari]

Yes, parameter changes are easy to make now. My only concern is we have to estimate blocks_per_year which is a very dynamic values whereas all other parameters in block provision are more static unless changed.
This dynamic quaity of blocks_per_year is making block provisions deviate a little always from the calculated ones

[alexanderbez]

This dynamic quaity of blocks_per_year is making block provisions deviate a little always from the calculated ones

Correct, this is known. What is your proposal?

[sahith-narahari]

Sorry, this totally skipped my mind. My main motive behind this issue was to know if any work is already going on in this direction. I'm working on something and will share the details here soon to discuss further.
What's your opinion on taking this dynamic value(block time) to decide block provisions rather than depending on blocks_per_year from genesis.

[alexanderbez]

What's your opinion on taking this dynamic value(block time)

I'm not completely understanding how this mechanism would work on-chain. Can you outline the proposal, please? Do you wish to the application to track average block time?

[sahith-narahari]

In my opinion tracking average time will have more overhead.
I'm thinking if we can take last block's blocktime and recalculate blocks_per_year for every block just like we're calculating inflation based on bonded tokens.

[alexanderbez]

I don't see how calculating the average block time is more overhead. It should be pretty straightforward on a per-block basis and you can adjust blocks_per_year on this. I think this is what you're suggesting.

[sahith-narahari]

Yeah, I'm fine with both approaches. The end goal being blocks_per_year not being a static value but a dynamic value(based on average blocktime or last block's blocktime) like inflation.

[alexanderbez]

What about a successive simple moving average?

[sahith-narahari]

That should work, either cases we'll need to use only last block's blocktime for computations. We can go forward with whatever you deem is better here.

[ValarDragon]

I'm extremely uncomfortable with any change around how block time is used without analysis of how this affects attacks. We have run into many issues regarding this, and this proposal puts no effort into thinking about any attacks. I'm concerned about how far this got (someone is very far on a PR to implement this) without any discussion of this.

There is a reason we made a static number of blocks per year, it was to prevent the dangers of validators lowering the block's blocktime field from compounding. See attack 2 on https://github.com/tendermint/tendermint/issues/2653. If this proposal goes through, attack 2 gets much worse. (Not only do I get an additional block of inflation, the amount of inflation gets worse)

I am strongly opposed to this change until a proposal per that issue gets implemented to improve BFT time, or I am convinced that my concern is incorrect.

[alexanderbez]

Indeed, but is that documented anywhere at all? It's not immediately obvious there are time-related attack vectors from just looking at the code or documentation (unless you have a strong understanding of Tendermint).

[ValarDragon]

Oh thats fair, I'm not sure if we documented this anywhere. I think most proof of stake decisions need to consider Tendermint (or at minimum malicious proposer / validator attacks), as every parameter induces some security concerns

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sahith-narahari]

To be discussed after Stargate launch