Sui’s object-centric model treats assets as independent objects with clear ownership. That means if two transactions touch different objects, they can be processed in parallel without waiting on each other. The magic comes from Sui’s consensus layers (Narwhal for data availability, Bullshark for ordering) plus its Move language, which enforces ownership rules so the system always knows which transactions can safely run side by side.

Sui’s object-centric data model is the foundation for its ability to process transactions in parallel, which is a major differentiator from traditional blockchains. Here’s how it works, and the key architectural components that make it possible:

1. Object-Centric Data Model

• Everything is an Object:
  On Sui, all on-chain data (coins, NFTs, smart contracts, etc.) are represented as objects, each with a unique ID, version, owner, and type.
  Source

• Ownership and Access:
  Each object has a clear ownership model (owned, shared, immutable), and transactions must declare exactly which objects they will read or modify.

2. Parallel Transaction Processing

• Explicit Dependencies:
  Because transactions specify the exact objects they touch, Sui can easily determine which transactions are independent (i.e., they don’t access the same objects) and can be executed in parallel.

  “When everything is an object, you know exactly which transactions are related. The system knows how to segment or group transactions and every group can be processed in parallel.”
  Source

• No Global State Lock:
  Unlike account-based blockchains (like Ethereum), Sui does not need to lock the entire global state for each transaction. It only locks the relevant objects, allowing unrelated transactions to proceed simultaneously.

• Causal vs. Total Order:

  • Owned Objects: Transactions involving only owned objects (not shared) can be processed in any order or in parallel, as they don’t affect each other.
  • Shared Objects: Transactions involving shared objects require consensus and are ordered, but can still be processed in parallel with transactions involving other (non-overlapping) objects. Source

3. Key Architectural Components

• Object References:
  Transactions use object references (ID, version, digest) to specify exactly which version of an object they operate on. This ensures validators agree on the state being modified. Source

• Transaction-Object DAG:
  Sui maintains a directed acyclic graph (DAG) relating transactions and objects. This structure makes it easy to track dependencies and causal relationships, further enabling parallelism. Source

• Validator Execution:
  Validators can dynamically allocate resources to process independent transactions in parallel, scaling throughput as needed. Source

Summary

• Sui’s object-centric model means each transaction declares its object dependencies.
• The network can safely execute transactions in parallel if they don’t touch the same objects.
• This is enabled by explicit object references, a transaction-object DAG, and a flexible validator execution model.

Sui’s object-centric model makes parallel execution possible because transactions operate directly on objects instead of a global shared state. Each object has a unique ID and ownership, so the system can quickly see which transactions touch the same objects.

If two transactions affect different objects, Sui runs them in parallel with no risk of conflict. Only transactions touching the same object need ordering.

Key architectural pieces that enable this are

Objects – Every asset or resource is an object with a globally unique ID and defined ownership.

Ownership and references – Objects can be owned by a user, shared, or immutable. This lets Sui decide if an update is isolated or needs coordination.

Transaction input analysis – The runtime analyzes which objects each transaction reads or writes before execution, allowing safe scheduling.

Narwhal and Bullshark consensus – For shared objects, Sui uses its consensus layers to order and finalize updates, while independent transactions bypass consensus and confirm instantly.

Together, this design avoids bottlenecks of account-based blockchains and enables high throughput with low gas fees.

Efficient validation methods for maintaining consistency Fair transaction processing to prevent monopolization of state Parallel Execution Engine - Transactions affecting non-overlapping objects can be processed simultaneously 17:16 Optimized for high-throughput processing Maintains consistency across concurrent operations