Cosmos-sdk: Fork gaiad init --with-txs into another command, let the user inject genesis accounts before the actual genesis.json is generated

[alessio]

New workflow for handling genesis is proposed as follows:

1. someone generates the starting genesis.json file: i.e. gaiad init
2. genesis accounts are injected manually
3. potential validators look at it, then sign gentx to say that they want to become a genesis validator and submit it, i.e. gaiad gentx
4. once they’re gathered, the genesis.json is updated with gaiad collect-gentxs
5. everyone gets the updated genesis.json file and they run it with gaiad start

Discussed with @jaekwon. CC'ing @cwgoes @jackzampolin @zmanian

---

For Admin Use

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

[alexanderbez]

For (2) we should have a tool to do this and a means to verify it.

[jackzampolin]

Agree with @alexanderbez here. I think this is a developer workflow issue. Currently the way to start a chain with an account that the dev controls is a bit clunky. It would be nice if this refactor addressed that issue.

[alessio]

We have a different issue here too actually. At genesis time of Cosmos, we need to inject some accounts before the validator will submit the MsgCreateValidator. The MsgCreateValidator will be validated against those accounts, anyone could actually generate a MsgCreateValidator and become a validator otherwise.

In other words, we need some control over the genesis accounts (CC'ing @cwgoes, with whom I discussed this few days ago)

[zmanian]

For the Cosmos hub genesis,

There will be a piece of software that reads the Ethereum and Bitcoin blockchains and Foundation suggest allocation file and then generates all the accounts in the genesis.json and then the MSGCreateValidator values should be validated against those accounts.

[cwgoes]

We have a different issue here too actually. At genesis time of Cosmos, we need to inject some accounts before the validator will submit the MsgCreateValidator. The MsgCreateValidator will be validated against those accounts, anyone could actually generate a MsgCreateValidator and become a validator otherwise.

Hmm I think we agree but I don't quite understand the phrasing, want to double-check. I just mean that we'll have some set of accounts at genesis, for Gaia. MsgCreateValidators in genesis should be run normally against those accounts in state - so if someone submits a MsgCreateValidator sending from a nonexistent account, it will simply fail, because the account doesn't exist. That doesn't require any "unusual" validation.

We might additionally want a simple CLI tool to check if a MsgCreateValidator would pass, both for testing by validators-to-be and for filtering the genesis file by whoever is aggregating these messages together (since failing genesis transactions cause InitChain to panic).

[alexanderbez]

What about simply a --dry-run?

[cwgoes]

What about simply a --dry-run

That would work - it just has to be dry-run against the genesis account list.

[zmanian]

Do we think that MsgCreateValidator should substract the bonded staking tokens from the amount in the account or checking that an account has sufficient balance should be out of band? I don't have strong feelings either way but it should be specified.

[alessio]

@zmanian the latter I guess
@cwgoes agreed, I'll do it

[cwgoes]

Do we think that MsgCreateValidator should substract the bonded staking tokens from the amount in the account or checking that an account has sufficient balance should be out of band? I don't have strong feelings either way but it should be specified.

It will definitely do the former, that's how the current genesis transaction system works - we set up an initial state with genesis accounts and then run the transactions as normal (a fake block zero, essentially) - so whatever self-bond is specified by MsgCreateValidator will be subtracted from the initial account balance.

I think we should also check out-of-band to ensure that the account has enough Atoms for the message execution to succeed.

[alessio]

It will definitely do the former

Oh right, you mean at gaiad start time. That's true.