Move: Sui, Aptos, and the Resource Model

In June 2023, Sui processed a transaction in 390 milliseconds. Not confirmed - finalized. By comparison, Ethereum at that same moment required 12-15 minutes for finality. A 2000x difference - this is not a hardware boost. Behind it stands a programming language in which a coin cannot be copied, a token cannot be lost, and the compiler mathematically proves the correctness of a contract. That language is Move, and it reimagines the very idea of what it means to "own" a digital asset.

• **DeFi on Sui (Cetus, Turbos)** - AMM pools are implemented as shared objects, and liquidity positions as owned objects. Thanks to this, adding/removing liquidity bypasses consensus (~400ms), while swaps go through fast Narwhal+Bullshark
• **Aptos Labs + Microsoft** - Aptos uses Move and Block-STM for enterprise solutions: digital assets with formal verification (Move Prover proves that a balance cannot go negative for all possible inputs)
• **The DAO reentrancy attack ($60M, 2016)** - would have been impossible in Move: no dynamic dispatch, a resource cannot be used twice, and Move Prover would have detected the balance invariant violation before deployment

Предварительные знания

• EVM: Ethereum Virtual Machine

The Move Language: From Diem to Sui and Aptos

In 2019, Facebook (now Meta) was developing a blockchain called **Libra** (later renamed **Diem**) for global payments. Engineers studied all known Solidity vulnerabilities - reentrancy, integer overflow, implicit token copying - and reached a radical conclusion: **the problem is not programmers, it is the language**. This was the birth of **Move** - a language where entire classes of bugs are impossible by design.

The Diem project shut down in 2022 under regulatory pressure, but Move survived. Two teams of former Facebook engineers founded separate blockchains: **Aptos** (Avery Ching, Mo Shaikh) and **Sui** (Evan Cheng, Sam Blackshear - the creator of Move). Both blockchains launched on mainnet in 2023.

Move is a **statically typed language with a module system**. Code is organized into packages, each package contains modules, and modules define struct types and functions. Unlike Solidity, where a contract is both code and data, in Move **code (module) and data (resources) are separated**.

Let's compare Move and Solidity's approaches to fundamental security:

**Move Prover** is a built-in formal verification tool. The developer describes a *specification* (invariants, pre/post-conditions), and the Prover mathematically proves that the code satisfies them. This is not testing - it is a **proof of correctness** for all possible inputs.

Resources: Assets as Types

In Solidity, a token is an **entry in a mapping**: `mapping(address => uint256) balances`. To "send" a token, you subtract a number from one cell and add it to another. But what if a bug allows adding without subtracting? Or subtracting twice? An ERC-20 contract is just a ledger, and all security rests on the correctness of the arithmetic.

Move takes a radically different approach. A **resource** is a data type that **cannot be copied and cannot be implicitly destroyed**. A coin in Move is not a number in a table but an object that can only be moved from one owner to another. Like a physical banknote: if I give it to you, I no longer have it.

To work with resources, Move provides special operations. Each controls **ownership and access**:

Let's compare how ERC-20 and Move Coin handle the double-spend problem:

In Move it is impossible to "forget" a resource. If a function receives a `Coin` and does not move it somewhere (transfer, deposit, destructuring) - **the code will not compile**. The compiler tracks every resource and requires explicit handling. It is as if the C++ compiler would not allow forgetting `free()` - but at the type level, not at runtime.

Linear Types and the Abilities System

Resources in Move are not magic - they follow from a fundamental theory in computer science. **Linear types** are a concept from linear logic (Jean-Yves Girard, 1987), where every value must be used **exactly once**. No more (copying), no less (destroying without use).

Strictly speaking, Move uses not linear but **affine types**. The difference: a linear type must be used exactly once, an affine type - *at most* once. This means that in Move a resource can be destroyed (via destructuring), but not copied. Affine types are also used in Rust (the ownership system).

Instead of a single notion of "resource", Move uses a flexible **abilities system** - four permissions that define the behavior of a type. Each struct receives only the abilities that are explicitly declared:

The abilities system lets the compiler catch entire classes of Solidity bugs at compile time:

