feat(genesis): Refactor Genesis to be message based

[testinginprod]

This is more of a discussion than a real action item.

current status

So let's focus on the three duties of genesis as of now:

• Initting a chain: genesis is currently used to init the initial state of a chain, the genesis state is intended as a list of ordered json files which represent some state. So we have JSON state objects converted then into protobuf ones (or whatever the state representation is).
• Exporting a chain's state: this is the reverse process of Initting a chain in which the state encoding is converted into JSON encoidng.

problem

The problem is that this way of doing genesis is often inflexible and conflates state export and import (in a human readable format) with incepting the initial state of a chain.

Proposal

I would propose to split the genesis into two scopes:

• State export and import
• Chain Inception

The first issue is being indirectly solved by the indexer work @aaronc is doing with standardized schemas and collections becoming more human friendly in their JSON representation.

the second problem is chain inception, for this I would like to propose that we make genesis message based, what does it mean to be message based:

it fundamentally means that genesis is just a list of ordered state transitions being executed.

For example, the current status quo on bank makes us do the following:

• Set bank denoms, set balances, etc etc.

How this would change in a message based genesis:

• The first message would be a MsgCreateDenom { denom: uatom, etc.. }
• The second message would be: MsgMintCoins { coin: { denom: uatom, amount: 1000}, address: cosmos1234 } }

The runner of these messages can be a specialized "address" which is treated by modules as a super user.

advantages

• Clean differentiation between state export, import and chain inception.
• No need for order init genesis, since the order is determined by the messages being executed.
• It is possible to alternate genesis steps between modules: eg a genesis could be accounts.MsgCreateAccount, bank.MsgMintBalance, accounts.MsgCreateAccount, and the dependencies between modules can become more loose.
• The genesis flow becomes easier to reason about since we do not need to reason in terms of big chunks of module state being applied but we can see genesis as a series of events (transactions) being executed in order.
• It would make serverv2 encapsulate state transition changes as just messages being executed.