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

Optional migrate entry point – allow more gas efficient migrations #1813

Open
webmaster128 opened this issue Feb 27, 2024 · 1 comment · May be fixed by #1846
Open

Optional migrate entry point – allow more gas efficient migrations #1813

webmaster128 opened this issue Feb 27, 2024 · 1 comment · May be fixed by #1846
Assignees

Comments

@webmaster128
Copy link
Member

webmaster128 commented Feb 27, 2024

When CosmWasm migrations were designed, we had 1 instance – 1 dev team in mind. The whole system assumes a small number of instances to handle. Recently we learned that more and more use cases are poping up in which many instances of a contract are created, dozens of pools, hundreds or DAOs, thousands of accounts. Having to send a MsgMigrateContract cand calling the contract for each message is gas intense and hard to manage.

While this ticket does no solve the full problem at once, it is a first step and actionable. The idea is this: not every migration needs a state change. Often times state changes can be done lazily or are not required at all. In those cases we can avoid calling the migrate entry point of the contract. Just swap out the code and call it a day.

This means not executing those lines:

res, gasUsed, err := k.wasmVM.Migrate(newCodeInfo.CodeHash, env, msg, vmStore, cosmwasmAPI, &querier, k.gasMeter(sdkCtx), gas, costJSONDeserialization)
k.consumeRuntimeGas(sdkCtx, gasUsed)
if err != nil {
return nil, errorsmod.Wrap(types.ErrMigrationFailed, err.Error())
}

In such cases the msg field of MsgMigrateContract becomes optional.

If a call to the migrate entry point is needed or not should be decided by the new code. There the contract author can decide if the state needs to change or not. Luckily we have Entrypoints in AnalysisReport and can implement the following logic:

  • if new code contains the migrate entry point, require msg to be non-empty JSON (current logic)
  • otherwise require msg to be empty

This avoids situations in which an expected msg is missing or a provided msg is ignored.

@webmaster128
Copy link
Member Author

In CosmWasm/cosmwasm#2087 we discuss a more powerful solution that makes it easier to migrate from various old version of the contract

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants