Arbitrum recently announced Stylus VM upgrade. It claims to have the following feature:

Support more languages
Lower fee, lower memory consumption
Custom pre-compilers
Interoperability with EVM

All these features are brought by the integration of WASM. WASM has lots of advantages and is widely used in the cloud native scenario. We will expand the story of WASM in the later sections.

Pioneers

Arbitrum is not the first one to bring WASM on-chain. Before Arbitrum, Polkadot enabled users to write WASM smart contracts. It provides two languages to write WASM smart contracts, one assembly scripts like embedding DSL and another is Rust-like language ink!.

Cosmos also employs CosmWasm as its smart contract runtime. Developer's can use Rust to write smart contracts.

Before diving deep into why blockchain ❤️ WASM, let's see how Cosmos and Polkadot explains their choice to WASM.

Cosmos claims WASM can bring the following benefits:

Compatible with Rust libraries
Diverse dev community
Security, prevent reentrancy attacks
Easy test
High performance

Polkadot’s WASM runtime has the following features:

High performance
Interoperability with EVM
Platform agnostic
Small size
Support Rust and Assembly Script(Typescript style)

There are some advantages shared across Polkadot, Cosmos and Arbitrum brought by WASM, but there is something unique for Arbitrum. We will cover more details about Arbitrum and Cosmos in the last part.

WASM

What is WASM

To understand why blockchain x WASM, we need to understand what is WASM and the initiative behind WASM.

WebAssembly (WASM) is a binary format that allows code to run at near-native speed in web browsers. It's a compilation target for languages like C and Rust, designed to be fast, efficient, and secure. WASM bridges the gap between web and system-level programming, enhancing web performance and capabilities.

WASM get name Web because it can run in JS, commonly browser environment. In JS, developers can access full WASM API. WASM also got full Web API supports. In WASM, developers can control the Web behavior.

WASM History

WASM is designed with the principle of writing once and running anywhere.

Back in 2016, lots of programs released new functions through Domain Specific Language(DSL). Making a DSL needs to make tradeoff between maintenance, efficiency and safety. However people are looking for a new way to deliver new functions to countless servers which needs maintenance, efficiency and safety.

They examine different solutions from top to bottom. Here are people’s concerns about these solutions:

System Virtual Machines
- Too much overhead for spinning up/down frequently
- Lack visibility into code for ensuring safety
- Too abstracted/high level for the performance needs
Containers
- Lack of visibility into code for ensuring safety
- Too high level/abstracted for performance needs
- much overhead for spinning up/down frequently
Language-level virtual machine
- Frequent VM modifications required for safety
- Overhead of embedding VMs like V8
- Slow to adapt new languages to the VM's security model
- Still high level
Instruction set architectures (ISAs)
- Very difficult to modify ISA code for sandboxing efficiently
- Prior project at Google moved away from it to WASM
- Lacked mature implementations to use

This is the background for WASM to be true. People start to develop WASM compiler till 2018. WASM developers expand the idea of write once and run anywhere. They would like to run on different architectures, run in servers and embedded hardware, even other languages. They don’t want to make another Java, which sacrifices safety.

In 2019, the component model was created to wrap WASM modules and raise their interfaces to a higher level, enabling cross-language interoperability between components. For example, this allowed them to write an HTTP library once and share it across languages. The component model solved long-standing problems in a novel way.

Till know, WASM has lots of cool features. WASM now is heavily used in the cloud native scenario. Blockchain somehow is also one use case under cloud native. WASM has following advantages:

High performance
Low binary size
Portability: WASM provides portability at the instruction set level, allowing the same bytecode to run across any WASM runtime.
Support C/C++, Rust, AssemblyScript, C#, Dart, F#, Go, Kotlin, Swift. D, ascal, Zig, Grain
Run in JS engine
Sandbox: WASM provides a much stronger sandbox by default, with limitations on memory, CPU, etc. to prevent access outside of its sandbox.
WASM has very fast startup, often milliseconds or less.

The WASM community is still working hard to bring more integration and cross-language performance.

Stylus

After thinking about the initiative of WASM and WASM applications on other blockchains, let’s go back and think about Arbitrum Stylus’s limitation.

How Stylus works

The developer compiles their smart contract to WASM using an off-the-shelf WASM compiler like Clang or Rustc.
The WASM bytecode is uploaded to the Arbitrum chain in compressed form.
The contract owner calls the compileProgram method of the ArbWasm precompile, which instruments the WASM for security, meters it for gas costs, and compiles it to native code optimized for the validator's hardware.
When the contract is called, it runs on a WASM runtime like Wasmer much faster than the EVM, saving gas costs.

The third steps looks extra, but it is necessary to build for performance and security reason. Compile WASM code to native machine code can speed up the execution. Adding extra compilation step can also avoid compile bomb.

A "compile bomb" is a type of malicious code that is designed to consume excessive resources during the compilation process, causing the compiler to crash or hang. It is a form of denial-of-service attack that can be used to disrupt software development processes.

