A hitchhiker’s guide to WASM smart contract ecosystem

Post Material after WASM conference 2022

Post Material after WASM conference 2022

Introduction

Smart contracts are what allow other people to create custom use cases on top of a blockchain.

For a blockchain to support smart contracts, it must have a smart contract execution environment or a smart contract virtual machine. Arguably the most popular environment is the Ethereum Virtual Machine (EVM), first introduced by the Ethereum blockchain, and later adopted by many different networks that wish to leverage the massive ecosystem that Ethereum was able to create. However, there are other smart contract virtual machines that are not EVM, and most of them are based on WebAssembly (WASM).

EVM vs WASM

EVM is a stack-based state machine that interprets the EVM opcode into computational instructions that can be executed on top of the blockchain. It was made by the founder of Polkadot, Dr. Gavin Wood. Developers can use the contract-oriented language, such as Solidity or Vyper to write applications that can compile down to the EVM byte code. EVM has a depth of 1024 items, and each item is a 256-bit word.

The 1024 item limitation means that there is an inherent limitation of complexity for EVM smart contracts. On top of this, because all operations are 256-bit, this also means that all non-256-bit processors (so all) will have a significant overhead when computing these operations. Furthermore, the language capability is also a problem as the EVM bytecode is made from the ground up, so if any other language were to target EVM, they will have to create the compiler from scratch, making it very difficult for expandability. Not to mention the unusual syntax of a contract-oriented language, making the barrier of entry quite steep. Overall, the limitation of EVM makes it very challenging for Solidity dApp developers to create a complex use case.

With more advanced use cases, smart contracts demand more complexity and EVM has been showing its limitations. That is where the WASM-based smart contract comes in.

WASM is technically a binary instruction format that can run on stack-based virtual machines that implement the instructions such as V8. But for the general public and in this context, when we say WASM, we refer to a generic virtual machine that can execute WASM instructions. WASM itself is a common standard for executing native-level operations from a browser environment. The development is led by industry leaders like Google, Microsoft, Mozilla, Apple, and more. With the power of WASM, you can run any hardware-intensive work such as games from the browser with near native-level performance.

Similar to EVM, WASM is also a stack-based VM that operates through a bytecode. Programming in WASM means using a higher-level language that can compile down to WASM bytecode that can only run within the WASM sandbox (VM). In other words, WASM can be a perfect fit for a smart contract VM. And many popular blockchains share this sentiment as we are seeing an increased number of high-performing networks that use a custom VM that is either inspired by WASM or is directly using WASM.

The main advantage that WASM has over EVM are but are not limited to:

• Native 32/64-bit operations
• Extensive language support
• Easier to expand the ecosystem
• High performance and compatibility

There may be more, but these are the main reasons why the blockchain ecosystem is moving to WASM including eWASM, a WASM implementation of EVM.

So we know that WASM-based smart contracts are technically superior to EVM, but why is EVM still king when it comes to dApp development? Why are so many networks still using EVM?

The simple answer is because of its developer ecosystem. There are so many tools, examples, materials, and communities behind it, Solidity is the gateway language for many new dApp developers, and because most blockchains with high liquidity support EVM, it makes it difficult for new projects to ignore them.

So let’s look into how other blockchain networks using an alternative VM manage to row their ecosystem despite EVM?

Other Smart Contract Platforms

Solana

Solana is well-known for its near-instant finality and smart contract performance. Interestingly, they call their smart contracts ‘on-chain programs’ which can be written in C++ and Rust. And technically, Solana does not operate in WASM. Instead, they use Berkeley Packet Filter bytecode as their VM. However, the 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.

The main documentation can be found in the official Solana docs (https://docs.solana.com/), which is where all new developers are expected to start. However, there are no other educational materials that are maintained or endorsed by the core team.

Although their client API, @solana/web3.js is lackluster due to the way how communication with on-chain programs works, their biggest strength comes from their all-in-one tool called the Solana Command-line tool.

From a single CLI tool, users can use the following functions to name a few:

• Faucet airdrop
• Account management
• Deploy on-chain program
• Build transactions
• Node management
• Staking
• Signature utility

There is no embedded scaffolding in the CLI, there is a separate repository maintained by the core team that developers can use for their projects.

Near

Near is famous for its nightshade shards and high-performance WASM smart contract VM. But another reason why it is famous amongst developers is probably because of its sophisticated developer ecosystem. You can write Near smart contracts with Rust and AssemblyScript (a variant of TypeScript)

Similar to Solana, Near also has a single document site which can be found at https://docs.near.org/. First-time developers will only need this documentation for both client-side and smart contract development, with a link to the node management/development in there too.

They also have a list of external resources that are helpful for developers wanting to learn on their front page.

Near also has its own JavaScript client API called near-api-js. Developers can use this API to create any RPCs for the node such as calling smart contracts, making transactions, and more.

Perhaps the biggest tool that Near has is the Near CLI, which is a Node.js CLI tool that uses the near-api-js in the back to interact with the Near blockchain.

The Near CLI can do the following:

• Account management
• Deploy smart contracts
• Interact with smart contracts
• Build transactions
• Manage validators
• Scaffold dApp repository (contracts and frontend)

CosmWasm

The Cosmos ecosystem is quite similar to the Polkadot ecosystem in the sense that it has a core SDK for building a modular blockchain with interoperability in mind. CosmWasm is a module for the Cosmos SDK that adds smart contract functionality to the Cosmos ecosystem. One famous network that uses this is Terra. Currently, CosmWasm only officially supports Rust smart contracts, but because the core module is made using Go, we can imagine expanded language support in the future.

Because CosmWasm is a module of the Cosmos SDK, there is a main CosmWasm developer document and multiple smaller documents that are maintained by the Cosmos ecosystem projects that use the CosmWasm module.

For example, the Terra Academy (https://academy.terra.money) is the main source for learning hands-on development using Rust and developing a smart contract with CosmWasm. And the main Terra document only contains the developer reference for the CosmWasm smart contract.

Most of the developer documentation can be found on the main CosmWasm document page (https://docs.cosmwasm.com). However, CosmWasm is not a sovereign blockchain, most new developers will start their journey from documents that are maintained by projects that are using the CosmWasm module, and then will eventually refer to the main document for details.

CosmWasm has its own JavaScript API called the CosmJs, and terra.js which is made for interacting with WASM smart contracts on the Terra Network.

Unlike the other networks, CosmWasm does not have a dedicated all-in-one CLI tool, instead, it uses cargo to compile the Rust smart contract, and the Go CLI called wasmd to deploy and interact with it from the terminal. However, there are a lot of manual configurations and prerequisites for setting up the developer environment for CosmWasm. That is why Terra has an all-in-one CLI tool called the Terrain. Terrain can do the following:

• Account management
• Network management
• Scaffold dApp repository (contracts and frontend)
• Testing
• Deploy smart contract
• Interact with contracts
• Client script framework

Polkadot/Substrate

The Polkadot ecosystem also has an interesting structure as the Polkadot network itself does not support smart contracts. Instead, blockchains that are built with Substrate (the equivalent to a Polkadot SDK) can implement a runtime module called the Contract Pallet. This pallet will allow any blockchains that implement it to execute WASM smart contracts. Currently, it supports ink (an eDSL of Rust) and there are works to support an eDSL of AssemblyScript.

Substrate WASM contract documentation is quite messy and spread out instead of having a single source as Substrate treats the contract pallet, the WASM contract language (ink), and the JavaScript API as a separate project.

Substrate node developers can learn about the contract pallet through the official Substrate developer document https://docs.substrate.io/v3/runtime/smart-contracts/ and on their workshop https://docs.substrate.io/tutorials/v3/ink-workshop/pt1/.

New developers wishing to build on the Polkadot ecosystem may start from the official Polkadot documentation https://wiki.polkadot.network/docs/build-smart-contracts.

But ultimately, they will have to read the detailed development guidelines from the official ink document (https://ink.substrate.io/), or from the individual parachain’s developer documents like the one Astar Network provides https://docs.astar.network/wasm-smart-contracts/smart-contract-development).

Perhaps the most comprehensive and mature WASM smart contract developer documentation for the Polkadot/Substrate ecosystem might be OpenBrush maintained by SuperColony. For general WASM contract development with ink, this is the best source.

Polkadot/Substrate also has a JavaScript API called the @polkadot/api, which also has its own documentation. Because the smart contract API is part of the Polkadot API package, the documentation is kept here, maintained by the Polkadot.js team.

As you can see, there is no single go-to documentation for developing WASM smart contracts on the Polkadot/Substrate ecosystem like the other projects, and because the contract pallet, the language compiler, and the JavaScript API for interacting with the contract are treated as separate projects, the documents are kept separately without a single source where new developers can see everything at a glance.

For the CLI tool, Polkadot/Substrate does not have an all-in-one tool or a standard developer environment for building smart contracts like Terrain, Near CLI, or Solana CLI. Instead, the tools are split into the Substrate node management tool and the language compiler tool. Although there was a tool called Redspot that streamlines the node setup and account management process for smart contract developers, this tool is no longer maintained.

The Substrate CLI provides:

• Account management
• Signer utility
• Node management
• Network management

And the ink contract compiler CLI (also known as the cargo contract provides:

• Build contract
• Deploy contract
• Run unit tests
• Interact with the smart contract
• Decode contract data

The ecosystem at a glance

Now we’ve explored what the WASM contract ecosystem has to provide, let’s compare and contrast these networks.

As you can see, it is much easier for a single blockchain network to provide a unified developer environment and documentation, making it easy for new developers to understand everything at a glance. On the other hand, blockchain frameworks and layer 0 chains like Cosmos and Polkadot/Substrate have a hard time creating a unified developer environment and CLI tools as it could put a bias in certain networks. That is why it is natural for the blockchain that is built on top of that framework to provide the documentation and tools like how Terra does. Although the CosmWasm is much more unified than how Substrate handles it since CosmWasm treats the language, contract module, and the JavaScript API as part of the single project, rather than separate everything like Substrate.

Let’s look at the tool support now.

It’s clear that blockchains like Near and Solana provide more integrated all-in-one tools for developers, while the Cosmos ecosystem with CosmWasm only provides basic features and relies on its ecosystem projects like Terra to create a fully integrated environment alongside its existing tools. On the other hand, Substrate CLI tools are very scattered as the developer must first set up a local contract node as the deploy target, and although we have the cargo contract, the Substrate ecosystem expects to see more smart contract languages like ask, having a CLI tool that is made specifically made for a single language will make it difficult for future language adoption.

Making WASM Swanky Again 😎

As you can see from the previous sections, although the WASM contract ecosystem is still new, there are many high-profile projects that are really pushing this technology for mass adoption. But the progress for the Substrate ecosystem still seems lagging and disorganized even though the underlying technology is on par if not better.

That is where we come in. Astar Network aims to push the Substrate WASM ecosystem for all future dApps who wish to leverage the interoperability of Astar Network.

To do this, we, at Astar Network, will focus on unifying the developer documentation who starts their developer journey from Astar Network, increase developer education, incubate and provide grants for new and innovative WASM dApps, and most importantly, create the Swanky CLI.

Swanky CLI is an all-in-one CLI tool for Substrate WASM contract developers that our ecosystem needs the most.

This tool is still under heavy development, but we plan to support various features like:

• Unit-testing
• Contract interaction
• Deploying
• Account management
• Developer node setup

By the end of June, and in the future, we will add:

• Integration tests
• Scaffolding for both front-end apps and contracts
• and much more

Because the codebase is made with modularity in mind, Swanky will add support for multiple smart contract languages as more projects join to expand the ecosystem. We are excited to be part of the future of smart contracts.

And this is the end of the hitchhiker’s guide to the WASM smart contract developer ecosystem.

Thank you.