Simpler upload/instantiate flow for permissioned chains

[ethanfrey]

A proposed solution to solve #761

Once #796 is merged, governance can adjust the instantiation config after the fact.

Since voting on the actual "store wasm" is a huge blob and lots of gas, I could imagine using that to achieve a much simpler process for permissioned contracts.

1. Anyone can upload a contract. (7 million gas of so)
2. Default InstantiatePermission is Nobody, so the code cannot be run
3. Make a proposal to allow everyone (or just you) to instantiate the contract (with normal gas costs)
4. If passed, you can now instantiate the contract, which is the key point "permissioned cosmwasm" seeks to control

This would replace the current flow:

1. Default CodeUpload permission is nobody
2. Make a proposal to upload some code (voting is very expensive... several million gas), along with the instantiateconfig
3. If passed, everyone (or just you) can now use this code

There is one last little gotcha... We currently allow the user to override the DefaultInstantiatePermssion upon code upload, so they could easily bypass control 2. However, if we make one change, this would work:

If InstantiatePermission is set on CodeUpload, it must be equal to or stricter than the default

• If the default is everyone, you can set anything there.
• If the default is OnlyAddress(x), you can either set the same OnlyAddress (but not changing the address), or Nobody
• If the default is Nobody, you can only set nobody.
• If not set, it will use the default.

This is a very minor change, but coupled with #796 we should solve many of the usability issues around uploading contracts on permsisioned CosmWasm chains.

[alpe]

The gov proposal content is persisted within the proposal in cosmos-sdk. In order to have reasonable gas costs on voting, we need to reduce the content payload. The proposed solution addresses this well. Also the Instantiate permissions rules make sense for me. There is the additional case where the chain permissions are changed to a more restrictive state after the upload. Like before "everybody" becomes "Nobody". How should this be handled?
A) Keep the instantiate permission as defined on creation
B) prevent instantiation
When going with B), we may return confusing permissions in CodeInfo queries.
I am wondering now, if we need the instantiate permission in CodeInfo at all? People can always get the wasm code and may upload it again.

I was thinking if we could end up with lot's of garbage wasm on chain easily that are never instantiated when following this proposal. Inactive gov proposals are deleted at some point.
But this is a different problem and maybe some "prune wasm" gov proposal can delete all code infos that match some conditions so that they are gone in a future state sync snapshot.

[jhernandezb]

I was thinking if we could end up with lot's of garbage wasm on chain easily that are never instantiated when following this proposal. Inactive gov proposals are deleted at some point. But this is a different problem and maybe some "prune wasm" gov proposal can delete all code infos that match some conditions so that they are gone in a future state sync snapshot.

I mentioned something similar here #785 (comment)
but my approach was to have a fee (different than gas) or a deposit somehow but a proposal to delete them might not be bad if there is no single contract instance depending on that code id.

[ethanfrey]

There is the additional case where the chain permissions are changed to a more restrictive state after the upload. Like before "everybody" becomes "Nobody". How should this be handled?
A) Keep the instantiate permission as defined on creation
B) prevent instantiation

I would vote with A. You could have already instantiated it 100s of times before. If a permission less chain becomes permissioned, we don't want to freeze all the existing codes automatically. But you could have a proposal to freeze them explicitly.

[ethanfrey]

I was thinking if we could end up with lot's of garbage wasm on chain easily that are never instantiated when following this proposal. Inactive gov proposals are deleted at some point.

Yeah, there are lots of ways to get garbage data on chain. Lots of ibc client updates do this pretty well also.