Architecture Overview

System Architecture

Sui is a distributed ledger that stores programmable objects with globally unique IDs. Each object is owned, and each object has a type.

Core Components

Objects

The fundamental unit of storage in Sui. Every piece of data is represented as an object.

Owned Objects

Belong to a single address, enable fast-path execution

Shared Objects

Accessible by multiple addresses, require consensus

Immutable Objects

Read-only data that never changes

Wrapped Objects

Contained within another object’s fields

Object Structure:

pub struct Object {
    /// Unique identifier
    pub id: ObjectID,
    /// Version number (increments on each update)
    pub version: SequenceNumber,
    /// Hash of the transaction that created this version
    pub previous_transaction: TransactionDigest,
    /// Owner of this object
    pub owner: Owner,
    /// BCS-serialized Move value
    pub data: Data,
}

Validators

Validators are the backbone of the Sui network, responsible for:

Transaction Processing

Receive and validate transactions from clients
Execute Move code in the Move VM
Update object versions and ownership
Return signed effects certificates

Consensus Participation

Propose blocks containing transactions
Vote on block validity
Determine transaction ordering
Ensure Byzantine fault tolerance (2f+1 quorum)

Checkpoint Creation

Aggregate transaction effects into checkpoints
Sign checkpoint contents
Broadcast to other validators and fullnodes
Enable state synchronization

Validator Requirements:

Minimum 30M SUI stake (for mainnet)
High-performance hardware (48+ cores, 256GB RAM, NVMe SSD)
Low-latency network connection (less than 100ms to peers)
Run sui-node binary with validator configuration

Fullnodes

Fullnodes serve the network but don’t participate in consensus.

Sync State

Download and verify checkpoints from validators to stay up-to-date.

Serve RPCs

Provide JSON-RPC and GraphQL APIs for clients to query and submit transactions.

Index Data

Optionally run indexer to enable rich queries and event subscriptions.

Transaction Flow

Fast Path (Owned Objects)

For transactions that only touch owned objects (no sharing):

Fast path bypasses consensus entirely, achieving finality in a single round of communication.

Consensus Path (Shared Objects)

For transactions that access shared objects:

Transaction Lifecycle

const tx = new Transaction();
tx.moveCall({
  target: '0x2::coin::transfer',
  arguments: [coin, recipient],
});

Client creates a transaction with commands.

const signedTx = await wallet.signTransaction(tx);

User signs the transaction with their private key.

const result = await client.executeTransaction(signedTx);

Transaction is broadcast to validators.

- Check signature validity
- Verify gas payment
- Check object versions
- Validate Move bytecode

Validators perform safety checks.

- Load objects from storage
- Execute in Move VM
- Generate effects (updates, deletes, creates)
- Calculate gas charges

Transaction executes in deterministic environment.

- Update object store
- Record in checkpoint
- Emit events
- Return certificate to client

Changes are committed and confirmed.

Consensus Protocol

Mysticeti Overview

Sui uses Mysticeti, a cutting-edge DAG-based Byzantine Fault Tolerant consensus protocol.

DAG Structure

Blocks form a directed acyclic graph, not a linear chain

Leader-Based Commits

Even rounds have leaders that trigger commits

Pipelining

Multiple rounds process simultaneously

Fast Finality

Commits in 2-3 network round-trips (~500ms)

Key Properties:

Safety: Never commits conflicting transactions
Liveness: Always makes progress (given 2f+1 honest validators)
Throughput: Scales with validator hardware and network bandwidth
Latency: Minimizes time to finality

Block Structure

pub struct Block {
    /// Round number
    pub round: Round,
    /// Author (validator) that created this block
    pub author: AuthorityIndex,
    /// Timestamp when block was created
    pub timestamp_ms: u64,
    /// References to previous round blocks
    pub ancestors: Vec<BlockRef>,
    /// Transactions included in this block
    pub transactions: Vec<Transaction>,
}

Storage Architecture

Multi-Tier Storage

Sui employs a sophisticated storage architecture:

Authority Store (Perpetual)

Persistent RocksDB database containing:

Current object versions
Transaction history
Effects and events
Signatures and certificates

Never deleted, enables full history replay.

Execution Cache

In-memory cache for hot objects:

Recently accessed objects
Pending transactions
Temporary execution state

Improves performance by reducing disk I/O.

Checkpoint Store

Finalized checkpoint data:

Checkpoint summaries
Contents (transaction digests)
Signatures from validators

Enables state sync for new nodes.

Object Versioning

Each object update creates a new version:

Object ID: 0xabc123
├─ Version 1 (Created)   @ Tx 0x111
├─ Version 2 (Updated)   @ Tx 0x222
├─ Version 3 (Updated)   @ Tx 0x333
└─ Version 4 (Deleted)   @ Tx 0x444

Concurrent updates to the same object version are rejected - only one succeeds.

Gas and Economics

Gas Model

Computation Gas

Based on instructions executed in Move VM

Storage Gas

