Start chain with initial state + sequence of transactions

[UnitylChaos]

Summary

Rework the process of loading a genesis.json file, to load a starting app state, and set of initial transactions to process.

Problem Definition

Currently gaiad init gen-tx generates a json blob for each intended validator, and the gaiad init --gen-txs command processes those and generates a genesis.json file which includes data in the following structure:

• Validators (pubkey, power, moniker)
• App State
  • Accounts (address, coins)
  • Validators (operator address, tokens, + lots of data needed for stake module)
  • Bonds (delegator address, validator operator address, amount)

gaiad export also dumps the current blockchain state into a genesis.json file with the same structure, so that a chain can be restarted with the same distribution of tokens / validator power.

This scheme works, but currently does not have any sort of authorization, validation, or consistency checking of the gentx files or the resulting genesis.json file.
This can lead to problems where gentx files are created for validators without their permission, or one user creates a validator under another's owner address, blocking them from making their own. This also has no system for validating the distribution of tokens that result.

Proposal

The proposed scheme is that we allow the genesis.json file to include both a starting state, and a set of fully valid transactions to be executed in a "block 0" of sorts. The starting state could be as minimal as just the distribution of coins in accounts, with the starting transactions being the self bonds and delegations needed to build the initial validator set. This would allow for "genesis transactions" to be actual transactions, which are validated the same way as bond/delegation transactions in a live chain. The system could also be used to allow chains to start with more complex state such as premade governance proposals or other app specific setup transactions without modifying the initial genesis state.
In the context of state exports for chain restarts or for generation of forks, the starting state could encapsulate the full state without using any additional transactions.

The implementation of this change would consist of adding functionality to run a sequence of transactions included in the genesis file. This would have to happen between when the genesis state is loaded, and when the initial set of validators is passed to tendermint.

This would allow for starfish to be simpler, as users would create self bond/delegation transactions with gaiacli, and submit them for inclusion through some mechanism such as github PRs, or a web form.

---

For Admin Use

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

[ValarDragon]

Why not just require self-signed gen-txs, or have the validator sign the Hash of the genesis file sans the validator set? Seems simpler to implement, and we can just include the signature in the genesis file.

[alexanderbez]

@ValarDragon that does sound simpler indeed, but does not allow for the flexibility of running an initial series of txs. I think both ideas are good in their respective ways. I guess it really depends on what were aiming for here. If it's just verification & authentication, then I'd vouch for the simpler route.

[ValarDragon]

Does anyone else have thoughts on this? The more I think about this, the more I'm in favor of just having self-signed gen-txs for simplicity. (Previous proposed in #659)

gaiad export already puts the governance and staking states into the genesis file. So I see no need for engineering a system for these txs.

[rigelrozanski]

Based on our SDK call today we decided to go with the original idea of simple signing gen-tx's offline using the CLI and then somehow distributing them - something along the lines of #659

[cwgoes]

Based on our SDK call today we decided to go with the original idea of simple signing gen-tx's offline using the CLI and then somehow distributing them - something along the lines of #659

Is there a particular reason we can't execute normal transactions in a fake "genesis block" then run the EndBlock handler and return the associated validator set updates? That way we don't have to implement additional logic duplicating some subset of our existing signature checking & state machine code for validator initialization.

I guess it might not be possible to declare-candidacy from a nonexistent account - but in that case do we want to make that possible for awhile? (holders of Atoms at genesis should be fine, since they can declare-candidacy from their existing account which will be initialized before the transactions are run). I'm a bit concerned about having some actions be possible at genesis but not immediately afterwards, since no genesis ceremony is going to be perfectly fair.

[cwgoes]

Ref #1840 - if we no longer need that logic after making these updates we should get rid of it.