Fundamentals: WASM vs. EVM and Why Aleph Zero Explores the New Frontier
Now that smart contracts are up and running on the Aleph Zero Mainnet, let’s explore WASM and EVM, the two most popular runtime environments that make this technology possible to implement on the blockchain.
Smart contracts are one of the more exciting developments of recent years, allowing users to create personalized use-cases whose execution is bereft of any kind of institutional intermediary or middleman. These contracts are pieces of specialized code that can be executed by users on demand; for example, two parties can potentially engage in an exchange of real estate through the help of a smart contract.
In this scenario, the smart contract will stipulate all of the requirements for the deal to be concluded. Once the pre-decided conditions occur, the property will change hands. The whole process will be completed and finalized by applying the smart contract without involving any real estate brokers, lawyers, or banks. In order to make smart contracts possible, it is necessary to employ a runtime environment known as virtual machines in which they can be executed. We’ll explore the two most popular ones, the Ethereum Virtual Machine (EVM) and WebAssembly (WASM).
The Building Blocks of Smart Contracts
Before we dive into the whole debate on EVM versus WASM, we should explain the mechanism that makes smart contracts feasible. This mechanism consists of the following elements:
- The smart contract language in which the contract is written, e.g., Solidity, Vyper, ink!;
- The compiler translates the code into the actual smart contract. This list of instructions that inhabits the smart contract is called the bytecode and must follow a certain standard to be executable. These rules are pre-established in the virtual machine standard;
- This bytecode is finally uploaded to the blockchain where it is stored. When a user performs a smart contract call, the corresponding piece of bytecode is loaded into the execution environment (a virtual machine able to execute that particular type of bytecode), where the instructions constituting that call are executed.
The Languages Behind Smart Contracts
Solidity is one of the programming languages through which we can code smart contracts. It is the foundation upon which the Ethereum blockchain is built and is the most popular smart contract language currently in use. Some of the pros of Solidity are as follows:
- Solidity offers inheritance properties for their contracts, including multiple-level inheritance properties;
- It is arguably easier to learn in comparison to an eDSL (embedded domain-specific language) like ink! due to Solidity’s similarity to other popular high-level languages.
- A wide selection of type-safe functions are supported in Solidity by facilitating ABI (Application Binary Interface);
- It is the default smart contract programming language when working within the Ethereum blockchain, as it was designed solely with the purpose of working with Ethereum. This translates into considerable support from a large community that worked through many of the initial bugs and provided a more user-friendly / dev-friendly environment.
The Aleph Zero smart contract pallet takes advantage of ink!, a Rust-embedded domain-specific language (eDSL) that compiles to WASM. This language was developed particularly for writing smart contracts for the FRAME Contracts pallet developed by Parity Technologies.
The main advantage of ink! is that it provides an immensely open ecosystem for developers because it simply expands on Rust instead of creating a novel language from scratch. This makes it easier for veterans and newcomers to begin creating smart contracts without delay. Besides employing ink!, Aleph Zero employs the cargo-contracts solution proposed by Parity Technologies, a CLI tool that helps you develop smart contracts in ink!
Here are the main reasons why we opted for ink!:
- Ink! possesses type and memory safety, which prevents overflows from occurring;
- Existing tools for Rust work for ink!;
- Existing libraries may be used if they can be compiled with the no_std feature – this is one of the bigger advantages of ink!;
- Inheritance by using Rust’s traits.
What is EVM?
EVM is a custom solution designed by Dr. Gavin Wood that permits the Ethereum blockchain to host smart contract functionalities. From a technical perspective, EVM call stack has a depth of 1024 items, and each item is a 256-bit word. Profound implications arise from these numbers as the 1024 item ceiling means that there are limits on the complexity of EVM smart contracts. What makes matters more complicated is that all operations are 256-bit, which means that our processors, which are usually 32- or 64-bits, need to simulate these 256-bit instructions using their actual register sizes (32/64-bit). The important consequence of this fact is the performance penalty that comes with the need for such a simulation.
Another challenge facing EVM is the fact that other than Solidity, there are only a handful of languages that compile to EVM bytecode, and none of them have gained significant popularity. Because EVM bytecode was created and deployed from the ground up, this means that if anyone wanted to employ a different language to work in this ecosystem, they would have to build a compiler from scratch. This limits the expandability of the solution proposed by EVM. Outside of the most basic smart contract applications, Ethereum’s native resolution has begun to show its limitations in recent years. On a brighter note, Ethereum remains the second largest blockchain ecosystem in the world, with countless applications being built on top of the network. This has resulted in a healthy ecosystem for developers working with EVM and Solidity.
Introduction to WASM
The main competitor to EVM is WASM, which is a portable binary-code format and corresponding text format for executable programs. It was designed to be an open-standard, highly modular environment for building applications on web pages, with the caveat that the system does not make any Web-specific assumptions or provide Web-specific features. This makes it perfect for applying it in a wide range of scenarios.
A testament to the quality of this environment is the ongoing support and development it receives from members of the W3C workgroup that includes such household names as Google, Mozilla, Apple, and others.
The Reasons Aleph Zero Uses ink! and WASM
A Technical Analysis of WASM
One of the main advantages of WASM is the flexibility it introduces regarding language choices a smart contract developer can employ when coding. This impressive list includes Rust, C/C++, C#, Typescript, Haxe, and Kotlin. Such a selection allows developers to write smart contracts in whichever language they are most comfortable with. An interesting twist involves the fact that there are tools (Solang) that can compile Solidity to WASM, so one could in principle, write Solidity contracts on Aleph Zero. The team behind Aleph Zero has been working in Rust for several reasons, including its lack of runtime overhead and its inherent security properties.
The pros of WASM are as follows:
- It is memory-safe, sandboxed, and platform-independent;
- The environment possesses 64 and 32-bit integer operation support that maps one-to-one with CPU instructions;
- Floating point operations have been removed, which is necessary to enforce deterministic execution;
- It is supported by the LLVM compiler infrastructure project. This means that WASM takes advantage of over a decade of LLVM’s compiler optimization.
Why WASM and ink! Are Ideal for Smart Contracts?
There are several key reasons why we at Aleph Zero chose to employ the tandem of WASM and ink!. The growing popularity of WASM and ink! has resulted in a healthy, growing ecosystem that is constantly evolving and improving its functionality, making it easier and faster to implement smart contracts. The streamlined nature of these two systems makes them free of undefined behaviors, and excess weight makes them lightweight and CPU friendly. They also possess features that remove dead code, and through compiler flags, they can protect themselves against integer overflow. They also boasts numerous tools that make programming simpler such as rustfmt, clippy, and rust-analyzer.
Aleph Zero and Smart Contracts
Smart contracts are one of the underpinnings of the decentralized internet, so it is paramount that the technological stack supporting them is both flexible and hospitable for developers of all backgrounds who are interested in exploring the Web3 space. The team behind Aleph Zero is confident that our choice to take advantage of the WASM standard combined with Rust and ink! will result in an ecosystem that, for years to come, will provide an exciting playground for innovative smart contract use cases—and significant real-world value as a result.
Monthly Update: August/September
August and September of 2023 were a crucial time for Aleph Zero: we’ve published the new visual identity for Common and publicly announced our involvement in the idOS. Read on to learn more about what we got up to at the end of Q3! Aleph Zero Signer release At the very beginning of August, Aleph
Shaping the Creator Economy with Panjea. Podcast Key Takeaways
In the Aleph Zero Podcast episode, we meet Kieron Bain and Lee Kerr to discuss Panjea, a novel creator-focused social media platform currently being developed on the Aleph Zero network. TL;DR Too long, didn’t listen There Is an Appetite for Web3 Social Media Panjea is one of the most popular projects currently under development in
Testnet 12.0 is out. Here’s what’s new.
Today, we’ve launched Aleph Node version 12.0 on our Testnet. There are new improvements to the platform’s capabilities and staking. Here’s all you need to know! What’s New in Aleph Node 12.0? Aleph Node 12.0 is now available for Testnet validators. It will follow the standard procedure of testing over the next 4–6 weeks before