Now we use wasmi for executing the wasm version of the runtime. The problem with that is that it is very slow. #1519 and #1845 show us that the difference with natively compiled code is very roughly around a few tens of times. wasmtime should allow us to move the performance closer to that point.

Another option would be to integrate LLVM, but it is a rather heavy dependency and I am not sure about any engines implementing wasm in Rust (not that it should be terribly hard to do). Wasmtime is way smaller than LLVM and should be easier to integrate. Because that cranelift and lightbeam is not terribly stable and don't support all platforms, we might want to continue providing option for using wasmi, at the very least for tests and/or fuzzing of the runtime execution logic.

#2416 envisioned usage of browser wasm engine for a node that is compiled for using within a browser.

To satisfy all constraints it would be great to have something that eases implementation of the substrate host API for multiple engines since every engine has its own API. Down the road, #2334 would be ideal. Altough for the first step, we might just want to write helpers that abstracts away all the differences. It could be a procedural macro which generates all thunks and shims and a runtime crate coupled with the macro.

There is also a similar task for the sandboxing: #2633. It might be beneficial to devise a mechanism that accounts for both use-cases.