Smart Contract Language Runtimes

May 22, 2022

Language runtimes are fun again.

Where can a language run? It's not a question of Linux vs. Windows anymore. Can it run in the browser (WebAssembly)? Can it run in the kernel (BPF)? Does it support x86 and ARM? Can you embed it in another language?

Other important questions: How can it be packed into a container? What security boundaries does the runtime provide?

First, what is a language runtime? You can think of the language runtime as the environment in which a program is executed. Everything from how the program manages memory, garbage collection (or not), interfaces with the operating system, and generally manages the stack, heap, threads, etc. The language runtime might also include code generation, debugging tools, or type checking.

Smart contract language runtimes have some requirements.

  • Auditable and correct within reason. Programmers have used language runtimes like Python and Java for decades, but they have enormous API surfaces. You can do practically anything in these languages (network calls, infinite loops, etc.).
  • Embeddable or having few dependencies. Decentralized systems require every node to execute the runtime. Needing specific hardware or configurations would stunt adoption.
  • Small code size. Block space is expensive on popular blockchains. Since all the programs (and their state) are stored on-chain, they need to be small and efficient.
  • Deterministic

Solana (rBPF)

Solana uses rBPF, a user-space virtual machine for eBPF (see A Short Primer on eBPF). Solana's programs compile with the LLVM toolchain to ELF binaries. This means that smart contracts can be written in languages like Rust and C/C++.

eBPF runs with an additional verifier step in the kernel, which provides extra safety (like doing a DAG check and removing loops). Solana's implementation doesn't use the verifier step but adds in its metering and limiting. Nevertheless, eBPF itself has a small and hardened surface.

Ethereum (EVM, eWASM)

Ethereum has a custom stack-based virtual machine (the Ethereum Virtual Machine, EVM). Several higher-level languages compile to EVM bytecode (Solidity, Vyper, Yul/Yul+, FE).

Ethereum 2.0 will support an Ethereum-flavored WebAssembly (eWASM) in addition to the EVM (see my short primer on WebAssembly). eWASM has been a long time coming; the initial proposal was back in 2015. Backward compatibility with the current EVM will be complex. Not to mention that WebAssembly is a moving target in itself (the standard and tooling are rapidly evolving). It's unclear what the current state of the proposal is.

Like Solana, there are numerous restrictions to what could be compiled to eWASM – no non-deterministic behavior, no or limited floating-point math.

Cardano (Haskell, DSL**)**

Cardano smart contracts are written in either Plutus (Haskell-based language) or Marlowe (DSL embedded into JavaScript or Haskell). See the description here.

IOTA (WASM)

IOTA currently supports two VMs: a WASM one (based on Wasmtime) and the EVM. Unfortunately, I couldn't find many examples of IOTA smart contracts in the wild besides this folder of samples – you can see some WASM contracts here.

You can see a description of the implementation here.

Bitcoin (Scripting)

Bitcoin contains a limited, non-Turing complete scripting language. The language is procedural and stack-based (similar to Forth).