Architecture

Sui's architecture is shaped by one decision: treat owned-object transactions and shared-object transactions differently. Everything else — the validator set, full nodes, the object store, and the SDK — follows from that.

The network roles

• Validators — a permissioned (staked) set that executes transactions, participates in consensus for shared objects, and produces checkpoints. Validator stake and behavior are governed by Sui's on-chain system state (epoch-based).
• Full nodes — non-staked replicas that verify and serve the chain: they expose the JSON-RPC API, maintain a copy of the object store and history, and can be run by anyone. Most applications talk to a full node, not to validators.
• Archive nodes — store complete historical data (all checkpoints and transactions) for deep history queries and auditability.

The object store

State is a database of objects keyed by (ObjectID, version). The object store:

• Indexes objects by owner (an address, another object, or "shared") and by type, enabling rich queries (getObjectsOwnedByAddress, getDynamicFieldObject).
• Keeps versions — every mutation bumps an object's version, which is what lets fast-path transactions detect and reject stale reads.
• Represents owned vs. shared state, which decides the execution path a transaction takes.

Transaction flow

1. A client builds a transaction block (a set of commands: Move calls, transfers, splits), signs it, and submits it to a full node or validator via sui_executeTransactionBlock.
2. The client decides the path based on the objects the tx touches:
3. Owned-only transactions are sent to validators for fast-path certification — a quorum of signatures and the tx is final. No consensus round.
4. Shared-object transactions are sent to validators which sequence them through the DAG-based consensus (see the Consensus & Ordering module) and execute them in that order.
5. Validators execute via the MoveVM, produce effects (state changes, events, gas), and form checkpoints that are signed and finalized.
6. Full nodes ingest checkpoints and update their local object store; clients see the effects via the RPC.

Why the split works

• Parallelism — transactions touching disjoint owned objects can be executed in parallel (they're independent), and the fast path avoids consensus entirely.
• Latency — the common "send a payment" case commits in one round-trip.
• Simplicity for developers — you don't choose the path; the framework does, based on object ownership. As a builder you just pick whether an object is owned or shared when you design it.

Design principles

• Ownership is a first-class, enforced concept — the framework won't let you mutate an object you don't own.
• Consensus only where required — ordering is the expensive resource; the architecture spends it only on genuinely shared state.
• Move is the only way to touch state — no arbitrary bytecode execution, which is a large part of why the system can be this parallel and auditable.