StoreAndInstantiate gov proposal

[jhernandezb]

Would be nice to have a single proposal that does both, specially if the store code is uploaded with instantiate permissions Nobody having to wait an entire voting period for store + instantiate might be just too long depending on each chain.

[alpe]

👍 Good thinking.

[ethanfrey]

I question this.

There is a desire to move away from the whole Store Proposal as it is too heavy to vote on. I would look for another way to do that before we consider adding more Proposals that include the entire wasm blob.

Also, I wonder which project will require votes on both store and instantiate?

This is related to #780 and I would consider a small re-architecture. If we do not allow StoreCode message to override the permissions, we could check a lot of boxes for permissioned chains. If we set the default InstanitatePermission to Nobody (which cannot be overridden):

1. StoreCodeMsg, then vote to make one Instantitate.
2. StoreCodeMsg, then vote to open up the permissions to instantiate (Freeze Code ID Proposal #780), then anyone can instantiate without a vote

We could also allow the StoreCodeProposal to set a non-Nobody instantiate permissions if people still want to do this vote, but I think the above two will make this whole flow much easier (and avoid gas intensive votes - see #761 )

[ethanfrey]

If you agree on this, I would say #780 plus a new issue to prevent StoreCodeMsg from overriding the InstantiatePermissions (quite simple) would cover this, and #761 as well.

[jhernandezb]

That kinda makes sense, I like that it will fix storing the blob inside the proposal, I'd be worried mostly about having a lot of contracts being uploaded and not used, but perhaps that could be solved by setting a fee that can be in a way a bit high (let chains to configure their own fee) for example creating a pool in osmosis costs 100 OSMO iirc, creating an nft collection in stargaze costs 1000 STARS.

[jhernandezb]

Let me know your thoughts about a configurable upload fee, I might be able get started on #780 which is needed for either option

[ethanfrey]

Let me know your thoughts about a configurable upload fee, I might be able get started on #780 which is needed for either option

We have a high store code gas price. I think this is configurable in code when compiling the chain - if not please raise an issue. We don't support these all as params yet, there is an open issue to discuss that.

I think the fee should be passed on gas price. And chains should have a min-gas-price for that. Adding a separate fee handling mechanism for each module is a bit confusing and I would avoid this for now.

[jhernandezb]

Well that doesn't quite work for chains like Osmosis and even with that its minimal but I understand your point.

[ethanfrey]

Then this is a bigger problem for those chains.

You suggest a fee for anti-spam resistance.
The gas fee was introduced for anti-spam resistance.
Let's use it.

If people have such low gas fees it doesn't serve at all to stop spam, then why do they want to only stop this one spam possibility and not the others?

We charge plenty of gas to cover compilation and storage of the upload. You could run a few dozen ibc client updates to achieve a similar result.

[jhernandezb]

My point wasn't about anti-spam but preventing contracts from being upload that would never be used because of the nature of a permissioned cosmwasm chain. For example random people uploading contracts but not submitting a gov proposal.

With the current flow if a proposal doesn't pass no contract is stored and it has a deposit fee. Moving away from this flow eliminates the fee (deposit) and the ability prevent uploads in the first place.

Having said that I agree having a fee on top of the gas is weird and also think it should not be added at least directly into this module.

[alpe]

Just adding some context on customizing wasmd gas values:
We have an extension point prepared that can be used to provide a custom Gas register to match your requirements.

Just from personal experience, not using some project "defaults" may cause communication and support overhead elsewhere ...

[ethanfrey]

I would start with #796 and #840 as a useable workflow, aiming for them both in 0.27. And then revisit if this is still necessary for the following v0.28 release

[pinosu]

Is this still relevant? Since #796 and #840 are now merged, what is the work left for this issue?

[alpe]

There were requests for a single proposal that does upload + instantiate for restricted chains where #840 is not setup.

[ethanfrey]

Note that as of cosmos-sdk 0.47, proposals will be much cheaper to vote on... not sure if this impacts the desire for this feature. Maybe @jhernandezb can comment here?

[jhernandezb]

Note that as of cosmos-sdk 0.47, proposals will be much cheaper to vote on... not sure if this impacts the desire for this feature. Maybe @jhernandezb can comment here?

Somehow I missed this, seems like it's closed now thanks! I think is still relevant when you want to save some governance burden eg. waiting 2 complete cycles of governance upload + instantiate.