Sui

🔗 Website

sui.io

🐦 Twitter

twitter.com/SuiNetwork

*️⃣ State Model

⏹️ L1

</> Language

Move

⏩ TPS

0297000 (testnet)

👾 Repos

00457

↕️ Repos change

⬆️

SUI is a Layer 1 blockchain and smart contract platform designed to provide high throughput, low latency, and an asset-oriented programming model. Developed by Mysten Labs, SUI aims to address scalability issues common in traditional blockchain systems by introducing innovative consensus mechanisms and a unique object-centric approach to data management.

Key Features

SUI's design philosophy focuses on enabling scalable decentralized applications (dApps) and Web3 services, particularly those requiring high-performance handling of digital assets.

Object-centric data model: Unlike account-based systems, SUI treats data as objects with unique identifiers, enabling more efficient parallel processing of transactions.
Move programming language: SUI utilizes an enhanced version of the Move language, originally developed for the Diem blockchain, to create secure and flexible smart contracts.
High throughput: The platform's innovative consensus mechanism, based on the Sui Lutris protocol, allows for parallel execution of independent transactions, significantly increasing transaction processing speed.
Flexible ownership structures: SUI supports various object ownership models, including address-owned, shared, and immutable objects, providing developers with versatile options for asset management.
Low latency finality: SUI's architecture enables rapid transaction finality, particularly for transactions involving owned objects.
Tokenomics design: The platform incorporates a sophisticated economic model, including a native SUI token, a storage fund, and a delegated proof-of-stake system.

History and Development

SUI was conceived and developed by Mysten Labs, a company founded by former executives and senior developers from Meta's (formerly Facebook's) Novi Research and Diem blockchain project. The founding team's experience with the Diem blockchain and the Move programming language significantly influenced SUI's design and architecture.

Key milestones in SUI's history include:

2021: Mysten Labs was founded by Evan Cheng, Adeniyi Abiodun, Sam Blackshear, and George Danezis, all of whom had previously worked on the Diem blockchain project.
November 2021: Mysten Labs raised $36 million in a Series A funding round led by Andreessen Horowitz, signaling strong interest in their novel blockchain architecture.
2022: Development of the SUI blockchain began, with a focus on creating a high-performance, scalable platform using the Move programming language.
July 2022: SUI launched its first public testnet, allowing developers to experiment with the platform's unique features.
September 2022: Mysten Labs secured $300 million in Series B funding, valuing the company at $2 billion and demonstrating growing confidence in SUI's potential.
December 2022: SUI launched its second incentivized testnet wave, further expanding its developer ecosystem and stress-testing the network.
May 2023: SUI officially launched its mainnet, marking a significant milestone in the platform's development and opening up the network for real-world applications.

Technical Architecture

State Model

SUI implements a Directed Acyclic Graph (DAG) architecture as a fundamental part of its design, which plays a crucial role in its ability to achieve high throughput and parallelism. This DAG-based structure underpins SUI's object-centric model and transaction processing approach.

Key aspects of SUI's DAG architecture include:

Transaction-Object Relationship:

In SUI's DAG, nodes represent transactions, and directed edges represent the flow of objects between transactions.
Each edge is labeled with the object reference, specifying the exact version of the object created by one transaction and used by another.

Causal History:

The DAG structure allows SUI to maintain a clear causal history of objects and transactions.
This enables efficient tracking of object lineage and dependencies between transactions.

Parallel Execution:

The DAG architecture facilitates parallel execution of transactions that operate on disjoint sets of objects.
Transactions that don't have dependencies on each other can be processed simultaneously, enhancing overall throughput.

Consensus Optimization:

SUI's consensus mechanism, based on the Sui Lutris protocol, leverages the DAG structure to optimize block creation and validation.
Validators can propose blocks in parallel, utilizing the full bandwidth of the network.

Object Versioning:

The DAG structure naturally supports SUI's object versioning system, where each modification to an object creates a new version with a link to its predecessor.

State Management:

The DAG allows for efficient management of the global state, as it clearly represents which objects are available for use in new transactions.

Scalability:

The DAG architecture contributes to SUI's scalability by allowing the network to process multiple streams of non-conflicting transactions concurrently.

Checkpointing:

While SUI uses a DAG for transaction processing, it periodically creates checkpoints that represent a consistent view of the network state.
These checkpoints are formed by taking chunks of ordered transactions from the DAG-based consensus layer.

Auditability:

The DAG structure provides a complete and auditable view of the system's state and history when it contains all committed transactions.

Flexibility:

The DAG can be used to construct a view of the relevant history for a subset of transactions or objects, allowing for efficient partial state reconstructions.

Consensus Mechanism

SUI employs a novel consensus mechanism designed to achieve high throughput and low latency. The core of this mechanism is based on two key components:

Delegated Proof-of-Stake (DPoS): This system allows SUI token holders to delegate their stake to validators, who are responsible for processing transactions and maintaining the network's security. The amount of stake delegated to a validator determines their voting power in the consensus process.
Sui Lutris Protocol: This is the next-generation consensus engine developed specifically for SUI. It optimizes for both low latency and high throughput through several innovative features:

Parallel block proposals: Multiple validators can propose blocks concurrently, maximizing network bandwidth utilization and providing censorship resistance.
Three-round commit process: Sui Lutris requires only three rounds of messages to commit blocks from the DAGs (Directed Acyclic Graphs), matching the theoretical minimum and ensuring rapid finality.
Parallel voting and leader certification: The commit rule allows for simultaneous voting and certifying of leaders on blocks, further reducing median and tail latencies.

The SUI consensus mechanism is designed to maintain Byzantine fault tolerance, ensuring the network's integrity even if up to one-third of validators behave maliciously or fail.

A unique aspect of SUI's consensus approach is its ability to process certain transactions without going through the full consensus process. Transactions that only involve owned objects (as opposed to shared objects) can be processed immediately by validators without waiting for consensus, providing near-instant finality for many common operations.

For transactions involving shared objects, SUI uses its DAG-based consensus protocol to order and execute these transactions. This hybrid approach allows SUI to maintain high performance for simple transactions while ensuring consistency for more complex, shared-state operations.

The economic model supporting this consensus mechanism includes stake rewards for validators and delegators, creating incentives for network participation and security. The system also includes mechanisms to penalize underperforming or malicious validators, ensuring the network's overall health and reliability.

Mysticeti Consensus Mechanism

Mysticeti is a family of Byzantine fault-tolerant (BFT) protocols designed to support high-performance distributed ledgers and blockchains. Developed by researchers from Cornell Tech, Mysten Labs, University College London, and IST Austria, Mysticeti aims to address the latency and throughput limitations of existing consensus protocols while maintaining strong security guarantees.

The Mysticeti family consists of two main protocols:

MYSTICETI-C: A consensus protocol that achieves the theoretical lower bound of 3 message rounds for latency in Byzantine consensus.
MYSTICETI-FPC: An extension of MYSTICETI-C that incorporates a fast commit path for certain types of transactions, further reducing latency for specific workloads.

Key innovations of Mysticeti include:

Use of uncertified Directed Acyclic Graphs (DAGs) to improve efficiency
Novel commit rules allowing for lower latency commits
Integration of consensus and fast-path protocols within a single framework
Improved resource efficiency and censorship resistance

Mysticeti has demonstrated significant performance improvements over existing protocols, achieving sub-second latency for consensus commits while maintaining high throughput. It has been successfully integrated into the Sui blockchain, resulting in substantial latency reductions in a production environment.

Background

Byzantine consensus protocols are fundamental to the operation of distributed systems that must maintain consistency in the presence of potentially malicious or faulty nodes. These protocols are particularly crucial for blockchain systems, where they ensure the integrity and consistency of the distributed ledger.

Traditional Byzantine Fault Tolerant (BFT) consensus protocols, such as Practical Byzantine Fault Tolerance (PBFT), have faced challenges in scaling to large networks and achieving low latency. More recent approaches, including HotStuff and Narwhal-Tusk, have improved upon these earlier designs but still face limitations in terms of latency and resource efficiency.

Mysticeti addresses several key challenges in the field of Byzantine consensus:

Latency: Existing protocols often require multiple rounds of communication, leading to high latency, especially in wide-area networks.
Throughput: Many protocols struggle to maintain high throughput as the network size increases or under adverse network conditions.
Resource Efficiency: Protocols that rely on certified DAGs or extensive signature verification can be computationally expensive.
Fault Tolerance: Handling both Byzantine (malicious) and crash faults efficiently is an ongoing challenge in distributed systems.
Flexibility: Supporting both consensus-based and consensusless transactions within a single framework has been difficult to achieve efficiently.

By addressing these challenges, Mysticeti aims to provide a more efficient and flexible foundation for building high-performance distributed ledgers and blockchain systems. Its design draws inspiration from previous work on DAG-based consensus while introducing novel techniques to overcome existing limitations.

MYSTICETI-C Consensus Protocol

MYSTICETI-C is a Byzantine consensus protocol that operates on an uncertified Directed Acyclic Graph (DAG) structure. It is designed to achieve low latency and high throughput while maintaining Byzantine fault tolerance. The protocol can achieve consensus in as few as 3 message rounds, matching the theoretical lower bound for Byzantine consensus.

2.2 DAG Structure

The MYSTICETI DAG is composed of blocks proposed by validators in each round. Each block contains:

The author's identity and signature
A round number
A list of transactions
References to at least 2f+1 blocks from the previous round (where f is the maximum number of Byzantine faults tolerated)

Unlike some other DAG-based protocols, MYSTICETI-C does not require explicit certification of blocks, which contributes to its improved efficiency.

2.3 Decision Rules

MYSTICETI-C employs two main decision rules:

Direct Decision Rule: Applied to the most recent slots, this rule attempts to classify slots as either "to-commit" or "to-skip" based on observed DAG patterns.
Indirect Decision Rule: Used when the direct rule fails to make a decision, this rule relies on finding an "anchor" block in a future round to determine the status of a slot.

These decision rules allow MYSTICETI-C to commit multiple blocks per round, improving overall throughput.

2.4 Commit Sequence

After applying the decision rules, validators derive an ordered sequence of slots. They iterate over this sequence, committing blocks marked as "to-commit" and skipping those marked as "to-skip" until they encounter the first undecided slot.

2.5 Performance Characteristics

MYSTICETI-C achieves sub-second latency for consensus commits while maintaining high throughput (over 200k transactions per second in some configurations). It is particularly efficient in handling crash faults, showing minimal performance degradation in such scenarios.

MYSTICETI-FPC Fast Path Protocol

3.1 Overview

MYSTICETI-FPC extends MYSTICETI-C to support a fast commit path for certain types of transactions. This extension is designed to handle workloads that do not require full consensus, such as asset transfers or payments, with even lower latency.

3.2 Fast Path Execution

In MYSTICETI-FPC, transactions are classified as either "owned object" or "shared object" transactions. Owned object transactions, which only access state controlled by a single party, can be executed via the fast path. A validator can safely execute a fast path transaction once it observes blocks from 2f+1 validators that include a vote for the transaction.

3.3 Fast Path Finality

While fast path transactions can be executed quickly, ensuring their finality across epoch boundaries requires additional steps. A fast path transaction is considered final when either:

The validator observes 2f+1 certificate patterns over the block proposing the transaction, each containing 2f+1 votes for the transaction.
A single certificate pattern over the proposing block, including 2f+1 votes, is referenced in the causal history of a block committed by the consensus protocol.

3.4 Epoch Changes

MYSTICETI-FPC introduces an "epoch-change bit" in blocks to handle the transition between epochs safely. When this bit is set, it signals that the block does not contribute to the finalization of fast path transactions. This mechanism ensures that all finalized transactions from the current epoch are included in the final commit before the epoch change.

3.5 Mixed-Object Transactions

MYSTICETI-FPC also supports transactions that contain both owned-object and non-owned-object inputs, called mixed-object transactions. These transactions are executed and finalized upon observing votes from 2f+1 validators and a consensus-committed block referencing these votes.

By integrating the fast path directly into the DAG structure, MYSTICETI-FPC achieves high efficiency and low latency for a wide range of transaction types while maintaining strong safety guarantees.

Implementation

The Mysticeti protocols are implemented in Rust, a programming language chosen for its performance and safety features. Key implementation details include:

Networking:

Uses the tokio asynchronous runtime for efficient network communication
Employs TCP sockets without relying on additional RPC frameworks

Cryptography:

Utilizes ed25519-consensus for asymmetric cryptography
Employs blake2 for cryptographic hashing operations

Data Persistence:

Implements a custom Write-Ahead Log (WAL) for crash recovery
Uses memory-mapped files for efficient reading of the WAL
Employs vectored writes for optimized I/O operations

Architecture:

Core consensus logic runs synchronously in a dedicated thread
Network communications operate asynchronously

Testing and Simulation:

Includes a simulation layer that replicates the functionality of the tokio runtime and TCP networking
Features a discrete event simulation approach to mimic real-world latencies
Provides an "orchestrator" utility for deploying and testing real-world clusters

Optimizations:

Minimizes data copying and serialization
Avoids use of key-value stores like RocksDB to eliminate associated overhead

The implementation is open-source, allowing for community review and contributions.

Performance Evaluation

5.1 Experimental Setup

Mysticeti's performance was evaluated using Amazon Web Services (AWS) with the following configuration:

Instance Type: m5d.8xlarge
Deployment: 13 different AWS regions globally
Hardware: 32 vCPUs, 128GB memory, 10Gbps network bandwidth
Operating System: Linux Ubuntu server 22.04

Experiments were conducted with varying committee sizes, including 10 and 50 validators. The inter-validator network latency ranged from 50ms to 250ms, simulating real-world conditions.

5.2 Comparison to Other Protocols

MYSTICETI-C was compared against several state-of-the-art consensus protocols:

HotStuff (Jolteon variant)
Narwhal-HotStuff
Bullshark

Key findings:

Latency: At steady state (50k to 400k TPS), MYSTICETI-C exhibited sub-second latency, 2-3 times lower than the fastest competing protocols.
Throughput: MYSTICETI-C achieved over 300k-400k TPS before reaching 1s latency, outperforming other systems.
Scalability: Performance remained strong for both 10 and 50 validator networks.

MYSTICETI-FPC was compared against Zef, a state-of-the-art consensus-less protocol:

Both systems achieved comparable latency (~0.25s) at low loads.
As load increased, MYSTICETI-FPC demonstrated significantly higher throughput (175k TPS for small networks, 80k TPS for larger networks) compared to Zef (20k TPS for small networks, 7k TPS for larger networks).

5.3 Fault Tolerance

Experiments were conducted to evaluate performance under crash faults:

MYSTICETI-C maintained high throughput and sub-second latency even with 3 out of 10 validators experiencing crash faults.
Competing protocols showed significant degradation in both throughput and latency under similar fault conditions.
HotStuff's throughput dropped to a few hundred TPS with latency exceeding 15s.
Narwhal-HotStuff and Bullshark processed about 70k TPS in 8-10 seconds.
MYSTICETI-C processed the same load while maintaining sub-second latency, demonstrating a 15-20x latency improvement over baseline protocols.

These results validate MYSTICETI-C's ability to handle crash faults efficiently, a common occurrence in real-world blockchain deployments.

Real-World Deployment

MYSTICETI-C has been successfully integrated into the Sui blockchain, replacing its previous consensus protocol, Bullshark. This integration provides valuable insights into the protocol's performance in a production environment.

Integration Process:

Initial explorations began in November 2023
A production-ready version was deployed on a geo-distributed private test environment in February 2024
Testing was conducted on two testbeds:

137 validators with equal voting power
117 validators with voting power distribution emulating the Sui mainnet

Adaptations for Production:

Implementation of crash recovery mechanisms
Integration of bulk catchup and synchronization code
Implementation of Sui's checkpoint mechanism
Integration of HammerHead for proposer reputation

Testing and Deployment Strategy:

Development of a Domain-Specific Language (DSL) for constructing MYSTICETI DAG scenarios
Alternating between Bullshark and MYSTICETI-C with each epoch during devnet and testnet phases
Devnet release scheduled for April 2024
Testnet release planned for May 2024
Mainnet release anticipated around June 2024

Performance Improvements:

Tests conducted on Vultr using vbm-24c-256gb-amd instances across 9 global regions showed:

MYSTICETI-C achieved p50 latency of 650ms and p95 latency of 975ms with 137 validators
In comparison, Bullshark exhibited p50 latency of 2.89s and p95 latency of 4.6s under the same conditions
Both systems maintained a throughput of 5,000 TPS

These results demonstrate a substantial latency improvement of over 4x when replacing Bullshark with MYSTICETI-C in the Sui blockchain.

Security Analysis

MYSTICETI-C and MYSTICETI-FPC are designed to provide strong security guarantees in Byzantine environments. The security properties of the protocols have been formally proven and are summarized below.

8.1 System Model and Assumptions

Byzantine Fault Tolerance: The system can tolerate up to f Byzantine faults in a network of n = 3f + 1 validators
Network Model: Partially synchronous network
Cryptographic Assumptions: Standard cryptographic primitives (digital signatures, hash functions) are secure

8.2 Safety Properties

MYSTICETI-C:

Total Order: All correct validators deliver a consistent sequence of blocks
Integrity: Each correct validator delivers each unique block at most once
Agreement: If a correct validator delivers a block, all correct validators eventually deliver that block

MYSTICETI-FPC (additional properties):

Epoch Close Safety: Transactions finalized in one epoch persist in all subsequent epochs
Transaction Safety: An honest validator never finalizes two conflicting transactions

8.3 Liveness Properties

MYSTICETI-C:

Consensus Liveness: After the Global Stabilization Time (GST), the proposal of an honest proposer will eventually commit
Round Synchronization: After GST, all honest parties enter the same round within a bounded time
Leader Proposal: After GST, an honest proposer's proposal receives votes from every honest validator

MYSTICETI-FPC (additional properties):

Fast-Path Liveness: An honest fast-path transaction will commit after GST
Equivocation Tolerance: The system can recover from equivocations across epoch boundaries

8.4 Byzantine Fault Tolerance

The protocols maintain safety and liveness in the presence of up to f Byzantine validators. The use of quorum certificates and the DAG structure ensures that conflicting decisions cannot be made even if Byzantine validators attempt to equivocate or withhold information.

8.5 Formal Verification

The security properties of MYSTICETI-C and MYSTICETI-FPC have been formally proven using rigorous mathematical techniques. These proofs provide strong assurances about the correctness of the protocols under the stated system model and assumptions.

Object Model

SUI introduces a novel object-centric data model that fundamentally differs from the account-based models used in many other blockchain systems. This approach is central to SUI's ability to achieve high performance and scalability.

Key aspects of SUI's object model include:

Objects as Basic Units: In SUI, all data is represented as objects. Each object has a unique 32-byte ID, making it globally identifiable and addressable. Objects can represent various entities such as coins, NFTs, smart contracts (called Move packages in SUI), or any other form of digital asset.
Object Metadata: Every object in SUI contains metadata including its ID, version (an 8-byte unsigned integer that increases monotonically with modifications), the transaction digest of its last modification, and ownership information.
Object Ownership Types:

Address-Owned Objects: These are owned by a specific 32-byte address and are accessible only to their owner.
Shared Objects: These can be accessed by anyone on the network.
Immutable Objects: These cannot be modified or deleted once created.

Dynamic Fields: SUI allows for the addition of arbitrary fields to objects at runtime, providing flexibility in object structure and composition.
Object Versioning: SUI uses a versioning system based on Lamport timestamps to ensure that object versions are strictly increasing and that (ID, version) pairs are never reused.
Wrapped Objects: Objects can be wrapped inside other objects, creating a parent-child relationship. This allows for complex data structures and ownership hierarchies.

The object-centric model enables several key features in SUI:

Parallel Execution: Transactions that operate on disjoint sets of owned objects can be processed in parallel, significantly increasing throughput.
Simplified Sharding: The object model naturally lends itself to data sharding, as objects can be easily distributed across different network segments.
Flexible Ownership Structures: The various ownership types allow for diverse application designs, from personal wallets to complex multi-user systems.
Efficient State Management: The versioning system allows for efficient tracking of state changes and enables features like simplified rollbacks and forks.

Move Programming Language

SUI utilizes an enhanced version of the Move programming language for developing smart contracts and defining the logic for all on-chain activities. Originally created for the Diem blockchain project, Move has been adapted and extended for use in SUI, taking advantage of its safety features while optimizing it for SUI's unique architecture.

Key aspects of Move on SUI include:

Safety and Security: Move is designed with a focus on safety, employing static typing and move semantics to prevent issues like double-spending and resource duplication. Its design makes it easier to write secure smart contracts, reducing the risk of vulnerabilities.
Object-Centric Programming: In line with SUI's object model, Move on SUI allows developers to define, create, and manipulate objects representing user-level assets. This aligns closely with SUI's overall data model.
Abilities System: Move uses an abilities system to define what operations can be performed on different types. In SUI, the key ability is required for all objects, while the store ability is optional and determines if an object can be freely transferred or wrapped.
Custom Transfer Rules: Move on SUI allows developers to define custom transfer functions for objects, enabling fine-grained control over how assets can be moved within the system.
Module Initializers: SUI introduces the concept of module initializers (init functions) that are executed once when a module is published, allowing for one-time setup operations.
Entry Functions: These are special functions in Move modules that can be called directly from SUI transactions, facilitating interaction between the blockchain and external systems.
Sui Framework: SUI provides a comprehensive framework of Move modules that offer core functionality and can be easily imported and used in custom contracts.

Key differences between Move on SUI and Move on other platforms include:

Global Storage: SUI doesn't use Move's global storage operators. Instead, it implements its own object-centric global storage.
Object References: Entry points in SUI take object references as input, rather than using global storage operations.
Address Representation: In SUI, the address type is repurposed as a 32-byte identifier used for both objects and accounts.

Transaction Processing

SUI's transaction processing model is designed to maximize throughput and minimize latency while maintaining security and consistency. The platform introduces several innovative concepts and mechanisms to achieve these goals:

Programmable Transaction Blocks (PTBs): PTBs are a key innovation in SUI's transaction model. They allow users to combine multiple operations into a single atomic transaction, enabling complex interactions in a single execution. PTBs can contain up to 1,024 unique operations, significantly reducing the overhead associated with processing multiple separate transactions.
Parallel Execution: SUI can process transactions that operate on disjoint sets of owned objects in parallel. This capability is a direct result of SUI's object-centric model and significantly increases the overall throughput of the network.
Immediate Execution for Owned Objects: Transactions that only involve owned objects can be processed immediately by validators without going through the full consensus process. This feature enables near-instant finality for many common operations.
Consensus for Shared Objects: Transactions involving shared objects are processed through SUI's consensus mechanism to ensure consistency across the network.
Transaction Lifecycle: A transaction in SUI goes through several stages:

Submission
Certification
Execution
Finalization (including effects certification)
Checkpointing

Gas Model: SUI employs a sophisticated gas model that separates computation and storage costs. This model aims to provide predictable transaction fees and incentivize efficient use of network resources.
Sponsored Transactions: SUI supports sponsored transactions, allowing one address to pay gas fees for transactions initiated by another address. This feature can enhance user experience by removing the need for new users to acquire tokens before interacting with dApps.
Transaction Finality: SUI offers two levels of finality:

Transaction finality: Achieved when a transaction is certified by a quorum of validators.
Settlement finality: Reached when the transaction effects are certified, allowing dependent transactions to proceed.

Checkpoints: SUI periodically creates checkpoints, which represent a consistent view of the network state and include all finalized transactions up to that point.
Gas Smashing: This feature allows users to pay for gas using multiple coins, providing flexibility in managing gas payments.

Storage and Versioning

SUI implements a sophisticated storage and versioning system that is fundamental to its object-centric model and its ability to manage state efficiently. This system is designed to handle the unique requirements of SUI's architecture while ensuring data integrity and facilitating efficient querying and updates.

Key aspects of SUI's storage and versioning system include:

Object Versioning:

Each object in SUI is referenced by both an ID and a version.
When an object is modified, a new version is created with the same ID but an incremented version number.
SUI uses Lamport timestamps for versioning, ensuring that versions are strictly increasing and that (ID, version) pairs are never reused.
Only the latest version of an object is available for transactions, maintaining a linear history of changes.

Package Versioning:

Move packages (smart contracts) in SUI are also versioned, but follow a different scheme from objects as they are immutable once published.
Each time a package is published or upgraded, a new ID is generated.
Unlike objects, older versions of packages remain accessible even after upgrades.
Framework packages (like the Sui Framework) are a special case, retaining the same ID across upgrades but incrementing their version number.

Storage Pruning:

Node operators have the option to prune old object versions that are no longer accessible, helping to manage storage requirements.
This pruning is optional, allowing nodes to retain historical data if desired for auditing or other purposes.

Dynamic Fields:

SUI supports dynamic fields, allowing objects to have an arbitrary number of fields added or removed at runtime.
The versioning system ensures that adding or removing dynamic fields does not lead to ID or version conflicts.

Wrapped Objects:

Objects can be wrapped inside other objects, and the versioning system maintains consistency across wrapping and unwrapping operations.
The version of an unwrapped object is always greater than its version when it was wrapped, preventing version reuse.

Storage Fund:

SUI implements a storage fund to manage the long-term costs of data storage.
Users pay upfront for storage when creating objects, and these fees are used to compensate future validators for maintaining the data.

State Sync:

SUI uses a state sync mechanism to allow nodes to efficiently catch up with the current state of the network.
This system leverages the object-centric model and versioning to minimize the amount of data that needs to be transferred.

Checkpoints:

SUI periodically creates checkpoints that represent a consistent view of the network state.
These checkpoints include all finalized transactions up to that point and play a crucial role in state management and synchronization.

Tokenomics

$SUI Token

The $SUI token is the native cryptocurrency of the Sui blockchain. It serves multiple crucial functions within the Sui ecosystem and is designed to support the network's economic model.

Key aspects of the $SUI token include:

Supply:

The total supply of $SUI is capped at 10,000,000,000 (ten billion) tokens.
A portion of the total supply became liquid at the Mainnet launch, with the remaining tokens vesting over time or allocated for future stake reward subsidies.

Utility:

Gas Fees: $SUI is used to pay for transaction fees on the network, covering both computation and storage costs.
Staking: Token holders can stake $SUI to participate in the network's proof-of-stake mechanism.
Governance: $SUI tokens play a crucial role in on-chain governance, allowing holders to participate in voting on protocol upgrades and other important decisions.

Denominations:

The smallest unit of $SUI is called MIST.
1 $SUI = 1,000,000,000 $MIST (1 billion $MIST).

Economic Design:

The $SUI token is designed to support various economic activities within the Sui ecosystem, including acting as a unit of account, medium of exchange, and store of value.
The token's design takes into account the need for the ecosystem to scale as more users and applications join the network.

Storage Fund Interaction:

The presence of a storage fund creates important monetary dynamics for $SUI.
As on-chain data requirements increase, more $SUI is locked in the storage fund, potentially reducing the circulating supply.

Staking and Rewards:

$SUI token holders can delegate their tokens to validators, participating in the network's security and earning staking rewards.
The staking mechanism is designed to incentivize long-term holding and network participation.

Token Distribution:

The initial distribution of $SUI tokens included allocations for the founding team, investors, and a community reserve.
The exact details of the token distribution were made public closer to the mainnet launch.

Bridging:

$SUI can be bridged to and from other blockchain networks, enhancing interoperability and liquidity across the broader cryptocurrency ecosystem.

Gas Model

The gas model in SUI is designed to provide a fair, predictable, and efficient mechanism for pricing computation and storage on the network. It incorporates several innovative features that set it apart from gas models in other blockchain systems.

Key components of SUI's gas model include:

Dual Fee Structure:

Computation Fees: Cover the cost of processing transactions.
Storage Fees: Account for the long-term cost of storing data on the blockchain.

Gas Price Mechanism:

SUI uses a dynamic gas pricing mechanism that aims to deliver low, predictable transaction fees.
A network-wide reference gas price is set at the start of each epoch through a validator voting process.
Users can optionally add a tip to the reference gas price to prioritize their transactions.

Computation Units:

SUI uses a coarse bucketing approach for computation gas costs.
Similar transactions fall into the same bucket and cost the same amount of gas, reducing the need for "gas golfing" optimizations.

Storage Units:

Storage costs are calculated linearly based on the amount of data stored.
Each byte of storage translates to 100 storage units.

Gas Budget:

Transactions must specify a gas budget, which acts as a cap on the total gas fees.
The minimum gas budget is 2,000 MIST (0.000002 SUI) to prevent spam.
The maximum gas budget is 50 billion MIST (50 SUI) to protect against potential overflows.

Storage Rebates:

When data is deleted, users receive a partial rebate of their storage fees.
Initially, 99% of storage fees are rebateable, while 1% is non-rebateable.

Gas Smashing:

Users can pay for gas fees using multiple coins in a single transaction.
This feature provides flexibility in managing gas payments and can help with coin management.

Sponsored Transactions:

SUI allows for sponsored transactions where one address can pay the gas fees for a transaction initiated by another address.

Incentive Alignment:

The gas pricing mechanism is designed to incentivize validators to optimize their operations and provide efficient transaction processing.
Validators that consistently process transactions at lower gas prices receive boosted stake rewards.

Epoch-based Updates:

The reference gas price is updated at each epoch boundary, allowing the system to adapt to changing network conditions.

Storage Fund

The Storage Fund is a crucial component of SUI's economic model, designed to address the long-term costs associated with data storage on the blockchain. This innovative mechanism aims to create a sustainable economic model for on-chain data storage and to fairly distribute storage costs across time.

Key aspects of the Storage Fund include:

Purpose:

The Storage Fund redistributes storage fees from past transactions to future validators, ensuring that future validators are compensated for storing data created by past transactions.
It addresses the inter-temporal challenge of on-chain data storage, where validators who process and write data today might differ from future validators needing to store that data.

Funding Mechanism:

When users transact on SUI, they pay upfront fees for both computation and storage.
The storage fees are deposited into the Storage Fund.

Stake Calculation:

The Storage Fund is included in the calculation of total stake in SUI's delegated proof-of-stake mechanism.
Total stake = User stake + Storage Fund

Reward Distribution:

A majority share (γ) of the stake rewards accruing to the Storage Fund is paid out to current validators to compensate for storage costs.
The remaining (1 - γ) share is reinvested in the fund to ensure its long-term sustainability.

Dynamic Sizing:

The size of the Storage Fund changes at each epoch boundary based on net inflows accumulated throughout the epoch.
Inflows come from storage fees paid for transactions and reinvestments of the fund's returns.
Outflows occur when users delete data and receive storage fee rebates.

Deletion Option:

Users can delete data and receive a partial refund of their original storage fees.
This incentivizes users to free up storage when the cost of maintaining data on-chain exceeds its value.

Capital Efficiency:

The Storage Fund is designed to be capital efficient, economically equivalent to a rent model where users pay for storage through a pay-per-period model.

Economic Impacts:

The Storage Fund creates deflationary pressure on the SUI token, as increased network activity leads to more SUI being locked in the fund.
It provides a market-based mechanism for managing on-chain data storage.

Validator Compensation:

The fund ensures that validators receive substantial additional rewards when on-chain storage requirements are high, compensating them for increased storage costs.

Long-term Sustainability:

By paying out only the returns on its capital and not the principal, the Storage Fund is designed to maintain its capitalization indefinitely.

Staking and Rewards

Staking and rewards are central components of SUI's economic model, designed to secure the network, incentivize participation, and distribute rewards fairly among stakeholders. The system is based on a Delegated Proof-of-Stake (DPoS) mechanism.

Key aspects of SUI's staking and rewards system include:

Staking Mechanism:

SUI token holders can stake their tokens by delegating them to validators.
Staking is implemented through a system Move package, creating a self-custodial stake object.
Staked SUI tokens are locked for the entire epoch in which they are staked.

Validator Selection:

Validators are selected based on the amount of stake delegated to them.
A validator's voting power in the network is proportional to their total stake.

Reward Calculation:

Total stake rewards = Computation fees accrued throughout the epoch + Stake reward subsidies
Rewards are distributed across validators and delegators based on their stake and performance.

Validator Rewards:

Validators receive rewards based on their own stake and a commission on delegated stake.
The reward formula includes factors for validator performance (μv) and stake share (σv).

Delegator Rewards:

Delegators receive rewards proportional to their delegated stake, minus the validator's commission.
Rewards are affected by the performance of the chosen validator.

Unstaking Process:

Users can withdraw their stake at the end of an epoch.
Rewards are accrued only for epochs where the stake was active for the entire epoch.

Performance Incentives:

The reward system includes a tallying rule (μv) that boosts rewards for well-performing validators and reduces rewards for underperforming ones.

Storage Fund Interaction:

The Storage Fund is included in the total stake calculation, affecting reward distribution.
A portion of Storage Fund rewards is paid to validators to compensate for storage costs.

Epoch-based System:

Staking, validator selection, and reward distribution operate on an epoch-based system.
At the beginning of each epoch, a new committee is formed based on current stakes.

Validator Requirements:

Validators must meet minimum staking requirements to join and remain in the active set.
As of the documentation, a minimum of 30M SUI stake is required to join, with lower thresholds for remaining active.

Staking Pools:

Each validator maintains its own staking pool to track stake amounts and compound rewards.
Staking pools use a time series of exchange rates to determine reward accrual.

Network Components

Validators

Validators play a crucial role in the SUI network, being responsible for processing transactions, maintaining the blockchain's security, and participating in the consensus mechanism. Here are the key aspects of validators in the SUI ecosystem:

Role and Responsibilities:

Validators process transactions submitted by users.
They participate in the consensus mechanism to agree on the order of transactions, especially those involving shared objects.
Validators are responsible for maintaining the security and integrity of the network.

Selection and Staking:

Validators are selected through a Delegated Proof-of-Stake (DPoS) mechanism.
SUI token holders can delegate their tokens to validators, increasing the validator's stake and voting power.

Minimum Requirements:

To become an active validator, a candidate must accrue at least 30M SUI of stake.
Active validators must maintain a minimum of 15M SUI stake to avoid immediate removal from the validator set.

Performance Incentives:

The reward system includes a tallying rule that boosts rewards for well-performing validators and reduces rewards for underperforming ones.
This incentivizes validators to optimize their operations and provide efficient transaction processing.

Consensus Participation:

Validators participate in the Sui Lutris consensus protocol, which allows for parallel block proposals and a three-round commit process.
They vote on and certify transaction blocks to achieve consensus.

Transaction Processing:

Validators verify and execute transactions, creating effects certificates.
They process owned-object transactions immediately and coordinate through consensus for shared-object transactions.

Staking Pool Management:

Each validator maintains its own staking pool to track stake amounts and compound rewards for delegators.

Epoch-based Operation:

The validator set is determined at the beginning of each epoch based on stake distribution.
Rewards are calculated and distributed at the end of each epoch.

Gas Price Setting:

Validators participate in setting the reference gas price for each epoch through a voting process.

Checkpointing:

Validators are involved in creating checkpoints, which represent a consistent view of the network state at regular intervals.

Protocol Upgrades:

Validators play a role in protocol upgrades by signaling their readiness to switch to new versions of the protocol.

Validators are essential to the functioning and security of the SUI network. Their role in transaction processing, consensus, and network governance makes them critical stakeholders in the ecosystem. The economic incentives and performance requirements built into the system are designed to encourage validators to operate efficiently and in the best interests of the network as a whole.

Full Nodes

Full Nodes play a crucial role in the SUI network by providing additional infrastructure support and serving as intermediaries between end-users and validators. While not directly involved in consensus, Full Nodes are essential for network resilience, data availability, and user interaction. Here are the key aspects of Full Nodes in the SUI ecosystem:

Role and Responsibilities:

Full Nodes serve as an interface between end-users or applications and the SUI network.
They replicate and store the entire state of the blockchain, including all transactions and objects.
Full Nodes can respond to read requests and submit transactions to validators on behalf of clients.

Transaction Processing:

