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

Limit init/migrate/execute payload message size #203

Closed
4 tasks
alpe opened this issue Jul 17, 2020 · 6 comments · Fixed by #539
Closed
4 tasks

Limit init/migrate/execute payload message size #203

alpe opened this issue Jul 17, 2020 · 6 comments · Fixed by #539
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@alpe
Copy link
Contributor

alpe commented Jul 17, 2020

Summary

There are currently no limits to the msg payload in MsgInstantiateContract, MsgMigrateContract and MsgExecuteContract. Should we set limit for external/ dispatched messages?


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ethanfrey
Copy link
Member

You have to pay gas for them, and they cost lots of wasm gas to process.

It might make sense to produce a reasonable limit on them, but what is reasonable? If I want to start an erc20 like contract with eg. 5000 addresses from some import, that will be easily 200kb.

I would rely on the tx gas limit and byte size to enforce this

@ethanfrey
Copy link
Member

Unless you have an objection, I would close this and just rely on other controls (like "max tx bytes" and "gas cost per tx byte") to limit this

@alpe
Copy link
Contributor Author

alpe commented Jul 24, 2020

Thanks for the updates. A scenario I had in mind was a contract that returns a very big message. Tx limits would not apply here as we dispatch them internally. I hope this is covered. 🤞

@ethanfrey ethanfrey added this to the v1.1.0 milestone Aug 19, 2020
@ethanfrey
Copy link
Member

You are right, this could be quite large. But as soon as we write this to the migration history, it will charge a bunch of gas based on size. I don't see a need for explicit limits, but if you want to make some (very large) ones, like 64kB, that is fine

@ethanfrey ethanfrey modified the milestones: v1.1.0, v1.0.0 Aug 19, 2020
@alpe
Copy link
Contributor Author

alpe commented Nov 20, 2020

Instead of a hard byte size lime we can charge for the bytes as proposed in option 2 in #297

@ethanfrey
Copy link
Member

Let's do that.

@alpe alpe assigned alpe and unassigned alpe Dec 14, 2020
@alpe alpe added the enhancement New feature or request label Dec 14, 2020
@alpe alpe modified the milestones: v1.0.0, v0.18.0 Jun 11, 2021
@alpe alpe self-assigned this Jun 14, 2021
@alpe alpe closed this as completed in #539 Jun 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants