The Importance of WASM for Web3 Development

Nitin Gurbani, blockchain developer and builder of DIA’s WASM-based oracle, illustrates the importance of the virtual machine to efficiently scale Web3 development.

6 minutes read
The Importance of WASM for Web3 Development

What is WASM?

WebAssembly, often referred to as WASM, is a relatively new type of portable binary-code format, capable of executing on modern browsers in an efficient manner. The code was released in 2017 by the World Wide Web Consortium (W3C) and involved engineers from Google, Mozilla, and Apple.

The original goal of WebAssembly was to enable high-performance applications on web pages. As WASM doesn’t provide any Web-specific features, it can also be employed in other environments, such as blockchain and smart contract development. In the blockchain development space, WASM is often referred to as Ethereum Virtual Machine — EVM’s predecessor. It is capable of delivering all the functionalities of the EVM while offering extra functionalities.

Analysing the Inefficiencies of EVMs

It is important to note, that EVM-based transactions are not human-readable, which considerably affects the user experience of the environment. Computationally, EVM is not sustainable from an energetic standpoint. While it was designed to be as efficient as possible, it still has some flaws that make it inefficient compared to its competitors like Polkadot, NEAR, Solana or Cosmos.

EVM has its own instruction set, memory size limitations and stack depth restrictions, which bears more risk for bugs and errors to occur. This makes it difficult to write safe smart contracts for EVM. As we saw with the DAO hack in 2016, even a small mistake in code can be exploited by hackers who are willing to take advantage of that loophole.

EVM has a stack size of 1024 and supports a word size of 256-bits. The 1024 cap indicates that the level of complexity for EVM smart contracts is constrained by design.

As a result, EVM’s limitations make it challenging for EVM developers to design advanced use cases.

Features — Why choose WASM over EVM

Fast, efficient and portable, with near-native speed, WASM’s promise is the capability to outperform EVM as a virtual machine for blockchains:

  • High performance: WASM enables high performance — it’s built to be as close to native machine code as possible while still being platform-independent.
  • Small size: WASM produces small-sized binary files. This is a great fit for the blockchain world as smaller binaries result in lighter transaction data and therefore save gas fees.
  • General VM & bytecode: WASM was developed to be deployed in any browser producing the same result. EVM on the contrary was developed for a specific use case. This has resulted in more teams using WASM for different purposes and generating a wide variety of tools and resources.
  • Tooling and support: as mentioned above, the community is creating tools and resources for WASM available to developers.
  • Efficient JIT execution: WASM natively supports 64 and 32-bit integer operations. This comes in handy when performing 64-bit operations because there is no need to decompose them into 32-bit and emulate instructions. Instead, WASM provides all numeric instructions with 64-bit support that map one-to-one with the CPU instructions.
  • Minimalistic: the formal specifications of a use case can easily fit on a single page.
  • Deterministic execution: WASM is easily made deterministic by removing floating point operations, which is necessary for consensus algorithms.
  • EVM can only process 256-bit bytecodes, which means that those smaller than 256 must first be converted to 256-bit format before being fed to EVM. The scalability issue of EVM is apparent as it only processes 25 transactions per second.
  • Supporting popular programming languages: WASM supports C, C++, C#, Assembly Script, RUST, preventing developers from learning single-use case languages like Solidity.

Current State of the WASM landscape

Chains supporting WASM

Currently, there are only a handful of blockchain networks natively supporting WASM and hence, a small number of WASM-based dApps. Some of the most popular networks supporting WASM are:

  • Solana: Solana is well-known for its near-instant finality and smart contract performance. Technically, Solana does not operate in WASM. Instead, it uses “Berkeley Packet Filter” bytecode as its Virtual Machine. However, the smart contract language will use LLVM (the same compiler that targets WASM) to compile their program, and it is very easy to recompile the code with minimal changes to WASM.
  • Near: Near is famous for its nightshade shards and high-performance WASM smart contract VM. Another reason why it is famous amongst developers is probably because of its sophisticated developer ecosystem. Near smart contracts can be written in Rust and AssemblyScript (a variant of TypeScript).
  • Substrate-based chains: The Polkadot network itself does not support smart contracts. Instead, parachains, blockchains that are built with Substrate, can implement a runtime module called the Contract Pallet. This pallet will allow any blockchains that implement it to execute WASM smart contracts.
  • Cosmos: similar to Polkadot, the Cosmos ecosystem also provides a core SDK for creating modular blockchains with interoperability. The Cosmos ecosystem now has smart contract capability thanks to the CosmWasm SDK module. Currently, Cosmos only supports Rust-written smart contracts. However, since the Go language was used to create the core module, we may see wider language support in the future.

Need for WASM Web3 Native Tools

WASM native dApps require Web3 tools written in WASM to work with and unlock their full potential. Therefore, infrastructure providers are required to redeploy their services in WASM to be able to be integrated with WASM smart contracts.

An example of a crucial building block for dApp development is blockchain oracles. Without WASM-native blockchain oracles, WASM smart contracts can’t access off-chain, real-world data, hence limiting the use cases and capabilities that dApps can perform.

DIA identified this issue early on and deployed its open-source oracle infrastructure on the Shiden networkShiden Network is the first live parachain in the Kusama network natively offering, alongside EVM, smart support for WASM smart contracts.

“Building WASM contracts is pivotal towards our vision of a strong interoperable future on Polkadot–opening bidirectional HRMP channels between Shiden and other Kusama parachains, enabling seamless communication and movement of tokens across chains.”
Hoom Kim Astar Shiden Network CTO
Hoon Kim
Astar and Shiden Network CTO

Future Outlook

From a technical standpoint, interoperability, scalability and developer onboarding remain the main challenges for the mainstream adoption of blockchain technology. Considering the limitation of EVMs and the market demand for technical improvement, WASM is one of the best candidates to become the standard smart contract virtual machine.

WASM’s architecture solves those challenges thanks to its low file size and high performance, multi-language support and cross-platform compatibility. These characteristics facilitate and enhance the developer experience to deploy dApps across multi-chain environments such as Polkadot, Cosmos, Solana and Near.

Looking for a WASM oracle?

Request your custom WASM oracle for token price feedsNFT floor price feeds or distributed randomness by getting in touch with DIA’s integration team via Discord or by submitting a Custom Delivery Request on the Forum.

Recommended resources for further reading

Dark mode
Light mode