Sui and Aptos implement Move differently. **Aptos** uses **global storage** - resources are tied to account addresses (`move_to`, `move_from`, `borrow_global`). **Sui** uses an **object-centric model** - each object has a globally unique ID and can be owned (belongs to an address), shared (accessible to all), or immutable (read-only).

Parallel Transaction Execution

Ethereum processes transactions **strictly sequentially**: each one sees the result of the previous one. This guarantees correctness but sets a hard ceiling on performance - ~15-30 TPS. Why can't transactions simply be run in parallel? Because two transactions may read and write the same data (storage slots), and parallel execution would produce unpredictable results.

Move blockchains solve this problem in two different ways. **Sui** uses an object model where ownership determines parallelism upfront. **Aptos** uses optimistic parallel execution. Both approaches deliver an order of magnitude more throughput than Ethereum.

**Block-STM** (Software Transactional Memory) is an algorithm developed by the Aptos team. It is inspired by the STM concept from Haskell and databases (MVCC in PostgreSQL). The key idea: execute transactions in parallel optimistically, then detect and re-execute conflicting ones.

**Sui** uses a fundamentally different approach: an **object-centric model with DAG execution**. If a transaction operates only on objects belonging to a single owner (owned objects), Sui can process it **without consensus** - via Byzantine Consistent Broadcast. This eliminates the latency of ordering.

Let's compare parallelism approaches across four blockchains:

TPS figures from benchmarks should be read with caution. Aptos and Sui show hundreds of thousands of TPS under lab conditions (simple transfers, ideal network). In real mainnet with DeFi transactions that work with shared objects, the numbers are an order of magnitude lower. Nevertheless, even a real-world 5,000-12,000 TPS is two orders of magnitude above Ethereum.

The connection between the resource model and parallelism is not coincidental. Precisely because Move directly defines **ownership** of each object, Sui can statically determine which transactions are independent. And abilities (the absence of `copy`) guarantee that an object will not appear in an unexpected place. The Move type system is the foundation on which all parallelism is built.

Key Takeaways

• **Move is a language with a resource model**, created for safe smart contracts. Reentrancy, integer overflow, and double-spend are impossible by language design, not thanks to careful programmers
• **Resources cannot be copied or lost** - the compiler tracks every resource and requires explicit handling. A coin in Move is not a number in a mapping but a movable object with type-level guarantees
• **The abilities system (copy, drop, store, key)** provides flexible control: a Coin without copy/drop is protected from duplication and loss; a Config with the full set of abilities behaves like a regular data structure
• **Parallel execution** became possible precisely because of the resource model: Sui determines conflicts by object ownership (owned vs shared), Aptos uses optimistic Block-STM with re-execution of conflicting transactions
• Returning to Sui's speed: 390ms finality is not just a good network - it is a direct consequence of Move making ownership explicit, and ~90% of transactions (working with owned objects) require no full consensus

Related Topics

Move blockchains stand at the intersection of programming language theory, virtual machines, and consensus algorithms:

• EVM: Ethereum Virtual Machine — Move was designed as a response to EVM limitations: the absence of resource types and sequential execution - problems Move solves at the language level
• Solana: Sealevel and Parallel Execution — Solana solves the parallelism problem through declarative access lists (Sealevel), while Sui uses the object model and Aptos uses optimistic Block-STM
• Solidity: Language Basics — Move and Solidity represent two polar approaches: Solidity provides freedom (dynamic dispatch, arbitrary storage writes), Move restricts for safety (static calls, resource types)
• HotStuff: BFT Consensus — Aptos uses DiemBFT (based on HotStuff) for consensus, while Sui uses Narwhal+Bullshark (DAG-based BFT), both are developments of HotStuff ideas

Вопросы для размышления

• Move makes many types of bugs impossible (reentrancy, double-spend), but at the cost of greater strictness. What kinds of applications are easier to write in Solidity, and does that justify the additional risk?
• Sui divides transactions into "fast" (owned objects, no consensus) and "slow" (shared objects, with consensus). How does this affect the design of DeFi protocols - should shared object usage be minimized?
• The abilities system in Move is similar to ownership in Rust. If Solidity v2 added affine types, would it solve the security problems, or does Ethereum also need to change the virtual machine?

Связанные уроки

• comp-01-intro