Follow up tracking issue on deep context stack efficiency

[yihuang]

The change here doesn't provide context on the following questions:

• How does flattening improve efficiency? Do you have benchmark results?
• Is it just to commit changes and avoid the infinite loop?
• What's the threshold (i.e max number) of internal calls that the EVM supports without crashing?
• Can we add a test to check the max number of internal calls supported?
• Do we still need to call the CommitCachedContexts() if the changes are being committed regardless if it fails or not? Can this logic commit an invalid result or affect the revert logic as well?

Since the underlying issue is from the SDK, you should open an issue there to get it fixed in the long term

Originally posted by @fedekunze in #617 (comment)

[yihuang]

The change here doesn't provide context on the following questions:

• How does flattening improve efficiency? Do you have benchmark results?

benchmark was done in the PR

• Is it just to commit changes and avoid the infinite loop?

not an infinite loop, just a steep computational complexity curve.

• What's the threshold (i.e max number) of internal calls that the EVM supports without crashing?

it's demonstrated in the benchmark, 13 layers will take seconds to simply create an iterator.

• Can we add a test to check the max number of internal calls supported?

the benchmark should have show this.

• Do we still need to call the CommitCachedContexts() if the changes are being committed regardless if it fails or not? Can this logic commit an invalid result or affect the revert logic as well?

CommitToRevision doesn't commit all the cache contexts, only the ones after the target revision. And after the EVM contract is executed, we don't need those intermediate contexts anymore.

Since the underlying issue is from the SDK, you should open an issue there to get it fixed in the long term

cosmos/cosmos-sdk#10310

Originally posted by @fedekunze in #617 (comment)