Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AccesType OnlyCodeIDs #1042

Open
jhernandezb opened this issue Oct 7, 2022 · 5 comments
Open

Add AccesType OnlyCodeIDs #1042

jhernandezb opened this issue Oct 7, 2022 · 5 comments
Labels
help wanted Extra attention is needed

Comments

@jhernandezb
Copy link
Contributor

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
Copy link
Contributor

alpe commented Oct 10, 2022

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 CosmWasm/cosmwasm#1436 for native support

@jhernandezb
Copy link
Contributor Author

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 ?

@ethanfrey ethanfrey added this to the v0.31.0 milestone Nov 4, 2022
@alpe alpe added the help wanted Extra attention is needed label Nov 15, 2022
@GNaD13
Copy link
Contributor

GNaD13 commented Dec 1, 2022

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?

@pinosu pinosu self-assigned this Dec 7, 2022
@alpe
Copy link
Contributor

alpe commented Dec 8, 2022

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

It is allowed. Gov bypasses the permission system

@alpe
Copy link
Contributor

alpe commented Dec 8, 2022

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 CosmWasm/cosmwasm#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

@alpe alpe modified the milestones: v0.31.0, v0.32.0 Dec 8, 2022
@pinosu pinosu removed their assignment May 7, 2023
@alpe alpe modified the milestones: v0.41.0, v0.42.0 Jun 12, 2023
@alpe alpe modified the milestones: v0.42.0, v1.0.0 Jul 12, 2023
@pinosu pinosu removed this from the v1.0.0 milestone Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants