Remote & Cross-VM Ethereum transaction support

[shaunxw]

Pull Request Summary

pallet-ethereum-checked to handle Remote & Cross-VM Ethereum transaction.

Check list

• added or updated unit tests
• updated Astar official documentation
• added OnRuntimeUpgrade hook for precompile revert code registration
• updated spec version
• updated semver

[ashutoshvarma]

Overall looks good to me except for few comments,

1. Since we are using global nonce for every tx from every origins (xcm & xvm), is there any implications or limitation due to this design? If there is, we can add that to our builder docs.
   Also would it be better to use separate nonce for XCM and XVM?
2. We should not allow for arbitary size inputs via XCM since we can receive very large inputs via XCM which we have no control over.
3. This design allows CREATE operation (deploy evm contract) via XCM context that can inflate proof size since we are allowing unbounded input, and even if we make input bounded, it will be useless for contracts larger than allowed size.
   If possible we should not allow this, IMO cons far outweigh pros
4. How will it impact evm tracing? I'm not sure if tx coming from XCM/XVM will have tracing data associated with them.

Once PR #970 is merged, it would be good to have some e2e tests for this.

[shaunxw]

1. Since we are using global nonce for every tx from every origins (xcm & xvm), is there any implications or limitation due to this design? If there is, we can add that to our builder docs.
   Also would it be better to use separate nonce for XCM and XVM?

I don't see any limitations so far. Using separate nonce for XCM and XVM will make it possible to have tx hash collision.

2. We should not allow for arbitary size inputs via XCM since we can receive very large inputs via XCM which we have no control over.

Yes, I was also planning to set the input bound while working on the XVM / Shibuya integration PoC. Will add it.

3. This design allows CREATE operation (deploy evm contract) via XCM context that can inflate proof size since we are allowing unbounded input, and even if we make input bounded, it will be useless for contracts larger than allowed size.
   If possible we should not allow this, IMO cons far outweigh pros

Good point. Will update.

4. How will it impact evm tracing? I'm not sure if tx coming from XCM/XVM will have tracing data associated with them.

I'm not sure about EVM tracing TBH. If it didn't work, we could research the solution, which I think is not in the scope of this PR.

Once PR #970 is merged, it would be good to have some e2e tests for this.

E2e tests will be added after Shibuya integration.

[Dinonard]

Looks good!

Just some minor comments.

[github-actions]

Package	Line Rate	Branch Rate	Health
chain-extensions/dapps-staking/src	0%	0%	❌
pallets/contracts-migration/src	0%	0%	❌
precompiles/xcm/src	85%	0%	✔
pallets/dapps-staking/src	82%	0%	✔
pallets/pallet-xcm/src	54%	0%	➖
chain-extensions/xvm/src	0%	0%	❌
pallets/collator-selection/src	70%	0%	➖
chain-extensions/types/assets/src	0%	0%	❌
pallets/pallet-xvm/src	5%	0%	❌
precompiles/xvm/src	61%	0%	➖
chain-extensions/pallet-assets/src	0%	0%	❌
pallets/custom-signatures/src	52%	0%	➖
precompiles/substrate-ecdsa/src	78%	0%	➖
precompiles/utils/macro/src	0%	0%	❌
pallets/ethereum-checked/src	69%	0%	➖
precompiles/sr25519/src	79%	0%	➖
primitives/src	72%	0%	➖
pallets/block-reward/src	85%	0%	✔
pallets/dapps-staking/src/pallet	87%	0%	✔
chain-extensions/types/xvm/src	0%	0%	❌
pallets/pallet-xvm/src/pallet	8%	0%	❌
precompiles/assets-erc20/src	76%	0%	➖
chain-extensions/types/dapps-staking/src	0%	0%	❌
precompiles/dapps-staking/src	93%	0%	✔
precompiles/utils/src	69%	0%	➖
primitives/src/xcm	70%	0%	➖
pallets/xc-asset-config/src	54%	0%	➖
Summary	55% (2243 / 4061)	0% (0 / 0)	➖

Minimum allowed line rate is 50%

[Dinonard]

LGTM