The Concepts and Elements of Sui

Sui区块链采用并行设计实现高吞吐量 scalability，在传统区块链中采用线性机制导致交易吞吐量瓶颈问题。Sui通过个体交易水平验证而非基于“块”的验证模式实现网络一致性。其采用基于 DAG 的对象模型进行交易处理：每笔交易以 objects 为输入/输出；系统维护 live objects（可变对象）、全局系统状态（包括地址拥有的对象及共享/Immutable对象）；支持动态字段和动态对象字段的操作；采用分层共识机制（Narwhal 和 Bullshark/Tusk），其中 Narwhal 确保数据可用性，Bullshark/Tusk 确保数据有序性；Sui 使用 Lamport 时间戳实现高可用性和低延迟的共识算法 Mysticeti 2.0 作为共享对象共识协议的基础。

Concepts

Sui Background

This traditional blockchain network architecture is limited due to its linear mechanisms often serving as the primary bottleneck in enhancing its capacity to process high volumes of transactions.

The Sui blockchain represents a highly decentralized parallel processing architecture dedicated to handling transactions across its network. This approach differs fundamentally from conventional block-chain structures, where validation occurs at a block level. Instead, Sui's innovative design processes each transaction individually, thereby significantly reducing overall network congestion by only requiring consensus when necessary to order linked transactions. This unique feature has been termed casual ordering, whereas traditional methods that achieve global consistency through consensus are referred to as total ordering.

Object Model

The basic unit of storage in Sui is the object , a transaction-object DAG.

Storage

Other blockchain networks organize their storage around accounts that are addressed via key-value stores. Sui’s storage, in contrast, organizes data around objects that can be uniquely identified on the chain.

Object

• A smart contract system is an object referred to as a SUI MOVE PACKAGE.
  • SUI MOVE PACKAGE: A collection of SUI MOVE bytecode modules designed to perform specific functions within the system.
  • SUI MOVE OBJECT: Represents typed data managed by individual SUI MOVE modules within the same SUI move package.
  • OBJECT PROCESSING: The workflow follows the sequence PACKAGE -> MODULE -> OBJECT, ensuring that once published, these elements remain immutable and are not altered or deleted thereafter. When referring to objects within this context:
    • Method 1: Assign a unique identifier.
    • Method 2: Use an (ID, version) pair for identification purposes.
    • Method 3: Implement a more detailed structure using an (ID, version, object digest) triplet for advanced referencing requirements.

Object metadata

Each Sui object includes:

• Its identifier is a 32-byte globally unique value.
• Its version is an 8-byte unsigned integer that increments monotonically with each Tx.
• The digest represents the final transaction involving this object as an output.
• It features a 32-byte owner field alongside additional fields.

The transaction-object DAG

• 交易将对象作为输入并进行读取、写入或修改这些输入操作以生成或创建新的对象。
• 有向图DAG用来展示对象与交易之间的关系。
  • 其中节点代表具体的交易操作。
  • 边界表示A→B表示A交易的输出结果是B交易的输入来源。
  • 根节点是一个起始性的交易操作没有输入但会产生相应的输出结果。

Global system state

• Live Objects: are accepted as inputs,
• The global state managed by Sui includes all such live Objects.
• A's address encompasses all its own Objects plus the system-shared and immutable Objects.

Object Ownership

Each object contains an owner field, categorized into several ownership types:

• Address-owned objects are controlled by either a specific 32-byte address (account) or an object ID. Access to these objects is restricted to their sole owner.
• Immutable objects lack owners, enabling universal access. These objects cannot be modified, transferred, or deleted.
• Shared objects are distributed through the 0x2::transfer::share_object function and make their contents accessible globally. All users on the network can access shared content.
• Wrapped functionality organizes data structures by encapsulating a field of struct type within another structure.

Object and Package Versioning

A single object with ID I may appear in multiple entries as (I, v0), (I, v1), and (I, v2), with the latest version being available.
It enables node operators to remove outdated object versions from their repositories that are no longer accessible.
Sui employs Lamport timestamps in its versioning algorithm for objects.
For example, a transaction transferring an object O at version 5 using a gas object G at version 3 updates both O and G’s versions to 1 plus the maximum of their respective versions: max(5,3)=6.

PTB: Programmable Transaction Blocks

• PTBs are defined as groups of transaction commands that specify all user transactions on Sui.
• PTBs enable users to invoke multiple Move functions, manage their associated objects, and handle coin operations within a single transaction without requiring the publication of additional Move packages or contracts.
• PTBs represent an efficient and adaptable method for generating transactions.
• Advanced programming patterns such as loops are not supported by PTBs; in such scenarios, users must publish new Move packages.
• Each transaction command executes sequentially and atomically (ensuring object modifications or transfers). If any transaction command fails within the block, the entire operation fails without partial success.
• A PTB is capable of executing up to 1{,}024 distinct operations per execution cycle.

