WASM runtime

Considered runtimes:

  • wasmer
  • wasmi

A good comparison overview is given in this thread that discusses replacing wasmi with wasmer and its links. In summary:

  • wasmer has native rust closures (simpler code)
  • wasmer uses lexical scoping to import functions, wasmi is based on structs and trait impls
  • the wasmer org maintains wasmer packages in many languages
  • wasmer may be vulnerable to compiler bombs
  • gas metering
    • wasmi inject calls to the host gas meter from Wasm modules
    • wasmer
      • uses Middleware which injects the instructions at the parsing stage of the compiler (with inlining) - reduced overhead
      • must also consider compiler gas cost and how to handle compiler performance changes
    • it's hard to implement gas rules for precompiles
  • nondeterminism concerns
    • different wasm versions (e.g. newly added features) have to be handled in both the compiled and interpreted versions
    • non-determinism in the source language cannot be made deterministic in complied/interpreted wasm either
    • threading - look like it has a long way to go before being usable
    • floats/NaN - can be avoided https://github.com/WebAssembly/design/issues/582#issuecomment-191318866
    • SIMD
    • environment resources exhaustion
  • both are using the same spec, in wasmi words "there shouldn't be a problem migrating to another spec compliant execution engine." and "wasmi should be a good option for initial prototyping"
    • of course this is only true if we don't use features that are not yet in the spec

wasmer

Repo: https://github.com/wasmerio/wasmer

Compiled with multiple backends (Singlepass, Cranelift and LLVM). It support metering via a Middleware.

wasmi

Repo: https://github.com/paritytech/wasmi

Built for blockchain to ensure high degree of correctness (security, determinism). Interpreted, hence slower.