fix: hardcode max vm cycles in keeper

[deelawn]

This hardcodes the maximum VM cycles in the keeper to ten million, the same that is currently being used from genesis. It doesn't seem like there is a reason why we should want people to be able to adjust this.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

Attention: Patch coverage is 28.57143% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 47.50%. Comparing base (0f2e755) to head (e03cf44).
Report is 18 commits behind head on master.

Files	Patch %	Lines
gno.land/pkg/gnoland/node_inmemory.go	0.00%	3 Missing ⚠️
gno.land/pkg/gnoland/app.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1807      +/-   ##
==========================================
+ Coverage   47.49%   47.50%   +0.01%     
==========================================
  Files         388      388              
  Lines       61311    61345      +34     
==========================================
+ Hits        29117    29144      +27     
- Misses      29756    29761       +5     
- Partials     2438     2440       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[thehowl]

I'm not entirely sure about these changes.

If you execute these on Gno.land, these will fail, I'm pretty sure, as you'd get "cpu cycle overrun" already. So these fail in gno run and gno test, which from this PR would be excluded with the new limit.

The way I see it, we should have a limit on the amount of frames that can be created (ie. a stack overflow error), which is for both local testing and the blockchain context, but nothing more than the existing CPU overrun checks for infinte for loops. wdyt?

[thehowl]

Initial comment

From the review meeting:

• Let's make sure that gno run and gno test are not limited in VM cycles execution
• And have a default value for max VM cycles

TBD w/ @deelawn @piux2

[petar-dambovaliev]

In my opinion, the bottom of infinite recursion/loop should be when there is no more gas. That means that the check needs to be added in the VM.

[zivkovicmilos]

Looks good 💯

Please see @thehowl's suggestions, otherwise good to go

[piux2]

also we need to remove the code that configs VM parameters from command flag.

[deelawn]

In my opinion, the bottom of infinite recursion/loop should be when there is no more gas. That means that the check needs to be added in the VM.

This will be the fallback value if, for some reason, something prevents the machine from halting execution when the gas runs out.

[moul]

Hey,

I support this change. But in the long time, I believe we should make it configurable by the blockchain instead of hardcoding it. See #1856.

Also, linked with #828.

[zivkovicmilos]

Hey,

I support this change. But in the long time, I believe we should make it configurable by the blockchain instead of hardcoding it. See #1856.

Also, linked with #828.

💯 % agreed. I'll see to tackle this soon

[piux2]

LGTM