Full Nodes receive transactions from clients and forward them to validators for processing.
They collect validator signatures to form transaction certificates and effects certificates.
Full Nodes can execute transactions locally to keep their state up-to-date.

Data Availability:

Full Nodes maintain a complete copy of the blockchain state, ensuring data availability and redundancy in the network.
They can serve historical data and respond to queries about past transactions and object states.

RPC Services:

Full Nodes provide RPC (Remote Procedure Call) endpoints for applications and users to interact with the SUI network.
They can serve online transaction processing (OLTP) requests, leveraging the data stored in their relational databases.

State Synchronization:

Full Nodes synchronize their state with validators to ensure they have the most up-to-date information.
They participate in the state sync process, which allows them to efficiently catch up with the current network state.

Network Resilience:

By maintaining multiple Full Nodes, the SUI network becomes more resilient to potential validator failures or network partitions.
They help distribute the load of read requests and transaction submissions across the network.

Local Execution:

Full Nodes can perform local execution of transactions, which helps keep their state current and allows for faster responses to client queries.

Checkpoint Processing:

Full Nodes process and store checkpoints, which represent consistent views of the network state at regular intervals.
This allows them to provide historical data and assist in network synchronization.

Data Pruning:

Full Nodes can implement data pruning strategies to manage storage requirements while still maintaining necessary historical data.

Indexing:

Some Full Nodes may run indexing services to provide more efficient querying capabilities for specific types of data or applications.

Sui Indexer

The Sui Indexer is a crucial component of the Sui ecosystem, designed to enhance data accessibility and query capabilities. It serves as an off-Full node data service that processes and organizes data from the Sui protocol, making it easier for applications and users to retrieve specific information efficiently. Here are the key aspects of the Sui Indexer:

Purpose:

The Sui Indexer is designed to serve data from the Sui protocol, including both data directly generated from the chain and derivative data.
It aims to improve the efficiency of data retrieval and analysis on the Sui network.

Main Functions:

Data Ingestion: The indexer pulls checkpoint blob data from Full nodes and schematizes it into various tables in a relational database.
OLTP RPC Requests: It serves online transaction processing (OLTP) requests, leveraging the structured data in the relational database.
Analytical Data: The indexer supports ingestion of analytical data, such as transactions per second (TPS) and daily active user (DAU) metrics.

Data Structure:

The indexer organizes data into structured tables, including objects, transactions, and other relevant entities.
This structured approach allows for more complex and efficient querying compared to the raw data stored in Full nodes.

Database Usage:

The Sui Indexer uses a relational database (such as PostgreSQL) to store and manage the indexed data.
This allows for more flexible and powerful querying capabilities compared to the embedded RocksDB used in Full nodes.

Query Optimization:

By schematizing data and creating appropriate indices, the indexer enables faster and more efficient data retrieval.
This is particularly useful for complex queries that would be slow or impractical to perform directly on Full node data.

Scalability:

The indexer can be run separately from Full nodes, allowing for independent scaling of indexing and data serving capabilities.

Real-time Updates:

The indexer continuously ingests new data from the blockchain, ensuring that the indexed data remains up-to-date.

Support for Analytics:

Beyond basic data retrieval, the indexer supports analytical data ingestion, enabling more complex analysis of network activity and performance.

Customization Potential:

While the core Sui Indexer provides general-purpose indexing, it's possible to create custom indexers for specific application needs.

Future Enhancements:

Planned improvements include expanding support to MySQL-compatible databases and simplifying the deployment process.

The Sui Indexer plays a vital role in making the vast amount of data generated on the Sui blockchain more accessible and usable. By providing efficient data retrieval and supporting analytical capabilities, it enables developers to build more sophisticated applications and allows for better insights into network activity. This component is crucial for scaling the ecosystem and supporting a wide range of use cases that require fast and complex data queries.

Challenges and Criticisms

While SUI introduces innovative solutions to blockchain scalability and performance, it has faced several challenges and criticisms:

Centralization Concerns:

Critics argue that DAG-based systems like SUI may face centralization issues as they scale. As the network grows, it becomes increasingly difficult to maintain a fully decentralized system without compromising on performance.

Complexity of Object Model:

The object-centric model, while powerful, introduces complexity for developers. Managing object lifecycles and ownership can be challenging, potentially leading to subtle bugs or security issues.

Limited Dynamic Dispatch:

SUI's MoveVM lacks dynamic dispatch, which can make certain programming patterns difficult to implement. This limitation can affect code reusability and upgradability.

Awkward Shared State Programming:

Programming shared state in SUI can be cumbersome due to the lack of stored references and limitations in type safety for related instances.

Potential for Double Spending:

In DAG-based systems, as the network scales and is divided into shards, there's an increased risk of double-spending attacks if not properly managed.

Consensus Challenges:

Achieving consensus in a DAG structure can be more complex than in traditional blockchain systems, especially as the network grows.

Lack of Global State:

Unlike traditional blockchains, DAG-based systems like SUI lack a single, consistent global state at any given moment, which can complicate certain types of applications.

Dependency on Centralized Components:

In its early stages, SUI relied on centralized components like "The Coordinator" for security, raising questions about true decentralization.

Complexity of Gas Model:

SUI's gas model, while innovative, introduces complexity that may be challenging for users and developers to navigate effectively.

Smart Contract Language Repository

move

a month ago

Sui

THE MEME STUDIO | Web3 Marketing Agency