Make it easy to initialize contracts in genesis file

[ethanfrey]

Use Case:

I want to launch a chain and create a number of multisig accounts in genesis that control a number of genesis tokens. This is doable for the cosmos sdk fixed multisig, but I would rather use a cosmwasm contract. This should be easy to do, and easy to inspect when reviewing the genesis.

Current State:

We can currently create initial x/wasm state by "dump state and restart" style. However, the format is the raw data and not very human readable.

Proposal:

A much more friendly version would be to allow a number of x/wasm messages to be included in the genesis. We don't need these to be signed by 3rd parties (like gentx), but rather just allow setting a "sender" in the messages themselves. At minimumum, we would want to support MsgStoreCode, MsgInstantiateContract and MsgExecuteContract. This would let us flexibly set the code, contracts, and then make any adjustments (like setting some initial allowances on cw1-subkeys).

To make this usable, we also need a utility to calculate the contract address a priori. This can be calculated deterministically by the code id and the contract sequence. I propose adding a simple cli command to x/wasm and wasmd that take a code id and contract sequence (you can determine this via genesis), and return what the contract address would be. This address then can be used when setting bank balances, or referred to by other contracts.

Alternatives:

Only add support for MsgInstantiateContract and MsgExecuteContract and use the existing format to initialize the code blobs.

[alpe]

I like the idea to make it easier but I am not sure if supporting messages is not adding too much complexity. They would be executed at block 0 with an infinite gas meter and no further validations.
Alternatively a tool can append the data to the right wasm elements so that we can have the same feature but would not have to deal with messages when loading from the genesis. WDYT?

[ethanfrey]

Alternatively a tool can append the data to the right wasm elements so that we can have the same feature but would not have to deal with messages when loading from the genesis. WDYT?

That was my first thought, to run the contracts on a dummy store and then export that. It could work and we could build tools to make it easy, but... it is very hard to validate the state. Contracts state dumps are not meant for human auditing.

The messages on the other hand should be much easier to inspect, using json raw message for the init and execute messages.

Running at block 0 with infinite gas meter seems fine with me. Look at how gentx does that to set up initial valiator stake.

[alpe]

I had a brief look at the gentx impl. The genesis transactions go through the full stack via app.BaseApp.DeliverTx which makes sense as tokes were staked. I think we should do the same as the methods can also involve token transfers. This would require a proper signature for the sender, though. With proper tooling this should not be an issue.

Contract addresses as in weave would be very nice but won't work with the signing. I guess some kind of list command can become handy that prints the address with some contract metadata... 🤔

[ethanfrey]

Contract addresses as in weave would be very nice but won't work with the signing.

Totally, that would be a great way to deal with the address issue - contract:5,15 or so, 15th contract with codeId 5. Oh, wait we need to support those address types in bank, etc to set initial balances, maybe this is more work.

[ethanfrey]

I had a brief look at the gentx impl. The genesis transactions go through the full stack via app.BaseApp.DeliverTx which makes sense as tokes were staked. I think we should do the same as the methods can also involve token transfers. This would require a proper signature for the sender, though. With proper tooling this should not be an issue.

I don't always agree with their design choices. This is one of those cases.

It makes sense for fully decentralized genesis creation, but the truth is, there is always some individual generating the genesis and the validators check it. I mean, we trust all the bank balances in the genesis file (or rather can manually review our contribution and totals match expectations) but do not trust the staking info? It doesn't make sense.

I would make easy-to-read/add message format. And then require all validators/token holders to review their share prior to starting the network. Much easier to work with and read.