Popular concern about Stylus

Language Support

Stylus can help Arbitrum to expand their dev community to C++ and Rust while it still cannot reach the most popular dev community nowadays. It opens up the door for smart contracts executed in the browser environment, but JS and Python is still not supported.

There are early stage projects bring Python and JS to WASM, but it is not ready for massive adoptions because of garbage collection objects implementation and performance issue.

Language Compatibility

Stylus current supports C/C++ and Rust SDK. It works well with these languages tools. Developers can also bring some third party libraries, like some native cryptography implementation while building smart contracts. The only limit for these is gas cost.

The Rust SDK is still in the early stage. There are some missing features for Rust and C SDK. C SDK does not support ABI export function. Modifiers are not supported in both SDK.

Local Stylus test environment is not supported yet, but developers can directly run test in SDKs. To run smart contracts in Stylus, testnet is the only way. Smart contract verification is not supported by the testnet yet.

People is bringing differet ERC token and Uniswap V2 to Stylus.

Language Choice

Use DSL, embedding DSL or general programming language is a hard choice. Developers need to make tradeoff between building close to the metal for control or higher level abstractions that are easier to use but limit flexibility.

Building a brand new DSL also takes time to develop toolchains and ecosystem. eDSL is a sublanguage of a general programming language, sharing same semantics and syntax. With eDSL, it can leverage existing language and tools, lower learning curve compared learning a new DSL, good Interoperability between DSL and general purpose code. For example, for reaching the most developers, making a JS, Python eDSL make sense. General programming languages require developers to use SDK to make development. This introduces extra tooling, more verbosity, less expressiveness and length API call and object operations.

Picking a right language and make an eDSL may be a right mix. It attracts people from popular dev community and provide easy-to-use tools. From the data below, we see the top crypto developer community is still Ethereum. Polkadot, Cosmos and Solana, which use Rust for smart contract also attract well amount of people. They also have a really fast growing speed on total developers

Performance

WASM can greatly increase the execution speed and decrease the bundle size. Although Stylus is not on mainnet yet, we can see benchmark on other network as reference.

The execution time is shorten 4-8x. The compiled size is reduced by 2x.

There is currently a limit on the size of Stylus contracts, around 128KB uncompressed. It will be difficult to port very large smart contracts from other languages like Solidity. You can find in the Stylus codebase.

// arbos/programs/programs.go

const MaxWasmSize = 128 * 1024
const initialFreePages = 2
const initialPageGas = 1000
const initialPageRamp = 620674314 // targets 8MB costing 32 million gas, minus the linear term
const initialPageLimit = 128      // reject wasms with memories larger than 8MB
const initialInkPrice = 10000     // 1 evm gas buys 10k ink
const initialCallScalar = 8

Notice that WASM has some overhead on spinning on and off. If you are coding something really light, EVM may be cheaper than WASM.

Interoperability with EVM

EVM and WASM shares the same storage slots and state tire. Stylus has interoperability with EVM because there are EVM API implemented in WASM. This is done through the popular Host I/O mode in WASM. Here is a full supported list for EVM API in WASM. It looks like the interoperability is fully supported.

read_args
write_result
storage_load_bytes32
storage_store_bytes32
call_contract
delegate_call_contract
static_call_contract
do_call
create1
create2
do_create
read_return_data
return_data_size
emit_log
account_balance
account_codehash
evm_gas_left
evm_ink_left
block_basefee
block_coinbase
block_gas_limit
block_number
block_timestamp
chainid
contract_address
msg_reentrant
msg_sender
msg_value
native_keccak256
tx_gas_price
tx_ink_price
tx_prigin
memoery_grow
console_log_text
console_log
console_tee

Custom Precompiles

This one is more exciting. Noone has done this before. We can bring more crypto primitives on-chain with a much lower execution cost. For on-chain ML, we can bring tensor computation as precompiles to lower the inference cost. However, I do not see any relevant code about custom precompiles. We see the precompiles for the EVM part, but is not hot swappable.

I believe these part are stilling implemented with the power of WASM. EVM can call functions written in WASM which can be compiled down to machine code.

Reentrant

Unlike CosmWasm which uses an actor model to provide contract call and does not provide reentrant functionality, Stylus Rust SDK set reentry as a feature flag and it is default set as off. Developers can manually enable the reentry functionality.

Introducing reentrancy with the default feature flags on will change the API a bit, since developers have to be careful to flush the storage cache when making calls, among other safety considerations.

Conclusion

WASM is an emerging technology gaining traction in the cloud-native space. Numerous blockchains are integrating WASM for their smart contract runtimes. While Arbitrum is not the first to do so, it could be the most significant. WASM cannot completely change the blockchain world and substitute EVM, but WASM has the potential to enhance Arbitrum's competitiveness against upcoming zk-rollups. I like how Arbitrum call this EVM+. EVM is the floor for smart contract runtime and WASM can bring some extra power for Arbitrum.