Project Jump Cannon: Choosing WASM

In previous episodes we outlined the reasoning for working on native Stellar smart contracts now. The Stellar ecosystem is in an advantageous position to implement smart contracts: learning from the research that has already been done; marching forward equipped with a diverse toolbox; and implementing Stellar smart contracts in a way that is true to the things that make Stellar what it is: safe, scalable and promotes equitable access.

One of the first major decisions to make in building a smart contracts platform in 2022 is choosing a smart contract platform. This post is going to walk you through the decision-making process, the options we considered, and the pros and cons of each. But if you’re just here for the grand finale…

TL;DR: Project Jump Cannon is being built on a WebAssembly (WASM) runtime.

For those of you sticking around to learn how and why we chose WASM, let’s carry on.

Over the past couple of months, an SDF team has focused on surveying the current smart contracts landscape. We want to use the most appropriate technology and learn from the broader cryptocurrency ecosystem. Our team has created a stack selection doc with our selection criteria and a thorough comparison of existing technologies. If you’re interested in all the nitty gritty details, check out that doc! This blog post is a lightweight version of it.

First, what do we mean when we say “smart contracts stack”? Well, a lot. But here’s a condensed version with four components

1. The Virtual Machine (VM): This executes bytecode instructions in a sandbox environment. It doesn’t really know anything about the blockchain.
2. The Blockchain Runtime services: These connect the virtual machine with the blockchain: ledger storage, gas metering, etc.
3. The Language toolchain: This allows developers to write contracts in a “human readable” language like Rust or Solidity.
4. Contract Development SDKs: These ease the development process by providing libraries, documentation, a testing sandbox, and more.

In a perfect world we’d pick a technology off-the-shelf that covers the entire smart contracts stack. That might not be realistic, given the differences between blockchain protocols and implementations. With that said, at minimum, we’d like to choose an existing Virtual Machine and a programming language – these are well-researched fields, and even though our team includes language creators, we don’t need to reinvent the wheel.

We considered the following criteria to evaluate the technology options:

1. First and foremost we asked ourselves: is it “capable” enough? If the technology can’t facilitate the type of smart contracts we’re looking for, it’s a non-starter.
2. We then looked at various aspects of the design: does the storage model promote long-term accountability for state and a manageable ledger size? Do transactions lend themselves well to concurrency by partitioning? How are developer ergonomics? That’s a bit subjective, but we want to make sure the development experience isn’t too “weird.”
3. We analyzed the existing implementation(s) for performance, maturity, and how tied up they are to a specific blockchain and execution environment.
4. Lastly, we looked at the maturity of the ecosystem: how many existing contracts, developers, and developer resources exist?

These are the lenses we examined the options through. There’s a lot of smart contract tech out there. Here are some of the noteworthy options we looked into and our general take on each.

The Ethereum Virtual Machine (EVM) is the elephant in the room. It was developed alongside Ethereum and is driving the majority of activity in the DeFi space. It is most commonly used alongside the Solidity programming language but others, such as Vyper, exist. The EVM is also used in a variety of other networks such as Avalanche, Celo, Fantom, and others.

It’s by far the most popular smart contracts stack. It’s mature and has an abundance of developer resources, tools, and best practices available. However, its storage and execution models are expensive and challenging to parallelize. This makes the validator software less accessible and gets in the way of scalability. In addition, having been built specifically for Ethereum makes EVM adoption in existing networks extremely challenging.

Move is a smart contracts stack designed by and for the Diem blockchain. The stack includes a virtual machine, programming language toolchain, a dedicated prover, and other dev tools.

Move is carefully designed from the ground up as a comprehensive blockchain tech stack. It gets a lot of things right, including a one-of-a-kind verification language and prover that were built alongside the language. On the flip side, it’s fairly immature (still a work in progress, no significant ecosystem) and the current executor is very slow. In addition, the Move storage model presents a programming model that developers struggle to grasp.

WASM is a bytecode specification created for running sandboxed applications in a browser.

It’s used by various chains in different configurations: Polkadot, Terra, Near, Elrond, Dfinity, etc. It is most commonly used with the Rust programming language, but there are others.

WASM lends itself well to smart contracts as it was designed to operate in an environment that, much like a blockchain, is extremely adversarial: the web. As a VM, WASM presents the widest set of possible source languages, toolchains, interpreters and JITs, and presents the best performance and lowest degree of coupling to a specific blockchain’s semantics. However, it leaves open the problem of designing “the rest of the stack” – blockchain agnostic and specific runtime services, as well as source language APIs/SDKs and/or special bindings/domain specific languages. There are several chains to study and learn from, but none fits Stellar well enough to adopt unchanged.

Interestingly, the Ethereum community has been advocating for using WASM in Ethereum as early as 2015. The Ethereum Foundation has also developed eWASM: a restricted subset of WASM to be used in Ethereum 2.0. With the changing definitions of Ethereum 2.0 throughout the years, it’s unclear whether eWASM will ever be implemented in Ethereum. However, this suggests possible re-encounter between the WASM stack and the Ethereum ecosystem down the road.

eBPF is a bytecode specification with multiple VM implementations. Originally created for running sandboxed programs in an OS kernel. In the blockchain space, it is only used by Solana who use a modified version of the rBPF implementation. The main contract language for Solana is Rust, although many can theoretically be used. Solana transactions declare dependencies which allows the runtime to partition blocks and execute concurrently on multiple cores.

eBPF for smart contracts is a fairly unique choice, and Solana makes many bold claims about it. However, the real benefits are unclear. eBPF as a VM is substantially similar to WASM as a target for multiple languages through native toolchains, but the support is worse and the maintenance burden is higher. One major difference is that eBPF interpreters typically optimize for low latency startup, but increasingly, this is the case with newer fast WASM interpreters anyway. Solana’s concurrency and storage models are more promising as design inputs to our own efforts, but present safety and performance hazards significant enough not to adopt unchanged.

There are many more smart contract options! Some of them are blockchain-dependent, some rely on a UTXO model and some are just ... fringe. We’re keeping an eye on these but this blog post is getting a bit too long.

So back to the bottom line — we’re focusing on WASM for Project Jump Cannon. We believe it provides a robust execution environment for smart contracts, has a thriving ecosystem and can be used to build a system that is safe, scalable and promotes equitable access.

With that said, many questions remain:

• Which WASM implementation to use?
• Which source language(s) to support?
• What is the contract storage model?
• What is the contract parallelism model?
• What is the interoperability story with the existing Stellar protocol?
• … and many more!

Stay tuned, as we answer all the above!