The primary approach for creating smart contracts involves using languages specifically designed for the Ethereum Virtual Machine (EVM), such as Solidity and Vyper. While these languages were purpose-built for Ethereum, when compiled to 256-bit runtimes, the EVM smart contracts inadvertently face slower execution times.
Enter, WebAssembly, or Wasm. With its ability to match the semantics of a CPU architecture like ARM or x86, Wasm paves the way for near-native execution. Let’s explore how Wasm modular blockchain apps can transform Web3.
WebAssembly (Wasm) is a binary instruction format for a stack-based virtual machine. It has four number types of 32- and 64-bit integers and floats (i32, f32, i64, and f64) and uses linear memory. Wasm has rapidly emerged as a portable, performance-oriented solution that is compatible with most web browsers. This makes it an appealing target for most Web3 developers.
With its minimalistic design and superior execution efficiency, Wasm is widely adopted by prominent blockchain platforms, including Radix, Near, and EOSIO, where it serves as the runtime for smart contracts.
The full list of blockchain protocols supporting compilation to Wasm is steadily growing.
Most Wasm smart contracts are written in Rust and Go. Other popular languages for this task include nk!, C/C#/C++, AssemblyScript, TypeScript, Motoko, and many others.
Like most contracts, Wasm smart contracts mostly involve contract storage, permission, and account management logic. Unlike contracts for traditional execution environments, Wasm contracts are modular and can be easily modified to meet specific requirements, given the appropriate blockchain implementation. The same base logic can drive different blockchains, modifying only the interface layer. This feature makes Wasm an advantageous choice for creating cross-compatible and efficient dApps, as it provides a general-purpose virtual machine and bytecode—all within a secure, high-performance environment.
Overall, a Wasm smart contract reflects a paradigm shift in contract development, eliminating the need to create a specialized language for each platform. Powered by a configurable virtual machine, these contracts ensure secure and scalable execution, dividing the load evenly for effective maintenance.
Wasm executes at near-native speeds thanks to the key technical advantage of a 32-bit word size, particularly when compared to 256-bit architectures typically utilized by blockchains such as Bitcoin/Ethereum and their copies.
The challenge with 256-bit runtimes. Platforms like Ethereum’s EVM and all their forks operate on a 256-bit word size. This size refers to the amount of data a CPU’s internal data registers can process simultaneously. However, procedures involving 256-bit integers or cryptographic functions can be computationally intensive, leading to slower execution times. Besides, modern hardware usually supports smaller word sizes, meaning that 256-bit operations must be emulated, adding to the inefficiency.
The efficiency of Wasm32. In contrast, Wasm uses a 32-bit word size in its runtimes (Wasm32). This smaller word size is designed to align with the physical machine semantics of modern hardware, enabling it to execute with increased efficiency. This alignment makes Wasm vastly more efficient compared to 256-bit runtimes for integer operations, consensus algorithms, and more blockchain operations, with speed improvements potentially in the thousands.
Size: While sometimes larger, Wasm contracts size is generally comparable with EVM and aligns with the space-constrained blockchain environment, enabling the delivery of smart contracts over the Internet.
Security: Like most VMs, Wasm offers a memory-safe, sandboxed execution environment for non-web embeddings and enforces the web environment’s same-origin and permissions security policies.
Language support: In theory, Wasm allows developers to compile a Wasm module from various high-level languages, including Rust, C/C++, C#, Typescript, Haxe, and Kotlin, among others, granting high flexibility and inclusivity. However, the variety is constrained by the limitations of the blockchain platform as it also requires SDK and API for a given language from blockchain devs.
Cross-platform portability: Binary format allows for efficient execution for both web and non-web embeddings—meaning the same set of codes can extensively run on different platforms without much alteration required. For now, this merit is not as important from the blockchain perspective.
While debugging features are common across virtual machines, Wasm’s debugging tools for blockchain applications are still evolving, making EVM debugging potentially easier due to the availability of established tools.
EVM is currently favored for smart contract debugging, but Wasm still provides at least some testing capability. Similarly to almost every VM, Wasm’s binary format allows for quicker parsing and execution. Wasm also offers a human-readable text format (.wat) for debugging and testing, but this is very rarely used in practice.
Wasm’s design as an object file format executed in the browser notably lacks integrated memory safety mechanisms such as stack canaries and address space layout randomization (ASLR). It’s important to note that this limitation is not important in the blockchain context.
See full WebAssembly Specification here.
Wasm smart contracts have inherent vulnerabilities, much like Ethereum smart contracts. For example, analyzing 4616 smart contracts on EOS, researchers have identified 13 real-world vulnerable contracts.
Wasm smart contracts are often compiled from memory-unsafe languages like C and C++. This deficiency exposes Wasm to classic vulnerabilities like stack overflow, which are otherwise tough to exploit in native binaries due to inherent mitigations.
Compounding this vulnerability, certain environments even provide developers with built-in functions like memcpy()
and strcpy()
. While useful, these functions can inadvertently lead to stack overflow issues if not used cautiously.
General-purpose languages weren’t designed to write smart contracts. To bridge this gap, we can leverage suitable libraries. For instance, Rust can write smart contracts effectively but requires a lot of code in its current state, dampening its ease of use. It is also worth noting that while Rust offers excellent support enforcing immutability, this feature is seldom used.
Despite its impressive characteristics, the inherent vulnerabilities in Wasm smart contracts necessitate enhanced security measures through a more thorough code review during development and execution.
The extensive language support of Wasm is an impressive feature, supporting C/C++, Rust, AssemblyScript, C#, Dart, Via Flutter, F# Go, Kotlin, Swift, D, Pascal, Zig, and Grain (provided that a blockchain platform also supports it).
Currently, WASM lacks EVM-level tooling for developers, as noted here. Key problems are inadequate documentation, lack of dedicated development tools and live public networks to run the contract, and few existing projects to guide newcomers.
Despite these challenges, some tools do exist:
Note: the vast majority of Wasm smart contract development tools are platform-dependent, meaning they will only work with the intended blockchain.
One of the ways to start writing Wasm smart contracts is through a Rust language extension that uses the Contracts pallet called !ink. Using a Rust-like syntax, it supports multiple constructor functions and offers variable storage entries, all while hiding the raw implementation details. Ink! also offers a vulnerability analyzer and dApp Boilerplate. With ink! you can use the following tools:
Overall, for some developers, extensions like ink! may offer a gateway into Wasm smart contracts.
Talking about the future, let’s focus on the Wasm paradigm in smart contract development. It is truly game-changing. Instead of having to create a specialized language for smart contracts for every platform, the industry can use Wasm with a limited VM as a security layer. A configurable VM used by many is going to be a good place to split maintenance costs.
Further, the modular nature of Wasm empowers smart contracts to be created as truly executable code on a blockchain, which can be easily adapted based on specific requirements. For example, the same base logic for yield calculation can be utilized across two different blockchains simply by adjusting the “interface” layer, enabling seamless scaling across different protocols.
Wasm’s potential isn’t just limited to blockchain applications. As an efficient intermediate language (IL), Wasm aspires to become a third architectural model for cross-platform applications, transcending beyond the blockchain-specific use case. The fact that Wasm can be instrumented effectively not only for blockchain but also for a diverse set of platforms – from web browsers to embedded systems – greatly broadens its scope of influence in the future of software development.
In essence, the future for Wasm smart contracts is promising. With robust security, cross-platform compatibility, performance efficiency, and scalability, we can be talking about a new paradigm shift in smart contract development with Wasm.
As we look ahead, the adoption of Wasm will continue to rise, with many projects and protocols incorporating it into their infrastructure, reaffirming its transformative potential in the blockchain ecosystem.
Be the first to receive our latest company updates, Web3 security insights, and exclusive content curated for the blockchain enthusiasts.
Table of contents
Tell us about your project
10 min read
Discover
13 min read
Discover
13 min read
Discover