XVM gas handling prototype

[Dinonard]

Pull Request Summary

The purpose of this PR is to provide a prototype implementation for gas handling in XVM.

Description

When executing a contract within the context of XVM, different VMs and gas handling schemas will be present.
E.g. the most basic example is EVM and Partity's WASM - gas vs. native weight. Each unit of these measures represents
a different concept, although similar. However, both are encapsulated by substrate's native way of handling weight (or gas).

So it's natural to keep the handling of gas in XVM context tied to the native weight system.

Current Solution

We rely on native weight handling for XVM gas handling.

To take an example when EVM contract calls WASM contract:

• EVM contract call is made by a user who sets gas_limit
• during EVM contract execution, some gas is consumed and a XVM call is made towards a WASM contract
• XVM precompile handles the call - it reads the remaining available gas, converts it to native weight and passes it on as max_weight via an XVM call
• XVM pallet detects which VM is being called and delegates call handling to it, also passing the max_weight value to WASM handler
• WASM handler executes the call, limiting it by max_weight, and in the return value returns how much weight was actually spent
• weight of the XVM call is updated (it can only be REDUCED compared to the initial setting)
• EVM precompile handler detects the real weight used for the XVM call, converts it to gas and refunds unused gas if needed

Same goes for WASM --> EVM direction.

Open Issues, Questions & Suggestions

1. We should remove Async VM until we actually need to implement it.
2. Using wrapped Call isn't good enough if we want to have a return value..
3. Weight in the XVM call should be subtracted by XVM execution cost itself. Requires proper benchmarking.
4. We should limit XVM call depth. Probably a good starting value is 1 or 2.
5. XvmContext needs to be revised - imo, contract shouldn't care about limiting gas consumption - it's implicit from the call. I'm not even sure what exactly should be passed via it.

Check list

• Receive feedback from team (1)
• Apply first feedback
• TBD

[0x7CFE]

more grumbles

[0x7CFE]

Unintentionally left edit?

[Dinonard]

Added a comment.

It seems that after latest updates, compilation with cargo check fails.

cargo contract check should work but it also fails for me with another error so I'll have to check that in more detail.

Perhaps this also indicates that we shouldn't keep contracts under root .toml file 🤔

[github-actions]

Package	Line Rate	Branch Rate	Health
frame/custom-signatures/src	81%	0%	✔
precompiles/utils/src/data	72%	0%	➖
contracts/xvm/src	0%	0%	❌
chain-extensions/types/xvm/src	0%	0%	❌
chain-extensions/trait/src	0%	0%	❌
frame/pallet-xvm/src/pallet	39%	0%	❌
frame/block-reward/src	96%	0%	✔
frame/pallet-xcm/src	81%	0%	✔
frame/vesting/src	87%	0%	✔
precompiles/substrate-ecdsa/src	78%	0%	➖
precompiles/utils/src	84%	0%	✔
primitives/xcm/src	88%	0%	✔
chain-extensions/impls/dapps-staking/src	0%	0%	❌
frame/collator-selection/src	89%	0%	✔
precompiles/assets-erc20/src	91%	0%	✔
precompiles/sr25519/src	78%	0%	➖
precompiles/xcm/src	80%	0%	➖
precompiles/utils/macro/tests	100%	0%	✔
chain-extensions/types/dapps-staking/src	0%	0%	❌
frame/dapps-staking/src	93%	0%	✔
frame/pallet-xvm/src	14%	0%	❌
frame/xc-asset-config/src	88%	0%	✔
precompiles/utils/macro/src	0%	0%	❌
chain-extensions/impls/xvm/src	0%	0%	❌
frame/dapps-staking/src/pallet	85%	0%	✔
precompiles/dapps-staking/src	95%	0%	✔
precompiles/xvm/src	73%	0%	➖
Summary	84% (8418 / 9982)	0% (0 / 0)	✔

Minimum allowed line rate is 60%