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

Freeze Code ID Proposal #780

Closed
jhernandezb opened this issue Mar 9, 2022 · 6 comments · Fixed by #796
Closed

Freeze Code ID Proposal #780

jhernandezb opened this issue Mar 9, 2022 · 6 comments · Fixed by #796
Labels
optional Not absolutely required for the milestone
Milestone

Comments

@jhernandezb
Copy link
Contributor

With permissioned CosmWasm chains, it would be nice to freeze code ids from being instantiated.

Example: There is a security bug in a code id and a new one is deployed but you want to prevent the old one from being instantiated but at the same time keep previously instantiated contracts to keep running.

@ethanfrey
Copy link
Member

We have a field that controls who can instantiate a given CodeID, called InstantiateConfig. Typically it is "Everybody", but could be set to "Nobody" as is sometimes done in permissioned environments, to only allow the governance mechanism to instantiate that codeID.

If we allowed modifying that field by a gov proposal, that should satisfy your request, right? It would also allow making a restricted codeID free to instantiate by anyone, which is more a permissioned use-case, but nice that one concept can cover a range of uses.

@jhernandezb
Copy link
Contributor Author

Yes! modifying that value through a gov proposal will totally work

@ethanfrey ethanfrey added this to the v0.25.0 milestone Mar 9, 2022
@alpe
Copy link
Contributor

alpe commented Mar 10, 2022

Thanks for bringing this up. I really like the idea of freezing a code id and releasing it. 💯
As Ethan pointed out, this would work with existing authz schema.

I don't have the steps to implement this well documented but as a start these are the high level steps, in case somebody want to give it a try already:

  • Add new type to proposal.proto
  • Run make proto-all to generate types from proto

Implementation on the server side:

Client side:

Manual testing

  • Build a wasmd binary via make install
  • Start local instance (see contrib/local)
  • Setup system under test and submit proposal

@jhernandezb
Copy link
Contributor Author

I can probably work on this, how this proposal should be called? It's actually updating instantiation permissions so UpdateInstantiatePermissions ?

@alpe
Copy link
Contributor

alpe commented Mar 11, 2022

💪 great!
The proposal would update the InstantiateConfig on CodeInfo. Technically it is not just the "permission" but can also be an address that was accept-listed.
I don't have a strong opinion on the naming. UpdateInstantiateConfig or SetInstantiateConfig came to my mind.

@jhernandezb
Copy link
Contributor Author

UpdateInstantiateConfig sounds good to me will start working on it this week.

@ethanfrey ethanfrey added the optional Not absolutely required for the milestone label Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optional Not absolutely required for the milestone
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants