The future of Web Assembly (WASM): the hardware-execution revolution!
By: Timothy Mccallum
Tags: Wasm, Wasi, Rust, Secondstate, Webassembly

Wasm in blockchain implementations

Bitcoin and Ethereum (and some other blockchain implementations) use a stack-based architecture which has similarities to WebAssembly’s stack-based architecture.

There are of course some differences in each of the unique stack-based virtual machines. For example equivalents to the well known stack-item-duplication operations such as Bitcoin’s OP_DUP opcode and Ethereum’s DUP1 to DUP16 opcodes are not found in Wasm.

Pictured: Ethereum Yellow Paper’s duplication operations.

Thankfully, Wasm offers a fixed amount of local variables for each Wasm function. These variables store information inside single index spaces which are local to that specific function. Point being, there are other ways of emulating certain stack behaviours.

Another important difference relates to the number of items which can be pushed onto the stack, per operation. If you look closely at the Ethereum Yellow Paper (pictured above) you will notice two columns labelled δ and α.

The column labelled δ represents the number of items to be removed from the stack. The next column over, labelled α, represents the number of additional items to be placed on the stack. As you can see each of the operations on the Ethereum Virtual Machine (EVM) is able to push many items onto the stack. In the above example DUP16 is capable of pushing 17 items onto the stack.

In the current version of Wasm however, only one single result value can be pushed on to the stack by a single instruction*see Update 20191128 in the Appendix* (webassembly.github.io, 2019).

With many other nuances like this, it goes without saying that building a compiler which is capable of converting any high level blockchain smart contract source code to executable Wasm-flavoured code is a seriously complex and onerous task.

Developers from SecondState recently built a compiler called Soll (video demonstration available here) which was the first compiler to allow Ethereum Solidity smart contracts to be, compiled, deployed and interacted with on the Ethereum flavoured Wasm (Ewasm) testnet.

Trail-blazing work, such as this, marks the beginning of exchanging digital value and data, as well as, engaging in rule-based interactions between devices across the decentralised web. The weaving of browser-based devices into blockchain’s already decentralised architecture could make permission-less, censorship-resistant, borderless, yet secure, web-based, transacting mainstream.

An article written after SecondState’s presentation at Devcon5 (an Ethereum conference for developers) illustrated that SecondState are also considering building a compiler from Ethereum’s intermediate language “Yul” to llvm to Ewasm.

This additional new work potentially allows for a wider variety of smart contracts (written in languages such as C++, Rust, Vyper etc.) to be deployed to Ethereum’s Wasm blockchain implementation.

It quickly becomes apparent that introducing new languages (across separate sections of compiler toolchains) leads to enormous potential in terms of language agnostic collaboration.

This is one of the great future benefits, which Wasm brings to the table.