Key Features

1. Casual order vs. total order enables massively parallel execution
2. Sui’s variant of Move and its object-centric data model make composable objects/NFTs possible
3. The blockchain-oriented Move programming language eases the developer experience

Overview

• Optimizes for single-writer objects, removing the need for consensus in simple transactions
• Design enables requestors or proxies to proactively communicate with validators to finalize transactions, resulting in near-instant finality
• Supports smart contracts written in Sui Move

Components

• Objects:
• Programmable objects created and managed by Move packages (smart contracts)
• Move packages themselves are also objects
• Transactions:
• All updates to the Sui ledger happen via a transaction
• Validators:
• Network is operated by a set of independent validators

Architecture

• Sui is a distributed ledger that stores a collection of programmable objects, each with unique ID
• Transaction contains:
• Set of input object references
• Pointer to a Sui Move code object that already exists in the ledger
• Executing a transaction produces updates to the input objects and (if applicable) a set of freshly created objects along with their owner addresses
• Transaction from a sender A can accept:
• Objects owned by A
• Shared objects
• Objects taht are owned by the above cases
• Validators do not require consensus to process transactions involving exclusively owned objects
• Instead, they execute transactions in parallel at high throughput, utilizing Byzantine Consistent Broadcast
• For objects involving shared objects, the validators employ Bullshark, a high-throughput DAG-base consensus protocol

System Overview

• Sui assumes the typical blockchain transaction is a user-to-user transfer or asset manipulation and optimizes for that scenario
• As a result, Sui distinguishes between two types of assets:
1. Owned objects that can be modified only by their specific owner
2. Shared objects that have no specific owners and can be modified by more than one user
• Consensus is only required when the transaction involves shared objects
• Narwhal DAG-based mempool
• BFT consensus via Bullshark
• Because Sui focuses on managing specific objects rather than a single aggregation of states, it reports on them in a unique way:
1. Every object in Sui has a unique version number
2. Every new version is created from a transaction that may involve several dependencies
• Sui gurantees transaction processing obeys eventual consistency:
1. Eventual delivery: If one honest validator processes a transaction, all other honest validators will eventually do the same
2. Convergence: Two validators that have seen the same set of transactions share the same view of the system

Transactions on Single-Owner Objects

• Sui recognizes single-owner objects transactions forgo consensus and uses simpler algorithm based on BFT
• Single-owner object protocol is based on the FastPay design
• Sui takes the approach of taking a lock only for the relevant piece of data rather than the whole chain
• Sui further expands this approach to more involved transactions that may explicitly depend on multiple elements under their sender’s control
• By requiring that dependencies be explicit, Sui applies a multi-lane approach to transaction validation, ensuring those independent transaction flows can progress without interference or synchronization
• Sui validates transactions individually, rather than batching them into traditional blocks
• Key advantage of this is low latency as each successful transaction quickly obtains a certificate of finality
• Submitting a Sui transaction involves the following steps:
1. Users send transactions to a quorum driver (i.e Full node), that broadcasts the transaction to a set of validators
2. Each Sui validator performs validity checks on transactions and adds a signature to valid ones; each signature is weighted proportionally to the amount staked with the validator
3. The quorum driver collects signatures with a combined weight greater than or equal to 2/3 of the total stake (quorum stake) into a certificate and broadcasts it to all Sui validators
4. When a validator receives a certificate, the validator validates the certificate; If the certificate is valid, the validator then executes the embedded transaction and returns signed transaction effects to the quorum driver; Transaction becomes final after a quorum of validators receive and execute the corresponding certificate
5. Optionally, the quorum driver can collect an effects certificate based on the previous step and return it to the sender as proof of finality
• This process allows each validator to perform the operations above in parallel without coordination
• Significantly reduces the communication cost of committing a transaction

Transactions on Shared Objects

• Sui must sequence transaction that manipulate the same shared object using a consensus protocol
• Narwhal for high-throughput, horizontally scalable transaction dissemination
• Bullshark for zero message overhead consensus
• The process is as described above up to step (4), where instead:
1. When a validator receives a certificate and validates it, the validator uses Narwhal to submit the certificate to Bullshark for sequencing
2. After Sui sequences the transaction, it executes it to produce effects using the same flow as (5) above

Narwhal and Bullshark, Sui’s Mempool and Consensus Engines