EVM Node: Introduce the experimental WASM Runtime

The goal of the EVM Node’s WASM Runtime is to introduce an ad-hoc WASM runtime, that is an alternative take of the Fast Execution runtime implemented for the rollup node. It can be enabled by setting experimental feature next_wasm_runtime to true in the configuration file.

Do take into account the implementation introduced in this commit is
incomplete. In particular, it does support fetching missing preimages from
a known endpoint.

In a nutshell, the Fast Execution runtime of the WASM PVM leverages the C API of Wasmer. This API, as its name suggests, delegates memory-management to the caller: every time a new Wasmer “object” (module, function instances, etc.) is created, the caller is expected to free it. We have strong evidences that there are some memory leaks in the Fast Execution of the PVM, but we have not been able to pin down where and why.

Wasmer being a Rust program, it is a little frustrating to have to face this memory leak issue. But, by moving the abstraction layers a little, it becomes possible to have Rust functions initializing and executing Wasmer. When doing that, we can enjoy Rust automatic memory management. It means having to reimplement the WASM PVM life cycle. But on this side, we don’t need to stick to everything the WASM PVM is doing. We just need to implement the subset that the kernel of Etherlink actually use. To give an example, the Etherlink kernel never checks the flag created by the PVM if the kernel panicks, so we don’t need to bother with it either. Similarly, the reboot counter is not really used beyond cosmetic logs, that we can reimplement as part of the runtime.

Manually testing the MR

Check it does not affect the size of other binaries.

-r-xr-xr-x 1 lthms lthms 367M Sep 24 09:23 octez-node

You can also run the minimal test showing that it’s possible to execute the kernel in proxy mode to create an empty block.

dune exec -- etherlink/bin_node/test/main.exe wasm_runtime

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR