Evaluate new version of rust-ethereum

[matevz]

As an alternative to Odyssey #2001 evaluate painpoints if we migrated the EVM module https://github.com/oasisprotocol/evm to a new https://github.com/rust-ethereum/evm/ codebase.

[njelich]

The rust-ethereum/evm package just reached v1.0.0. Unfortunately, there are currently no clear migration paths and a lot of breaking changes implemented:

• gas metering has been redesigned, requiring use of eval_gasometer instead of the old model
• opcode handling moved to the new Etable trait with different extension points
• call stack replaced with a hybrid stack/heap implementation
• debugging now supports stepping in addition to tracing, with different APIs
• backend overlays are generalized, meaning prior assumptions about state reverts and substates no longer apply
• configuration is now passed per call frame and uses AsRef/AsMut patterns
• custom interpreter support is handled through Resolver and Invoker abstractions
• overall API surface has shifted and direct v0.x code will not compile without adjustments

Based on this, the migration is likely to be quite a bit of work, since the API interface changes completely. The maintainers generally seem to intend to provide a migration interface to minimize changes in the future, but that is likely to come in the future:

"We don't have a migration path from v0.x to v1.0 yet, but this will change soon. The plan is a evm-compat crate that mimics the API interface of v0.x which should make migrations easier."

[njelich]

@matevz @abukosek

[kostko]

Can someone take a quick look to see how much effort it would take to upgrade? Because the only other alternative is revm which was also hard to migrate to, so this may still be easier?

[njelich]

I consulted with @abukosek and he said that the most important thing is the precompile extendability, as well as nonces. The precompiles seem pretty easy to extend:

https://github.com/rust-ethereum/evm/blob/master/precompile/src/lib.rs7

The other questions is how much of feature parity we want with ethereum? E.g. they are implementing Pectra update, which rebalances some opcodes, but also changes how historical blocks, and blocs are handled.

[abukosek]

It's not enough to just be able to make new precompiles... The precompile system needs to be capable of running subcalls from within precompiles and needs to export used gas so far (before the precompile has ended).

More specifically, someone needs to check if we can do this from within a precompile:
https://github.com/oasisprotocol/oasis-sdk/blob/main/runtime-sdk/modules/evm/src/precompile/subcall.rs#L77

And how to port our changes to do this:
https://github.com/oasisprotocol/oasis-sdk/blob/main/runtime-sdk/modules/evm/src/precompile/gas.rs#L15
From here:
https://github.com/oasisprotocol/evm/commits/oasis/

And how to do the origin_nonce_incremented workaround:
https://github.com/oasisprotocol/oasis-sdk/blob/main/runtime-sdk/modules/evm/src/backend.rs#L352

[peternose]

rust-ethereum/evm#401