Mysticeti & Threshold Logical Clock

The next-generation consensus engine, which is set to be released in Sui, will be built upon the Mysticeti protocol. This marks the release of version 2.0 for Sui’s consensus mechanism.

The protocol is designed to optimize for both minimizing latency and maximizing throughput, aiming to achieve balanced performance.

This system enables multiple validators to submit blocks simultaneously while fully utilizing network bandwidth and providing censorship resistance. This feature is characteristic of DAG-based consensus protocols.
Only requires three rounds of messaging to commit blocks derived from DAGs, matching both pBFT's performance and achieving the theoretical minimum latency.
The commit rule permits parallel voting and certification of leaders on blocks, further reducing both median and tail latencies.
Additionally, this rule accommodates unavailable leaders without significantly increasing commit latencies.

To gain comprehensive insights into the subject matter, including the detailed correctness proofs, the Mysticeti paper stands out as an authoritative reference.

Consensus

Based on our earlier discussion in Part I, owned objects can bypass consensus, whereas shared objects must undergo consensus processes during which nodes must reach an agreement to ensure that records are preserved across the network's distributed ledger.

Prior to engaging in an in-depth examination of contrasting transaction processes, it is important to consider the following observations：

该共识系统以Epoch（时间周期区间）作为共识操作的基本时间单位。在每个周期内，节点验证者被指定并在此周期内保持不变。此类节点验证者被称为Committee。每个 epochs的委员会负责批准下一个 epochs的委员会并推进工作，这需要至少2/3的真实 majority的支持。对于拥有对象上的交易，在通过验证后无需参与共识；而共享对象上的交易则会经过共识阶段以达成节点间的一致顺序。

Owned vs. Shared Object Transaction

Owned Object

The transactions involving owned entities encompass a variety of scenarios such as simple peer-to-peer token transfers the transmission of messages to decentralized applications (dApps) large-scale minting voting and similar activities. These directional transactions specifically do not require or consider the total ordering of their operations thus necessitating validation without the need for a consensus mechanism governing their sequence.

For these object-oriented transactions, Sui leverages *Fast Pay, an innovative Byzantine Consistent Broadcast-based solution. This robust algorithm ensures that all transactions are processed and validated without requiring any consensus. The system leverages *Fast Pay to deliver efficient and reliable transaction processing.

Foundational Byzantine Consistent Broadcast (BCB) serves as an algorithm designed to ensure all node validators receive the same transaction request. Fastpay achieves high transaction per second (TPS) by bypassing consensus steps and implementing a streamlined peer review process among validators. The following example demonstrates that within a 2-node validator setup, the network attains approximately 8-9 transactions per second with an average processing time of less than one hundred milliseconds.

Through the peer-review process mentioned above, Sui adopts dPoS (Delegated Proof-of-System), where delegators are able to delegate their stakes to stakeholders or node validators.

An example of another ex-Libra blockchain project, namely Linera, also incorporates the Fast Pay technology alongside other features. The Fast Pay algorithm paper's authors notably include both the creators of Linera and Mysten Labs.

Here are the steps in processing owned-object transactions:

1. The transaction is delegated from a sender node within a network, subsequently circulates through all validator nodes.
2. The validators participate in dPoS by submitting their votes regarding its authenticity.
3. The initiator creates a certificate incorporating these vote signatures as a confirmation of compliance with Byzantine Fault Tolerance .
4. The initiator re-sends this certificate to circulate through all validator nodes; in response to this dissemination, each validator verifies it independently. If successful verification occurs, this ensures that such transactions are finalized on-chain.

Note that this consensus design requires the transaction originator to additionally perform two steps, specifically the creation and submission of a transaction certificate. However, such a design effectively reduces the overall complexity by completely eliminating the heavy consensus process among validators. From a functional standpoint, this approach can notably enhance user transaction processing efficiency.

Shared Object

Shared object transactions involve scenarios like interacting with accessible smart contracts. Such transactions are not one-way and need sequencing through consensus. In Sui, the consensus engine is built from two key components: Narwhal and Bullshark/Tusk, each serving distinct functions. We will explore each layer in depth in upcoming sections.

At a high level:

• Narwhal (mempool) verifies the data availability of data included in consensus.
• Bullshark and Tusk collaborate to establish a sequential ordering for this dataset.

Mysticeti is the latest consensus 2.0 of Sui used for shared object.