@adlrocha - WASM: A Universal Bytecode

Not only for the web but for smart contracts and much more.

astronaut in spacesuit floating in space

I have been pretty obsessed lately with blockchain interoperability, specially at a protocol and smart contract level (nothing you couldn’t expect). We managed to build the Internet and make different networks interoperable. We managed to build browsers and Javascript in order to make web applications interoperable. Why are we having such a hard time to make smart contracts and DLTs interoperable? (I know, know, this is an open problem being tackled by several projects such as Cosmos or Polkadot).

The idea of this publication is definitely not new (check this post, or this one, or maybe this one, or what about this project?). But while reading and learning about Web Assembly (WASM), and linking the concepts with the problem of blockchain interoperability, it came to me, “Wait a minute! We may already have the key module to ensure (at least) some interoperability between platforms at a computational and smart contact level”. And here is where I started my research about WASM and blockchain technology (a research that, due to the great amount of resources I’ve found in the process, may last more than one publication. We’ll see!).

Pardon me. WASM?

You are right, some of you may not know yet what WASM is. Let me give you a brief introduction before we go deep into the topic. “WebAssembly is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust/Go, enabling deployment on the web for client and server applications”. Pretty straightforward definition (I briefly presented it already in one of my previous publications). In short, WASM is a W3C standard that defines a binary format (interesting) intended to run on web browsers’ JavaScript engines. All major browsers have added support. So you can easily call your WASM code from JavaScript and vice-versa. WASM offers:

  • Near native-speed: Allows you to run code at near native speed compiling it from several high-level languages.

  • No Plugins: No browser plug-in needed, the browser supports WA out of the box.

  • Built-in interface to communicate with JavaScript allowing the sharing of objects in both directions.

WebAssembly has been designed with a number of performance-intensive, browser-based use cases in mind: games, music streaming, video editing, CAD, encryption, image recognition. In a nutshell, use cases hard to implement solely with Javascript due to their high-performant requirements. Some examples where WASM is perfect for are:

  • Already existing high-performance codes and modules existing in a targetable language: Such as an existing cryptographic library written in Rust that you want to include in your web applications. You could create a WASM module of the crypto library in order to use it along the JS code of your web app leveraging WASM’s near-native performance.

  • High-performance code where Javscript isn’t ideal (think about AI in your browser).

  • Porting libraries and applications from one platform to other. WASM’s standard allows the use of a single binary in several independent platforms. With WASM you can port libraries, modules, or complete applications from one platform (desktop) to another (web).

The WASM workflow

In order to illustrate how WASM works, let’s follow a typical WASM development workflow. Imagine that I want to write my own WASM cryptographic library to be able to efficiently validate ZkSnarks proofs in the browser.

  • The first think I would do is writing the library code in one of the compatible subset langauges for WASM such as Rust, C++ or Go.

  • I would then compile the library into WASM, generating the .wasm bytecode.

  • With the WASM module compiled, I would be able to start calling it from my web apps through JS. The Javascript Engine of my browser will worry about transaling wasm into machine code and running it.

A good way to start getting a quick grasp of how it is to compile WASM without having to install anything in your machine is going to WASMFiddle and testing its example in C. This sample allows you to compile a C program into WASM and execute the resulting module from JS (click the gear from the top-left of the screen to trigger the magic).

If you want to try WASM in a more serious way, have a look at the following tutorials in Rust and Go (I am sharing resources I’ve tried myself using my favorite programming langauges, but you can find many other references out there for C++, JS and even Python).

The Base Layer of Decentralized Applications

Now that we know what WASM is, let’s move to our matter at hand. What does WASM have to do with blockchain and smart contracts? Well, the idea that came to me while exploring WASM was, “if WASM defines a standard binary format, couldn’t we use a WASM-compatible VM in every smart-contract based platform?”. This turned out not to be a new idea, but an active field of research and experimentation:

  • It was not exactly what I was thinking about, but as many of you may already know, there’s an initiative in Ethereum called eWasm that aims to replace the current EVM with an eWasm virtual machine. eWasm is basically WASM and offers greater and improved performance over the current EVM architecture. Not only that, but adopting WASM in Ethereum would open the floodgates to developer adoption because any developer would be able to write a dapp in any language they are comfortable with and compile to a dapp. This seems like a first step towards my idea of inter-platform smart contract compatibility: first we get WASM in Ethereum, and then we start standardizing the VM and migrating it to other platforms.

  • Even more, other projects already use WASM as its smart contract execution environment: The virtual machine of EOS understands WASM natively. U°OS understands WASM natively. Tron is planning to move to WASM this year . In short, WASM is increasingly being used as the de-facto execution environment for smart contracts and distributed logic.

  • Great! blockchain platforms are increasingly adopting WASM, but what I was thinking about wasn’t just in WASM for blockchain adoption but for interoperability. Were there already initiatives tackling this problem? It was then when I came across the announcement of WASI: A system interface to run WebAssembly outside the web. And here is where I started to get really excited about the potential of WASM and its use in distributed technologies.

