Create app.go for gov-enabled consumer chain

[mpoke]

This issue refers to the so called democracy package (see #66 for details).

app/gov-consumer/app.go, should contain the modules necessary for the minimum viable consumer chain (see app/consumer/app.go) and in addition the modules necessary for the gov-enabled consumer chain:

• x/ccv/staking module is enabled (see feature: support "democracy" module #89)
• Governance module is enabled and connected to x/ccv/staking
• Mint module is enabled and connected to x/ccv/staking
• x/ccv/distribution module is enabled (see gov-distribution module #130) and connected to x/ccv/staking

[okwme]

@hxrts and I created a voting matrix with a first pass about which chain should be in charge of which votes. The bulk of this sheet is param changes which could be debated.

https://docs.google.com/spreadsheets/d/1s7IGkxIjvebFu0guC5iFC4gWaEOJLBWx2QQHik9WmYo/edit?usp=sharing

The primary proposal type that imo should be performed by ATOM token holders is the upgrade proposal. Our messaging is that ATOM validators don't need to worry about gov on these consumer chains because they have their own gov tokens. This is true except for factors that impact the validator directly. Upgrades need to be prepared and performed by validators so I think it's important they happen on the hub where validators are still meant to be active.

This would be possible by leveraging the adminmodule inside of the composer repo: https://github.com/cosmos/composer/tree/master/x/adminmodule
If the Cosmos Hub gov module account were listed in the whitelist then the cosmos hub gov module could send out proposal + vote msgs using interchain accounts. That way it is voted on the hub and if it passes it is submitted to the consumer chain and immediately passed.

[jtremback]

The ultimate objective of this issue is to create a chain in the /app/gov-consumer folder which implements the "democracy suite". The "democracy suite" is collection of modifications to certain modules and app.go which allows several things to take place on a consumer chain:

• The consumer chain has a native token much like the native staking token on a normal Cosmos chain.
• This token can be delegated to "representatives". Representatives are just like validators on a normal Cosmos chain, but they do not have any responsibility to run chain binaries (obviously, these are run by the provider chain validators).
• Not running chain binaries, the only responsibility of representatives is to vote on governance proposals. Their role is to allow governance token holders to delegate decisionmaking responsibilities to someone they trust.
• The governance token will also inflate (just like a staking token on a normal Cosmos chain). This inflation will go to representatives and the people who have delegated to them. But also some percentage of the inflation is sent over IBC to the provider chain and is distributed to the delegators and the validators there.

There is already a lot of work that has been done:

• https://github.com/cosmos/interchain-security/pull/89/files - staking work that is already in main
• 0ef7264#diff-7ccc79d278c9efceedd48edafab578c90785e01c71e0d169affcc9412bbceda8 - distribution work that needs to go into main

Here are all the things that should be possible once this work has been completed and integrated:

• Start gov-consumer and provider chains
• Distribute gov-consumer's tokens to accounts
• Check that delegators on gov-consumer chain can change representative powers
• Have accounts vote on something on the gov-consumer chain
• Check that the parameter is changed on gov-consumer chain
• Check that gov-consumer's validator powers are updated by the provider chain (as is normal)
• Check that delegating on gov-consumer does not change validator powers
• Check that tokens are minted and distributed to representatives and their delegators
• Check that tokens are minted and sent to provider chain and distributed to validators and their delegators on provider chain
• Check that slashing on the gov-consumer chain does not result in slashing for the representatives or their delegators

Implement automated tests in the integration tests folder for these things.

[jtremback]

@smarshall-spitzbart We need to talk about you helping @dusan-ethernal @stana-ethernal to test this stuff in the integration tests.

[jtremback]

@stana-ethernal @dusan-ethernal Can this issue be closed now?

[stana-miric]

@jtremback it can be closed after we finish integration tests and clean up some logs in PR. We will let you know once we finish it