Get the governance proposals

[RiccardoM]

Feature description

We need to get the created governance proposals.

Implementation proposal

To implement this, I think we can simply create a message handler that handles MsgSubmitProposal messages. Such kind of messages should contain all the information that is worth saving about a proposal.

@kwunyeung do you think that would be sufficient?

[kwunyeung]

The current version is getting all proposals from the rest server /gov endpoints. Those endpoints should be able to provide all proposals information including tally results. If we only get the proposal information from the MsgSubmitPropoal message, we will not be able to get the real time tally results and we still have to query the rest server.

There are a few points to consider.

1. The proposal proposer queries from the proposer endpoint is actually traced back from the MagSubmitProposal message in the SDK. That means if the chain has been exported before and restarted, the proposal proposers can't be retrieved as the transaction was removed. We need to consider how to keep this value.
2. The tally result of the existing implementation of the gov is wrong after the proposal voting period is ended. I haven't dug deep into the root issue but looks like it's getting gov is not saving the latest state after the proposal is ended. We may need to save the correct result right at the proposal is ended.
3. The total voting power at the proposal voting period end time would probably be different from the current voting power on chain. Make sure to keep the voting power at the proposal end time so that we know the correct voter turnout.

[RiccardoM]

@kwunyeung About tally results, I've separated them into another issue (#29). About point (1) I don't see the problem. If the chain restarts, won't messages be persisted?

[HarleyAppleChoi]

For (1), won't there are types.genesisState that stored the proposals at the start of the chain? Or you are saying a different thing?
About (3) since we stored the total voting power of validators every 30 seconds, we can match the height at ends the proposals, or stored the voting power again at the proposal ends

[kwunyeung]

For (1), if the chain restart, all txs are not kept and the messages are all gone. If we only read from the REST endpoints, it will have the proposal information and the tally result. You can see that the first few proposals on Cosmos Hub don't have proposal proposers as they can't be retrieved after the upgrade.

https://cosmos.bigdipper.live/proposals/5

Hm... I'm not sure if we really need to consider this. This is the way how the SDK is working. Or we should create an issue on SDK asking for a change in the module. Looks like the module should save the proposer in the state.

[RiccardoM]

@kwunyeung I honestly think this shouldn't be a matter of DBJuno or any explorer at all. Explorers should display the data that can be found on-chain as well. If the chain does not have some data and you display it anyway, you could be accused of manipulating the data. For this reason, I think it's better to ask the SDK team to properly keep the past proposals, instead of doing that work by ourselves.

[RiccardoM]

Closed with #33