Subspaces CosmWASM contracts

[RiccardoM]

Following the merge of #728 which introduces the concept of subspace as described inside ADR-006, developer will now have the ability to create application-specific subspaces inside Desmos.

To make sure that DApps developers can leverage the full power of Desmos, we need to make sure that they are able to run CosmWASM contracts inside their own subspace. This will allow them to build custom DApps tokenomics as well as custom features that might not be available directly inside Desmos.

That being said, one question is raised: who should be able to deploy a CosmWASM smart contract inside Desmos?.

Current status of CosmWASM deployment on different chains

This same question has been raised inside other Cosmos chains, and two completely opposite solutions have emerged:

1. allow all users to deploy them (similar to what Juno is doing), or
2. allow the on-chain governance to vote every smart contract to decide whether it should be deployed or not.

Obviously, both of the two methods have each one their pro and cons.

Permissionless deployment
Pros

• Users are free to deploy smart contracts without waiting
• No censorship is possible

Cons

• A lot of smart contracts might slow down the chain significantly
• It's not possible to deploy sudo smart contracts that execute without the need of an external call

Permissioned deployment
Pros

• It's harder that the chain will slow down, due to the fact that it's less likely a lot of contracts will be deployed
• Smart contracts will be ideally be "audited" by the community before approval

Cons

• Slower development time due to the need of waiting for the governance to accept them
• It's possible that cartels will be born, effectively censoring one developer to benefit another one (e.g. in case of competitors that do the same things)

Considerations about Desmos

Although the two solutions might work on different scenarios, I think neither of the two would work properly inside Desmos due to the fact that:

• we need sudo contracts to exist for tokenomics to work properly
• we need a way to avoid having too many smart contracts deployed on chain, especially the ones that are not specific to Desmos
• we need developers to be independent if we want our ecosystem to thrive

That being said, I think what we could implement is a hybrid system in which we allow for permissionless deployment only to users that satisfy some requirements.

Semi-permissioned deployment

Since each smart contract will be tied to a subspace, what we can do is require developers to lock some tokens before being able to deploy a smart contract. The amount of token can then be based on a on-chain parameter that the community can change with a governance proposal.

The flow would then be:

1. the developer locks the amount of token required to deploy a smart contract
2. the developer deploys the smart contract on the Desmos chain

This economic requirements acts as a way to prevent users from deploying smart contracts that are either malicious to the chain or are not related to Desmos at all (in this case they can choose another chain).

Note that the required amount does not need to be put only by the developer. It could be locked also using the subspace treasury or by a group of user that want to see that smart contract being deployed.

The only thing necessary for this to work is to make sure, each time a smart contracts needs to execute, that there is enough money locked. If such amount is below the minimum threshold at any given time, the smart contract should become unexecutable until more tokens have been locked.

---

Please @kwunyeung @bragaz @dadamu @manu0466 let me know what do you think about this approach, if you see any flaws in that and, most importantly, if it's technically doable.

[leobragaz]

Speaking from a technical feasibility perspective: It is. But not in a straight forward way. Let me explain a little bit.
Currently, vanilla wasmd (which implements x/wasm) allows you to setup 3 different type of permission related to contracts upload/interaction using x/wasm module's params.

They are respectively:

• AccessTypeEveybody (the standard one, which allows everyone to upload/interact with contracts);
• AccessTypeNobody (this one is the one used when you choose to deploy contracts through governance);
• AccessTypeOnlyAddress (this one allows only one address to store/interact with contracts).

Unfortunately, this is not enough to achieve our purposes. With one of these setup, even if we create a x/subspaces logic to interact with sudo contracts, users will be always able to:

• Store/upload other non-sudo contracts directly from the module;
• Create a subspaces and upload a sudo-contracts which can be either malicious or not related to Desmos.

What I think we can do is fork wasmd and edit it's logic so it uses subspaces to check on contracts store/interactions.
I don't see any other ways at the moment, and I'm conscious about the extra-work we will need to do in order to maintain the fork.
What do you guys think about this?

[kwunyeung]

This is something always in my mind as I always think how smart contracts being deployed on Ethereum is not safe enough. The way of deploying a smart contract with only spending transaction fees will generate too many unsecured contracts which lead to lost of fund.

My ideal scenario is similar to what @RiccardoM mentioned that smart contract deployment should be done with stake (locked tokens). This amount cannot be withdrawn from the chain as the deployment has been done. And the staked amount should be slashable when disaster happens. We may consider setting multiple levels of staking as issuing CW20 tokens without reserving funds will just lead to many shit coins floating around.

However, I understand this is not easy to achieve. Also defining the scenarios of slashing maybe too complicated and the result could be trivial. We can see that most token hodlers don’t care about slashing/security but focus on quick money. As @bragaz mentioned, of course we can fork wasmd and make changes but maintaining a forked wasmd might increase unforeseeable work-load.

The simplest solution is to incur a very high transaction fee for deploying smart contracts. This is similar to the current NFT contracts on Ethereum. Each project may have to spend more than 3ETH to deploy a smart contract with minting and royalty features. Osmosis is similar. Anyone can create a pool but it costs 100OSMO.

In the case of Desmos, the fees can either

1. Just be burnt
2. Distribute as normal tx fee rewards as all delegators will be beneficial. This is similar to how Terra works for the use of UST.
3. Transfer the tx fee to community pool for future development

The smart contract deployment fee should be a parameter so that it can be updated by governance.

[RiccardoM]

Considering the above answer by Leo that would require us to fork wasmd, and considering that your implementation idea is as effective as what I thought, I think we can stick with having a custom min_fee set for messages that are related to the deployment and management of CosmWASM contracts.

We can reboot the fees module we had developed and set a min fee for such messages using that module.

Out of all the tree options on what to do with the fees, I think the best one is to simply handle them as normal fees. The user will then just have to specify a fee amount greater or equals to the min required to make sure the transaction is valid. Distributing the fees normally would benefit everyone: the community pool (its cut is currently set to 20%), the validators that are later going to validate the CosmWASM transactions, and the delegators that contribute in keeping the network secured thanks to their delegations.

[leobragaz]

Other than fees, we can also tweak a range of different gas parameters for contracts execution.
You can take a look at them here:
https://github.com/CosmWasm/wasmd/blob/v0.23.0/x/wasm/keeper/gas_register.go

Here's the gas strategy adopted by wasm:
https://github.com/CosmWasm/cosmwasm/blob/v1.0.0-beta/docs/GAS.md

I'm currently testing some of those gas parameters here:

desmos/app/wasm_config.go

Line 20 in 60b842a

func DesmosWasmGasRegister() wasmkeeper.WasmGasRegisterConfig {