WASI: A first step towards a standard blockchain interface

WASI, is a proposal for a WebAssembly system interface. Developers are starting to push WASM beyond the browser (see the blockchain case we have been discussing), but it doesn’t exist a solid foundation to build upon. Before WASI, WASM code talked directly to the browser, who was responsible for interacting with the underlying system through its system interface. If we remove the browser in this equation, WASM has no way of interacting with the system in a secure and standard way.

WebAssembly is an assembly language for a conceptual machine, not a physical one. This is why it can be run across a variety of different machine architectures. Just as WebAssembly is an assembly language for a conceptual machine, WebAssembly needs a system interface for a conceptual operating system, not any single operating system. This way, it can be run across all different OSs. And this is the reason for WASI.

One C source file being compiled to a single binary

WASI is implementing interfaces for the execution of WASM bytecode in several target platforms. But what if one of these platforms was a smart contract execution environment? Even more, what if there was a standard WASI interface for the interaction between blockchain networks and WASM that could be implemented and adopted by every blockchain project (the same way browsers adopted the Javascript VM for the execution of code)? This would mean that we would be able to run our WASM-compiled smart contract (distributed logic) in any smart contract platform. Moreover, this standard interface would open the door for the communication between smart contracts of independent networks. They would all follow the same interface and run the code over the same target execution environment.

It turns out this idea wasn’t new either, and projects such as Polkadot where already exploring this concept using WASM:

While Wasm itself benefits from wide support and integration, unlike EVM it is not built with the purpose of interacting with the blockchain. The Parity Ethereum Client runs the Wasm bytecode in the Wasmi interpreter, which enables the Wasm code to access and interact with the blockchain. Right now we’re testing Wasm on the Kovan testnet on which EVM and Wasm smart contracts can co-exist and even interact. The Ethereum Foundation is also working on implementing Wasm support into geth, the Go client implementation, and researching the use of Wasm in sharding.

Because we believe in Wasm to be the foundation of decentralised systems development, Polkadot, a next-generation blockchain interoperability protocol, is being built with Wasm support from the ground up. Polkadot smart contracts will be able to be developed in any language that compiles to Wasm.

We look forward to a future where secure smart contract development is easier and where developers can develop smart contracts with the languages they already know.

-Polkadot, 2018

This same concept I suggest is also presented in the following post.

Three runtimes—wastime, Node, and the browser—passing their own implementations of wasi_fd_open into the sandbox

WASM will be everywhere!

First came the browser, and then the OS, CDNs, serverless, edge computing, blockchains, IoT, the kernel, portable CLI tools, soon it will become an enabler for blockchain interoperability, and more yet to come. WASMs portability and security makes it a perfect candidate for its use in many platforms and use cases. I have felt in love in this project, and I feel I still have to learn a lot about it and the people behind. So expect many more articles about WASM (I have already planned two more while I was researching for this one). Welcome WASM, a universal bytecode!

Wasm on the blockchain Berlin 2019

To learn a bit more about the open fields of research around blockchain and WASM I invite you to check out the following summary of the talks presented in the “WA on the Blockchain workshop” in Berlin early this year.

I will end the publication sharing one of the lines of work from this workshop that impressed me the most:

An Awesome Runtime (OS)

Martin Becze

Martin’s talk is a call to action to start building an OS that all blockchains can support and all smart contracts can run on.

Martin starts with reminding that one of the promises of the blockchain is portability which is currently left unfulfilled because blockchain contracts are not portable across the blockchains, which is primarily because we do not have standard interfaces and tooling. Ewasm was the first to take a stab into this problem, by standardizing interfaces and metering. Unfortunately, Ewasm was not designed to be portable, because they did not think of it as an operating system. However, any blockchain that has smart contracts talking to each other is implementing an OS. The blockchains then can be viewed as similar to the PC manufacturers — adapting to the OS layer. Such an OS layer should exercise POLA (Principle of Least Authority) and not use ambient authority, which is by the way not how current *nix or Ethereum work.

In general, OS needs performance, security, portability, and toolchain compatibility. But blockchain OS also needs determinism and integrity checks on the file system which is currently usually done through Merklization. It might actually be advantageous to have a Merklized file system when running such OS locally not on the blockchain. If we have that then smart could run on local machine and blockchain. Conversely, it would be nice if smart contracts had access to the POSIX-like API. If we could map smart contract filesystem to Linux filesystem without virtualization that would be great. This comes back to the discussion of WASI and POSIX that happened in other talks. Martin then opens discussion with the audience and the audience suggests that for now we can build adapters for POSIX but we should not constrain the development of an alternative standard that is not compromised by the legacy of POSIX; Martin agrees. The audience also notes that trying to have programs that run locally, on the cloud, and on the blockchain might be an overreach, because we are still not able to run the same programs on phones and cloud, which is the first problem we need to solve.

Current focus: Martin’s talk is a call to action to start building interfaces, kernel, and tooling that would eventually lead to the OS.