Yes I agree that this supersedes your RFC. We should not deploy pallet_evm as it does not improve enough on the status quo. We have this potentially much better solution on our hand that barely drops any compatibility when compared to frontier while offering orders of magnitude speedup for computation heavy benchmarks.
The RFC should look something like this:
- pallet_contracts
- Ethereum RPCs
- EVM (YUL) → PolkaVM recompiler
I am up for writing this RFC.
We are in the middle of checking for the technical feasability. Improving the recompiler, PolkaVM and benchmarking all of that. For example, we are still lacking 64bit support in PolkaVM which is crucial for efficient code when recompiling from a 256bit machine like EVM. We are expecting a certain improvement but can’t benchmark it, yet. But I think we are sufficiently confident that we can defeat EVM in each use case. Large contracts that barely execute any code (think getters) were a problem. But now with the lazy interpreter of PolkaVM we are even winning there in most cases. 64bit support will be the final nail in the coffin. In computation we are already seeing 100x speedups vs. native EVM execution with 32bit PolkaVM. But we also must not regress in those other cases.
But when writing the RFC it is important that we have all the data to make a good case.