Investigate alternative wasm runtimes

[ethanfrey]

Our 1.0 release is primarily blocked on a stable version of wasmer, which is on a timeline we have no influence on. There are many improvements in their codebase, but being tied to one pre-1.0 dependency whose timeline and stability you do not control is a large risk for a company that wants to be nimble. We have invested quite some work into updating to the latest wasmer master and would like to carry on that path if possible. This issue to to gather other possibilities as Plan B in case there is timeline pressure.

Requirements:

• Stability guarantees (code has no know bugs, core APIs are not in flux)
• Can be called from Rust language (or Go directly)
• Ability to perform deterministic "gas metering" based on instructions executed, not clock time
• Ability to restrict memory allocated (less than 4GB)
• Flexible WASM<->Rust import/export interface that covers our current functionality
• Compilation step without "JIT Bombs"/"Compiler Bombs"
• Fast execution time (this include loading wasm/precompile into memory, as well as the actual contract execution)

Desired:

• Passed security audit
• Reached 1.0 (does anyone ever reach that?)

Note: in my research I found a list of blockchain VMs in Rust, which included... CosmWasm :tada:

[ethanfrey]

Lucet is a project by the "ByteCodeAlliance", creators of cranelift/wasmtime, and Fastly. It is in Rust and argues a 50 microsecond startup time, compared to 5ms in chrome or 15ms in wasmer 0.17.

Con: the security design explicitly states that extra defense is needed for compiler inputs:

Attack vectors stemming from asymmetric consumption of resources inherent in compilation processes, for example consumption of CPU or memory for large or complex inputs, should be addressed by user/administrator via environmental controls or similar. For example, a lucetc deployment could limit input size earlier in the processing flow, include cgroup runtime controls, etc.

Con: latest release is 0.6.1 and there is no blockchain project using it

[ethanfrey]

WasmTime is the flagship project of the ByteCode alliance

Pro: can use lightbeam streaming JIT - lightbeam was a Parity project with blockchain plans - this leads should avoid JIT bombs as it does one pass

Configurable. Whether you need to precompile your wasm ahead of time, generate code blazingly fast with Lightbeam, or interpret it at runtime, Wasmtime has you covered for all your wasm-executing needs.

Pro: At v0.20.0 and meets full WASM (and WASI) specs

Standards Compliant. Wasmtime passes the official WebAssembly test suite, implements the official C API of wasm, and implements future proposals to WebAssembly as well. Wasmtime developers are intimately engaged with the WebAssembly standards process all along the way too.

Pro: Imports and exports seems similar to what we use with wasmer

Con: No native gas metering, we would have to use parity/wasm-utils gas metering, which is true for most projects here.

---

Looking at the wasmtime docs, we get a Config object to customize the Engine, where we can control memory allocation as well as the compiler.

We have to set the Strategy to Lightbeam along with a feature flag to enable such JIT. It would be interesting to test this out on some standard wasm code and benchmark it.

And this shows how to use Funcs for imports and exports

[ethanfrey]

wasm3 is an interesting project: "Fastest WASM Interpreter". Being an interpreter it doesn't suffer from JIT bombs or a class of possible exploits. And they keep high performance.

Con: only on 0.4.1 and not clear if this is designed for production use or a cool idea

Con: Written in rather low-level C with Rust (and Go) bindings on top

[ethanfrey]

wasmi is a safe but slow bet.

wasmi was conceived as a component of parity-ethereum (ethereum-like contracts in wasm) and substrate. These projects are related to blockchain and require a high degree of correctness, even if that might be over conservative.

It is used in Polkadot and also by Secret Network for their SGX enclave implementations.

It is considered fairly slow, but they were clocking ~80tx/s on Secret, so 12ms per call is not horrible when compared with wasmer startup overhead.

Pro: Secret network has ported cosmwasm to wasmi and we can look at their code (and they might help upstream some of it)

[webmaster128]

Great summary, thanks! Let me add some note for the record.

Lucet seems to focus on ahead of time compilation and instantiating a module many times. I think we have a different focus. If we don't want to require explicit compile and execute calls, every execution should have roughly the same cost, no matter if the cache is hot or not. It uses Cranelift (optimizing compiler) and native modules, which Wasmer offers as well. It has no Windows support We don’t currently have a business case for supporting windows, so we couldn’t put those resources towards it. We run Lucet exclusively on Linux in production, and some developers use it on the Mac. (https://github.com/bytecodealliance/lucet/issues/205#issuecomment-500150690)

WasmTime seems to be serious competetion to Wasmer.

Given that we are very happy with the feature set and code quality of Wasmer, and could adapt our time line to not be blocked by the Wasmer 1.0 release, I think it is safe to say we stick with it for the foreseeable future.

[ethanfrey]

Sounds good. Happy to see wasmer reborn being merged