Open jhernandezb opened 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
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 ?
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?
But the main problem is what happend if gov instantiate this kind of contract?
It is allowed. Gov bypasses the permission system
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
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.