1 of 25

Move: A Safe, Cross-Platform Language for Programming With Assets

Sam Blackshear

Working on Sui blockchain + Move @ Mysten Labs

Joint work with collaborators at Mysten, Aptos, Meta, Stanford, Waterloo, 0L, StarCoin

2 of 25

Agenda

Why crypto needs a safe, asset-oriented language
Introduction to Move, a cross-platform attempt at this

3 of 25

Smart contract safety is an existential threat to broader crypto adoption

$10M+ hacks are routine
No reason to expect that future smart contract devs can do better…
… so languages + tooling must improve significantly.
Safer SC languages, advanced testing/analysis/verification tools are the only way to grow the dev community in a sustainable way

4 of 25

What is a smart contract language, and how does it fit into a blockchain?

5 of 25

Blockchain = replicated state machine

Replicas (“validators”) must agree on State 0 (“genesis”), tx order (“consensus”), and function f(State, Transaction) -> State

6 of 25

How does a language fit into a blockchain?

Smart contract =

executable code inside state

Tx = main() + args

f = language semantics

7 of 25

Must-have properties of a smart contract language

Deterministic

Otherwise, validators may not agree

Type and memory-safe at executable level

Adversarial environment: code directly callable by attackers

Metered execution (i.e. “gas”)

Otherwise, transactions may run indefinitely and stall the system

No conventional language has all three.

8 of 25

Smart contracts are unconventional programs

Smart contracts really only do three things:

Define new asset types
Read, write, and transfer assets
Check access control policies

Thus, need language support for

Safe abstractions for custom assets, ownership, access control
Strong isolation–writing safe open-source code that interacts directly with untrusted code written by motivated attackers

Not common tasks in conventional languages

Not supported well by existing SC languages

9 of 25

In other smart contract langs, you typically cannot:

Pass asset as an argument to a function, or return one from a function
Store an asset in a data structure
Let a callee function temporarily borrow an asset
Declare an asset type in contract 1 that is used by contract 2

Building large systems by composing type-based abstractions is not possible

Take an asset outside of the contract that created it

“Trapped” forever in a hash table inside its defining contract

Assets, ownership are the fundamental building blocks of smart contracts, but there’s no vocabulary for describing them!

10 of 25

Opinion: Solidity/EVM network effects over-emphasized

Small (~5k) dev community [1] relative to conventional langs (e.g., ~16M JS devs)
Not too late to establish safer, cross-platform industry standard

[1] https://medium.com/electric-capital/electric-capital-developer-report-2021-f37874efea6d

11 of 25

Agenda

Why crypto needs a safe, asset-oriented language
Introduction to Move, a cross-platform attempt at this

12 of 25

Assets encoded via Rust-like ownership types

“If you give me a coin, I will give you a car title”

“If you show me your title and pay a fee, I will give you a car registration”

CarTitle, CarRegistration, Coin are user-defined types declared in different modules.

Type can flow across trust boundaries without losing integrity

13 of 25

Type system prevents misuse of asset values

Destruction

“Double-spending”

Duplication

Protection against:

Ensures that digital assets behave like physical ones

Enforced by both compiler and JVM-style bytecode verifier

14 of 25

Struct abilities let programmers create linear types, affine types, and more

15 of 25

Move design optimizes for safety + predictability

No dynamic dispatch (no re-entrancy)
No mixing of aliasing and mutability (like Rust)
Type/memory/resource safety enforced by JVM/CLR-like bytecode verifier
Robust safety via strong encapsulation primitives
All-or-nothing semantics, no partial reverts
Mathematically ill-defined ops (e.g., int overflow) abort: “SafeMath by default”

16 of 25

Co-developed with Move Prover verification tool

Prover engine based on bytecode rewriting, Boogie + Z3/CV4

Much more detail in David’s talk

Runs directly on the executable bytecode language, minimizes trust in compiler
Specification language integrated with source language
Prover integrated with Move CLI

17 of 25

Prover aims at fast, precise, accessible verification

Fast/stable enough to run in both locally and in CI

Runs in CI for Move repo, repos of Move-powered blockchains

Move stdlib is thoroughly specified and verified

Community contributors are able to verify code, not just experts!

18 of 25

Platform-specific SC languages frustrate platform experimentation

Existing smart contract languages: ~1 language per blockchain
Languages hardcode account/transaction format, serialization format, cryptography, blocks, …
If I want to create a new blockchain platform, I have two (bad) choices:

Reuse old language (e.g. EVM) in new platform = inherit design decisions, limitations of the original platform
Use new language = new dev community, toolchain, libraries, …

19 of 25

Move is platform-agnostic

Move bytecode language is intentionally minimal, not “blockchain-y”
Platform designers can experiment with different choices for transactions, accounts, storage, etc.

And extend core functionality with new native functions and VM extensions

Programmers can reuse expertise, tooling, libraries across platforms
Used in 4 blockchains that are very different under the hood:

Sui, Aptos, 0L, StarCoin
… and lots of interest from existing + emerging chains (Solana, Avalanche, Celestia, …)

Vision: Move is the WASM of web3

20 of 25

Conclusion

Move provides safe, convenient abstractions for programming with assets
Move is platform agnostic and used by four blockchains, more coming in the future
Move is a great playground for program analysis research without the typical barriers:

Mixing aliasing and mutability
Dynamic dispatch
Reflection
Concurrency

Move community needs more contributors, auditors, researchers, static analyzers, verifiers, fuzzers, testing tools, …

https://github.com/move-language/move

https://github.com/MystenLabs/awesome-move

https://move-language.github.io/move/

https://move-book.com/

21 of 25

Example: flash loans

On Eth-like platform, would implement flash loan standard like EIP3156
In Move, use abilities and generics!

22 of 25

Leveraging linearity with “hot potato” objects

Key idea: give the borrower a Receipt with the amount of the loan
Only way to destroy Receipt object is calling repay()
Code that doesn’t do this won’t even compile