analyse SputnikVM in detail as the basis of the EVM foreign runtime

[raulk]

To finalize our architectural design, we need to fully grasp how flexible SputnikVM in its current form in order to inject our own memory model, storage hooks, address translation, syscalls, etc.

From perusing NEAR Aurora's engine code, there seem to be some pretty well-defined hooks to customise the glue layer between the EVM sandbox and the outer layer (FVM).

There are two traits: Backend and ApplyBackend. The former loads values from the environment, and I suspect the later is called once processing is done to hand off changes that resulted from the call.

https://github.com/aurora-is-near/aurora-engine/blob/008e34cdf87ed1dfe87ba174af6a2bdc38dcfb5d/engine/src/engine.rs#L890-L1076

We need to do a deep dive into this to fully scope what the integration will entail, as well as to identify any uncertainties, risks, and blockers ahead of time.

Links

https://github.com/rust-blockchain/evm
https://github.com/aurora-is-near/sputnikvm

[raulk]

Part of this task is to produce a detailed design doc for the FVM <> EVM mapping.

[raulk]

Doc is here: filecoin-project/fvm-specs#39. SputnikVM is feasible, but we need a better understanding on https://github.com/bluealloy/revm, as it's a newer implementation that claims higher performance and less problems.