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

Revisit reply gas costs for submessages. #450

Closed
alpe opened this issue Mar 10, 2021 · 1 comment · Fixed by #630
Closed

Revisit reply gas costs for submessages. #450

alpe opened this issue Mar 10, 2021 · 1 comment · Fixed by #630

Comments

@alpe
Copy link
Contributor

alpe commented Mar 10, 2021

Follow up from #441 (comment)

@alpe alpe added this to the v1.0.0 milestone Mar 10, 2021
@ethanfrey
Copy link
Member

Thanks for marking this.

In previous discussions, we decided to charge the reply call just like execute. Which was a simple and safe solution.

On reflection, I think any reasonable validator should have a decent sized cache (100-1000 contracts), such that we can expect this contract to still be in cache when get reply.

To avoid it, one would need several hundred different code blobs, and organise some chain that called through all of them, such that the first one was out of the cache before it got a reply.

The cost of the instantiation of these (very likely unpinned) contracts would be 40_000 * 100-1000 = 4-40 million gas, and that will allow the user to force some amount of work without charging gas. At worst case (even assuming 0 size cache and very simple contract), you can maybe get 60% of the gas charged for the work (1 instantiation + 2x work vs 2x instantiation + 2x work). And usually need to pay several million gas before you can even start to get to that zone.

That said, I would treat all contracts as pinned in the reply section for gas calculation purposes.

This also encourages usage of submessages when needed as they are not arbitrarily expensive.

Thoughts?

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

Successfully merging a pull request may close this issue.

2 participants