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.

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.