One-time fee for storing new objects

Storage Rebate

Partial refund when deleting objects

Reference Gas Price

Minimum price set by validators each epoch

Gas Calculation:

Total Gas = Computation Gas + Storage Gas - Storage Rebate

Computation Gas = Σ(instructions × instruction_cost)
Storage Gas = object_size_bytes × storage_price
Storage Rebate = deleted_object_size × rebate_rate

Storage Fund

The storage fund ensures long-term sustainability:

Inflows: Storage gas fees from object creation
Staking: Fund is staked to earn rewards
Outflows: Rebates when objects are deleted
Growth: Accumulates over time as network grows

Network Topology

Validator Network

Validators communicate via two networks:

Consensus Network
State Sync Network

Purpose: Mysticeti consensus protocol
Protocol: Anemo (custom RPC framework)
Topology: Fully connected mesh
Requirement: Low latency (less than 100ms)

Client Connectivity

Clients connect to fullnodes (not validators directly):

[Client] → [Fullnode RPC] → [Validators]
                ↓
         [Indexer/GraphQL]

Epochs and Reconfiguration

Epoch Lifecycle

An epoch is a period of validator operation (typically 24 hours).

Epoch Start

New validator set activates
Staking positions locked
Reference gas price set
Protocol version determined

Normal Operation

Process transactions
Create checkpoints
Accumulate rewards
Track validator performance

Epoch End

Final checkpoint created
Rewards calculated and distributed
Next validator set determined
State transition to next epoch

Validator Selection

For the next epoch:

Stake Calculation: Sum delegation to each validator
Threshold: Must meet minimum stake requirement
Committee Formation: Select validators with voting power proportional to stake
Activation: New committee activates at epoch boundary

Security Model

Byzantine Fault Tolerance

Sui tolerates up to f Byzantine (malicious) validators out of 3f+1 total:

Safety threshold: >2f+1 honest validators (⅔ of stake)
Liveness threshold: >2f+1 responsive validators (⅔ of stake)

Example (100M total stake):

f = 33M stake can be faulty
67M stake needed for quorum
Network secure if less than 33M stake is Byzantine

Attack Resistance

Double Spend

Prevented by object versioning and quorum requirements

Equivocation

Detected via cryptographic signatures

Denial of Service

Mitigated by gas fees and rate limiting

Sybil Attack

Prevented by stake requirements

Developer Tools

Move VM

The Move Virtual Machine executes smart contracts:

Bytecode Verifier: Ensures type safety and resource safety
Interpreter: Executes Move instructions
Gas Metering: Tracks execution costs
Deterministic: Same inputs always produce same outputs

Indexer

PostgreSQL-based indexer for rich queries:

-- Query all NFTs owned by an address
SELECT object_id, object_type, version
FROM objects
WHERE owner = '0x123...'
  AND object_type LIKE '%::nft::%';

Supports:

Object queries by owner, type, or field values
Event filtering and subscriptions
Transaction history
Package and module discovery

Next Steps

Sui Architecture Deep Dive

Detailed technical architecture

Consensus Protocol

Learn about Mysticeti consensus

Objects & Ownership

Understand Sui’s object model

Transactions

Transaction structure and lifecycle

Introduction

Quick Start

​System Architecture

​Core Components

​Objects

Owned Objects

Shared Objects

Immutable Objects

Wrapped Objects

​Validators

​Fullnodes

​Transaction Flow

​Fast Path (Owned Objects)

​Consensus Path (Shared Objects)

​Transaction Lifecycle

​Consensus Protocol

​Mysticeti Overview

DAG Structure

Leader-Based Commits

Pipelining

Fast Finality

​Block Structure

​Storage Architecture

​Multi-Tier Storage

​Object Versioning

​Gas and Economics

​Gas Model

Computation Gas

Storage Gas

Storage Rebate

Reference Gas Price

​Storage Fund

​Network Topology

​Validator Network

​Client Connectivity

​Epochs and Reconfiguration

​Epoch Lifecycle

​Validator Selection

​Security Model

​Byzantine Fault Tolerance

​Attack Resistance

Double Spend

Equivocation

Denial of Service

Sybil Attack

​Developer Tools

​Move VM

​Indexer

​Next Steps

Sui Architecture Deep Dive

Consensus Protocol

Objects & Ownership

Transactions

Build docs developers (and LLMs) love

System Architecture

Core Components

Objects

Validators

Fullnodes

Transaction Flow

Fast Path (Owned Objects)

Consensus Path (Shared Objects)

Transaction Lifecycle

Consensus Protocol

Mysticeti Overview

Block Structure

Storage Architecture

Multi-Tier Storage

Object Versioning

Gas and Economics

Gas Model

Storage Fund

Network Topology

Validator Network

Client Connectivity

Epochs and Reconfiguration

Epoch Lifecycle

Validator Selection

Security Model

Byzantine Fault Tolerance

Attack Resistance

Developer Tools

Move VM

Indexer

Next Steps