Before getting into the details, we would like to give you notions on how WebAssembly was born and how fast was/is its adoption.
It is a fact that JavaScript is currently used in all modern web browsers to allow client-side scripting. However, due to the complexity of this language, its security flaws, and to gain in performance, several alternatives appeared through the years (for example, the infamous Java applets). In 2014,Emscripten proposed to use a strict subset of JavaScript, asm.js, to allow low-level code such as C to be compiled into JavaScript. Asm.js was first announced as an LLVM backend. Thus, this approach came with the benefits of having all the ahead-of-time optimizations from LLVM, gaining performance on browser clients compared to standard JavaScript code. Asm.js demonstrated that client code could be improved with the right language design and standardization.
A few years later and following the asm.js initiative, the W3C publicly announced the Wasm (Wasm) language in 2017. Wasm is a binary instruction format for a stack-based virtual machine. The announcement of Wasm marked the first step in the standardization of bytecode in the web environment.
Wasm is designed to be fast, portable, self-contained, and secure, and it outperforms JavaScript, showing only a 10% slowdown compared to machine code execution. Wasm has been demonstrated to be perfect for web browsers. Yet, this language evolved outside web browsers. Some research demonstrated that using WebAssembly as an intermediate layer is better in terms of startup, memory usage, and bandwidth than containerization and virtualization. Consequently, in 2019, the Bytecode Alliance proposed WebAssembly System Interface (WASI). WASI pioneered the execution of WebAssembly with a POSIX system interface protocol, making it possible to execute Wasm directly in the operating system. Therefore, it standardizes the adoption of WebAssembly in heterogeneous platforms, making it suitable for edge-cloud computing platforms.
Solomon Hykes, the former CEO of docker, highlighted the importance of this fact in a very stunning tweet:
Solomon Hykes on Twitter: "If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! https://t.co/wnXQg4kwa4 / Twitter"
In fact, docker recently supports Wasm as images in their platform.
Why Containers and WebAssembly Work Well Together | Docker
All Wasm programs are compiled ahead of time from source languages. LLVM has included Wasm as a backend since release 7.1.0 published in May 2019, supporting a broad range of frontend languages such as C/C++, Rust or Go. Despite other benefits that we will discuss later, this supporting includes ahead-of-time optimizations, e.g. all of them included in LLVM by default. Remarkably, LLVM is not the only pipeline supporting the generation of Wasm binaries.
The execution of Wasm 1.0 is included in the Filecoin Virtual Machine (FVM) specification. The main idea is to run WebAssembly binaries as smart contracts, so-called actors, in the context of the FVM. Since WebAssembly is an intermediate representation, our FIL-ders benefit of an extensive range of frontend languages to implement them. In practice, one only need to learn our ABI and how to interact with our mainnet. For example, by using the polyphene/fvm-rs-sdk project, any developer can create an actor for the FVM directly in Rust, compile the code to Wasm and put it into the mainnet.