[Research] CosmWasm path to production (mainnet)

[iboss-ptk]

This issue is for tracking the clarification of the path to production (mainnet) for CosmWasm. Since Osmosis implements permissioned CosmWasm, See what are the steps to take, who is involved in order to have clear understanding on what Beaker should support, who else needs to be involved, what system needs to eventually be upgraded and later we can have a clear documentation for the dapps developer.

The following is my attempt to flesh out the understandings along with ❓ questions and 💡 ideas.

Grouping for wasm gov proposal types

According to the wasm gov docs, there are additional proposal types for wasm gov. Grouping by their functions for further reference:

• Deployment and Migration (**main focus for this issue)

  • StoreCodeProposal
  • InstantiateContractProposal
  • MigrateContractProposal

• Code Permission

  • UpdateAdminProposal
  • ClearAdminProposal
  • UpdateInstantiateConfigProposal

• Code Pinning

  • PinCodes
  • UnpinCodes

• Execution

  • SudoContractProposal
  • ExecuteContractProposal

[❓ 1] on mainnet, which of the above are required to be execute through governance?
📝 Answer 1 by @czarcas7ic

[💡 1] Same wasm gov configuration as mainnet for testnet (stagenet?) and/or localosmosis variation would be ideal for testing. @czarcas7ic @nicolaslara

For Code Pinning and Execution, if the [❓ 1] is clear, it doesn't seem to be important for this issue. Let's move on to the main topic.

Deployment and migration

StoreCode requirements

There was a discussion with @ValarDragon @daniel-farina about hash verification and contract-list

• [Research] List steps to verify contract hash  #56

This is what I imagine would happen if there is a need to store code:

graph TD
    StoreCode[Submit `StoreCodeProposal`]
    SubmitRepo[Submit source and metadata]
    Val{validate}
    Voting[Gov Voting]

    StoreCode == wasm byte code ==> Val
    SubmitRepo == source code & build metadata ==> Val
    Val -->|passed| Voting

Loading

[❓ 2] should we require hash validation before triggering the voting period of the proposal? if so it sounds like a chain upgrade, what else could be an alternative? @ValarDragon

📝 Answer 2 by @daniel-farina

The StoreCodeProposal already contains wasm byte code, one can get that by querying the proposal.
For Submit source and metadata this would trigger a question:

[❓ 3] In what format should we store the source reference & build metadata (for deterministic build)?
📝 Answer 3 by @daniel-farina

[💡 3] Specific & special region in the proposal description for source reference & build metadata

[❓ 4] Do we require public git repository? or just upload an archive somewhere?
📝 Answer 4 by @daniel-farina

[❓ 5] Where does contract list update sits in the process?
📝 Answer 5 by @daniel-farina

Deployment

This is normally a 2 steps process of StoreCode -> InitiateContract, but common pattern of a dapp has the following:

1. StoreCode -> InitiateContract tends to happen sequentially.
2. A dapp can have more than 1 code/contract and could be depending on each other

The following graph is a general execution plan for a deploying a dapp.

[💡 6] Note that this structure is dependency graph so the process as code @daniel-farina mentioned in #48 could incorporate the whole flow like what terraform does.

[❓ 7] Is it possible / how hard it is to have multiple related proposals (like in the process above) to go through the gov together as bundled proposal? Does it make sense to do so? I can imagine how this could simplify the flow... @ValarDragon @sunnya97

Migration

The following graph is a general execution plan for a migrating multiple contract for a dapp. It shares the same question as for the deployment.

Lastly:

[❓ 8] Will we use https://commonwealth.im/osmosis/ for wasm governance?
📝 Answer 8 by @daniel-farina

Let me know your thoughts.

[czarcas7ic]

[❓ 1] on mainnet, which of the above are required to be execute through governance?

I could be wrong, but I believe the only thing required would be StoreCodeProposal

[daniel-farina]

[❓ 2] should we require hash validation before triggering the voting period of the proposal? if so it sounds like a chain upgrade, what else could be an alternative? @ValarDragon
I think this is a nice idea but could be added as an issue to discuss later, for now we can instruct teams on the steps they should follow and make sure they meet the criteria.

The next two questions could be part of the issue above

[❓ 3] In what format should we store the source reference & build metadata (for deterministic build)?
[💡 3] Specific & special region in the proposal description for source reference & build metadata

[❓ 4] Do we require public git repository? or just upload an archive somewhere?
[❓ 5] Where does contract list update sits in the process?

Basically, it's our job before we integrate Osmosis with a contract, to verify the hash matches what their Official repo says. Eventually to have on chain verification would be a beautiful thing but a lot more complex.

[daniel-farina]

[❓ 8] Will we use https://commonwealth.im/osmosis/ for wasm governance?
I think so, it should be the same.

[ValarDragon]

[ ? 2 ]
Code verification will not be an on-chain requirement for the code to go on-chain. It should for now be enforced in voting. In the future, we can imagine some commitee gets veto rights if they discover the hash is invalid.

Unfortunately, it seems unlikely that the state machine can safely contain the Rust -> Wasm compiler under reasonable tradeoffs.

[ ? 3]

I think for 3, this can even be a URL, and we can spend time iterating on steps to improve this. I don't really view the exact steps as a blocker for first contract deploy, but I moreso view it as a thing we need to figure out / experiment with. (I currently don't know steps to get reproducible wasm hash)

[ ? 4]
Yes public github repository should be required within voting.

[ ? 5] For now I think there should be a PR link with some fields left blank to the contract list entry. I don't think this is a blocker for intiial contracts, but should be a standard we better form with a couple iterations.

[ ? 7] great question! I have no idea whats supported in wasmd today, we can look at the code / ask confio if they want to add it natively. Otherwise we can fork to add multi-uploads and in the interrim people do multiple proposals.

[ ? 8] Yup[

[iboss-ptk]

Thanks for all the answers ! will use these info the come up with the mainnet flow with Beaker.

With that being said, one big question is still unanswered:

[❓ 1] on mainnet, which of the above are required to be execute through governance?

@czarcas7ic mentioned that

I could be wrong, but I believe the only thing required would be StoreCodeProposal

Wondering how could we know for sure? It there any other way to test it, or only need to do actual mainnet deployment to confirm?

[czarcas7ic]

It's in the pipeline for us to automate a testnet that mirrors all the params of mainnet. If this is needed soon I can spin one up manually

[iboss-ptk]

@czarcas7ic that would be great if that's possible, alternatively, if you can point me to some resource to make mirroring params happens in localosmosis, that also works. Please let me know :)

[czarcas7ic]

@iboss-ptk I just realized today that despite wasm being permissionless on the testnet, you should still be able to submit a wasm prop just like before (I approved one this morning, see prop 181 on the testnet)

[iboss-ptk]

@czarcas7ic yes, I'm aware of that, just that we can't verify this question

[❓ 1] on mainnet, which of the above are required to be execute through governance?

[czarcas7ic]

@czarcas7ic yes, I'm aware of that, just that we can't verify this question

[❓ 1] on mainnet, which of the above are required to be execute through governance?

Ah, well some of the other individuals that deployed contracts when testnet params matched mainnet (ion dao for example) were able to deploy with just the single gov prop. Unsure if that answers your question

[iboss-ptk]

Oh cool, I think I've found it @czarcas7ic thank you!!

https://github.com/osmosis-labs/osmosis/blob/f0270d04bd77cc5e1c23f7913118b3c2ba737e97/app/genesis.go#L25

[iboss-ptk]

I think the information needed is enough to proceed now, closing the issue.