◈
Storage Model
Sui
Object Model + Sparse Merkle Tree

In Sui, everything is an object with a unique ID. Objects have owners. Owned-object transactions skip consensus entirely — enabling massive parallelism. Built on Move language for type-safe assets.

Object Ownership — The Key to Parallelism

Description

Only one address can read/write this object. Most NFTs, tokens.

Parallel Execution
✅ Full parallel
Consensus Required
No consensus needed

Object Structure

object-model.rsrust
1// Sui Object Model — Everything is an Object
2// Every asset, config, token = a typed Move object
3
4struct Object {
5    id:          UID,         // globally unique 32-byte ID
6    version:     u64,         // incremented on every modification  
7    digest:      ObjectDigest, // hash of current state
8    owner:       Owner,        // who can use this object
9    type_:       MoveObjectType, // Move struct type
10    data:        MoveObject,   // the actual data (Move struct fields)
11}
12
13// Owner types:
14enum Owner {
15    AddressOwned(address),    // only this address can use it
16    ObjectOwned(UID),          // owned by another object
17    Shared { initial_version }, // any tx can access (needs ordering)
18    Immutable,                  // read-only, no gas for reads
19}
20
21// Storage key in RocksDB:
22DB[object_id] = serialize(object)
23// No trie needed — direct object ID lookup
⚡

vs Ethereum ERC20

Ethereum ERC20:
mapping(address => uint256) balances;
// Centralized ledger — shared object
// All transfers need consensus
Sui Coin:
struct Coin<T> { id: UID, value: u64 }
// Each coin is an owned object
// Transfers skip consensus!
🔑

Object ID Generation

id = hash(tx_digest, creation_index)
// Deterministic + unique
// Clients can predict IDs

Move Objects — Type-Safe Assets

move-objects.moverust
1// Move Objects — Type-Safe Assets
2// In Move, assets are types, not mappings
3
4// Define a token:
5module my_token::token {
6    struct Token has key, store {
7        id: UID,
8        value: u64,
9        metadata: String,
10    }
11    
12    // Create: object has key ability → gets a UID
13    public fun create(value: u64, ctx: &mut TxContext): Token {
14        Token {
15            id: object::new(ctx),  // generates unique UID
16            value,
17            metadata: string::utf8(b"MyToken"),
18        }
19    }
20    
21    // Transfer: Move's ownership system tracks this
22    public fun transfer(token: Token, recipient: address) {
23        transfer::transfer(token, recipient)  // changes owner
24    }
25}
26
27// KEY DIFFERENCE from Ethereum ERC20:
28// Ethereum: mapping(address => uint256) balances — central ledger
29// Sui: each Token object is independently owned — no shared state needed

Why Object Ownership Enables Parallelism

parallel.rsrust
1// Why Sui Can Parallelize — Owned vs Shared
2
3// Owned objects → PARALLEL (no global consensus needed)
4// Only the owner can submit txs → no conflicts possible
5
6// Example: Alice sends Token to Bob
7// Alice owns TokenA → only she can touch it
8// This tx touches: TokenA, Alice's coin (for gas)
9// No other tx can touch TokenA → PARALLEL!
10
11// Shared objects → SEQUENTIAL (need global ordering)
12// Multiple users can interact → conflicts possible
13
14// Example: DEX pool (shared object)
15// Alice and Bob both try to swap against the same pool
16// → Must be sequentially ordered (who goes first?)
17// → These txs CAN'T be fully parallelized
18
19// Sui's performance insight:
20// Most real-world txs (transfers, games, NFTs) = owned objects
21// Only complex DeFi = shared objects
22// → 90%+ of txs can be parallelized!

Sparse Merkle Tree — State Commitment

smt.txt
1// Sui State Commitment — Sparse Merkle Tree (SMT)
2// Not MPT like Ethereum — uses a different tree structure
3
4// Sparse Merkle Tree:
5// - Fixed depth = 256 (for 256-bit keys)
6// - Most nodes are "empty" (no data)
7// - Efficient because: empty subtrees compress to one hash
8
9// Key = object_id (32 bytes = 256 bits)
10// Value = hash(object)
11
12// Compared to Ethereum MPT:
13// ETH MPT: variable depth, 16-way, key = keccak256(address)
14// Sui SMT: fixed 256 depth, binary, key = object_id
15
16// Proof size:
17// Both: O(depth) proof elements
18// ETH: 64 nibbles → up to 64 nodes × larger hashes → ~10KB
19// Sui: 256 bits → 256 hashes × 32 bytes → 8KB (similar)
20// But: SMT can compress empty subtrees → much smaller in practice!
21
22// Checkpoint (like Ethereum block):
23// checkpoint.effects_root = SMT root of all affected objects

How Object Storage → Capabilities

✅
Owned objects skip consensus

Simple transfers, NFT sales, game moves = no validator coordination needed. Near-instant finality for owned-object txs.

✅
Objects have explicit ownership

Move's type system prevents double-spending at the language level — no central ledger needed for safety.

⚠️
Shared objects need sequencing

Complex DeFi (DEX pools, lending) requires all nodes to agree on order. Throughput limited for shared-object txs.

✅
Object versioning (version field)

Each object tracks its own version. Enables optimistic concurrency for owned objects without global state lock.

⚠️
Different mental model from Ethereum

Developers must rethink DeFi (no ERC20 mappings, no global state). Steep learning curve for ETH devs.