Implement a fine-tuned EVM instead of relying on an external one

[hai-rise]

Context: #316 (comment), #319, #373.

TL;DR, we want an implementation specifically designed for parallel execution with thread-safe types, states, more native caches and instrumentation, no overheads for lazy, etc. Using an external sequential-first implementation like revm adds too much overhead and unwanted type conversions.

EVM isn't that complicated anyway: https://github.com/lambdaclass/lambda_ethereum_rust/tree/main/crates/vm/levm.

[byhashdong]

@hai-rise I'm also very interested in this topic.
Do you have any plan and task splits or architecture design now, or just fork from levm?

[hai-rise]

@byhashdong This is an ambitious project!

A fork is likely a bad choice as we want low-level control over EVM execution right within pevm::Vm, for instance, to use the multi-version memory directly instead of going through another (frictional) layer of JournaledState's EvmState in revm. We may want to reuse/reference utility functions (like era-based gas calculation) but our parallel-first VM must be very different architecturally.

The current plan is to take baby steps like in #383. We will need many iterations before we can completely remove revm usage. I'll create smaller tasks along the way that you can pick if you are interested 🙏.

[byhashdong]

I'm thrilled to hear this ambitious project, so eager to see your task list.
And if any design doc could be provided, that will be more helpful for code implementation.

[hai-rise]

@byhashdong We'll get there, sir 🫡.