CosmWasm / wasmd

Basic cosmos-sdk app with web assembly smart contracts
Other
366 stars 398 forks source link

Add AccesType OnlyCodeIDs #1042

Open jhernandezb opened 1 year ago

jhernandezb commented 1 year ago

It's very common for factory patterns where there is A -> B-> C, where C should only be instantiated by B type contracts but due to the dynamic nature it's hard to enforce without hardcoding the value inside the C contract.

alpe commented 1 year ago

Thanks for this feature request! I can see your problem. Although It would not be very hard to implement in the DefaultAuthorizationPolicy, it adds complexity and does not solve that code-ids can change between different systems (test/mainnet for example). You would really benefit from using predictable contract addresses instead, which solve this, too. Unfortunately they are not available yet, unless you use Stargate messages. WDYT? See https://github.com/CosmWasm/cosmwasm/issues/1436 for native support

jhernandezb commented 1 year ago

I don't think I really follow your comment, don't think different code ids on different systems is an issue since this will be specified when you upload the contract. wasmd tx wasm store contract.wasm --instantiate-only-code-ids 1,2,3

How this will work with predictable addresses ?

GNaD13 commented 1 year ago

I have read the issue. The problem is this may change a little with current design about checking permission feature. We can add more logic to retrieve the CodeID using contract address (which is the sender address) and use that data to check the permission when instantiate. But the main problem is what happend if gov instantiate this kind of contract?

alpe commented 1 year ago

But the main problem is what happend if gov instantiate this kind of contract?

It is allowed. Gov bypasses the permission system

alpe commented 1 year ago

The bigger issue with this task is that we share the same AccessConfig type for Params.code_upload_access and CodeInfo.instantiate_config. While there was a an overlap before it does not make much sense to have an only_code_ids for the params. We should split the different configs into separate types which can add quite some work and requires a migration.

With predictable addresses you can have an alternative way that can be used to setup a A -> B-> C . Wasmvm integration is coming. See https://github.com/CosmWasm/cosmwasm/issues/1500

Setup would be:

# prepare addresses
contractA=$(wasmd q wasm build-address [code-hash-contract-1] [creator-address] [salt-A-hex-encoded]))
contractB=$(wasmd q wasm build-address [code-hash-contract-2] [contractB-address] [salt-B-hex-encoded]))
contractC=$(wasmd q wasm build-address [code-hash-contract-3] [contractC-address] [salt-C-hex-encoded]))

# upload contracts with instantiation permission set
wasmd tx wasm store contract-1 --from creator-address --instantiate-anyof-addresses=${contractA}
wasmd tx wasm store contract-2 --from creator-address --instantiate-anyof-addresses=${contractB}
wasmd tx wasm store contract-3 --from creator-address --instantiate-anyof-addresses=${contractC}

# create instance 1 with predicted address
wasmd tx wasm instantiate2 "$CODE_ID1" "$INIT" [salt-A-hex-encoded] --from creator-address

This workflow would be environment independent.

See a simple example https://github.com/CosmWasm/wasmd/blob/main/contrib/local/02-contracts.sh#L35