Transactions and Objects

On traditional blockchains, a transaction manifests a transition of the whole blockchain from State n to State n+1, the result of which is recorded in the ledger. Each new transaction is associated with a new blockchain state.

On the Sui Network, however, this is an entirely different story due to the object-centric design of the blockchain. Here, a transaction is an operation resulting in the emergence of new and mutation of the existing objects. New objects have version 0. With each transaction, the version of an address-owned and a shared object increments by 1. Hence, a transaction is a signed command specifying the number of input objects (read-only, owned, or shared), a version number per object, an entry function into a smart contract, and a set of parameters. So, a transaction on Sui is the state transition of an object from Version n to Version n+1.

There are three approaches to different objects on Sui:

• Read-only or immutable objects (packages) cannot be mutated or deleted within an epoch and can be used in transactions concurrently and by all users.
• A transaction run with an address-owned object is signed by a single address. However, a single transaction cannot use objects owned by multiple addresses. An object (child object) can also be owned by another object (parent object). If this is the case, the child object may only be used if the root object (the first one in a tree of possibly many parents) is part of the transaction and the transaction is authorized to use the parent. This facility is used by contracts to construct complex data structures (collections, gaming objects, etc.).

📘

Shared objects (Kiosk stores, exchanges, marketplaces) are mutable and do not have a specific owner. Anyone can use them in transactions, and in this case, authorization is run by a smart contract.

📘

Everything is an object on Sui.

For more information on the Sui object model, go here.

What's specific about transactions on Sui

Apart from the novel object-centric model, Sui has introduced several innovations that accelerate transactions, among which are the following:

• Narwhal and Tusk DAG-based Mempool and Bullshark Consensus engine that group and batch transactions around objects they are associated with to execute them in parallel;
• Sui Lutris protocol combines DAG-based Consensus with consensusless approaches to achieve low latency and sustained throughput.
• Separation of roles in transaction processing and execution: a client and validators in the validator set.

📘

Glossary

There are some terms everyone should know to understand transaction performance on a blockchain:

Throughput - The measure of how many transactions a blockchain can process within a given time frame. It's typically measured by TPS - transactions run per second.

Latency - the time between transaction initiation and completion.

Finality - the point at which an executed transaction becomes irreversible.

Time-to-finality - the time needed for a transaction to become irreversible.

Consensus - a process by which individual sections of a network define uniform rules and agree upon adding new blocks to the blockchain.

Byzantine-Fault Tolerance - a feature of a distributed system or P2P network that enables it to withstand the actions of rogue nodes or components (51% attack).

Narwhal and Bullshark Consensus Mechanism

Narwhal and Tusk is a DAG-based Mempool, and Bullshark is a Consensus engine. On traditional blockchains, transactions are ordered and executed consecutively, in a row, one by one, making Consensus a linear process. These arrangements make parallel transaction execution impossible - new pending transactions have to stay in the Mempool, waiting for their turn to be executed.

In Narwhal and Bullshark, transactions are grouped by objects using a DAG (Directed Acycled Graph) structure. This structure allows the execution of several transactions in a row and batching them together in a single programmable transaction block. Not only does this increase throughput due to transaction parallelization, but it also keeps transaction fees low since users pay a fee for several transactions at a time.

📘

Transactions with address-owned objects don’t have to go through Consensus.

To learn more about Consensus on Sui, read this article.

Sui Lutris

Sui Lutris is a protocol within a protocol designed specifically for the Sui Network's object-centric design. It enables a differentiated approach to Consensus with different types of objects so that transactions with address-owned and immutable objects skip Consensus and only transactions with shared objects have to go through Consensus. The introduction of Sui Lutris significantly increased throughput and reduced latency, as shown in the image below.

📘

The highest throughput ever recorded on-chain reached 297,000 TPS, making Sui one of the most scalable blockchains ever.

Transaction Lifecycle

In the transaction lifecycle, there are two key roles: a client and a set of validators. The transaction cycle on Sui typically unfolds as follows:

1. The client initiates and signs a transaction using its private key. This is the sole instance where user signature keys are required; the rest of the process can be carried out by the user or a gateway acting on the user’s behalf.
2. Validators take over the transaction: they conduct a range of checks for validity and safety, sign it, and hand back the signed transaction to the client. The checks include:
   a) The epoch(Tx) must align with the current epoch.
   b) All object reference inputs(Tx) and the gas object reference in payment(Tx) must be present within Obj𝑣. For address-owned objects, the precise reference should be accessible; for immutable or shared objects, the object ID should be present.
   c) The gas object must have enough gas to cover the transaction execution cost.
   d) The objects in the transaction must be valid. This step verifies that the verification data in the transaction grants access to the owned objects.
   e) All transaction address-owned objects must be locked.
3. The client then gathers responses from a group of validators that represent a supermajority (at least 2/3 stake) and compiles a transaction certificate that includes the transaction itself, the identifiers, and the signatures.
4. The client forwards the certificate to the validators, who verify its authenticity and confirm its receipt to the client. If the transaction solely involves address-owned objects, Sui can process the transaction certificate instantly and execute it without waiting for the Consensus to be run. All address-owned objects must be locked. If this modified locks check fails, the validator has identified an irrecoverable Byzantine failure, the normal operation must be stopped, and a disaster recovery process must be initiated. For shared objects, validators verify that the locks have been established through the certificate being sequenced in a Consensus to determine the version of the shared object to use. If so, the transaction may be executed; otherwise, it must first wait for such sequencing. If the check is successful, the authority adds the certificate to its certificate map and the effects (events) resulting from its execution.
5. Transactions involving shared objects undergo Consensus, which results in a total order of certificates being output; the validators verify and execute those that contain shared objects.
6. The client collects a supermajority of validator responses, compiles them into an effect certificate, and uses it as evidence of the transaction settlement.
7. The Sui Protocol creates checkpoints for every consensus commit, which it also uses to drive the reconfiguration protocol.

📘

Sui allows a batch of 1024 heterogeneous transactions, one transaction at a time. This is particularly beneficial for DeFis, which often executes custom logic involving a series of transactions (x to y swap, for instance).

The image below illustrates the transaction lifecycle on Sui.

📘

The highest throughput ever recorded on-chain reached 297,000 TPS, making Sui one of the most scalable blockchains ever.

Finality

Finality is the property of a transaction being irrevocable and unconditional. On traditional blockchains, finality is reached by adding more blocks on top of the block in which the processed transaction is being added, which takes time. The longer it takes for a block to be added to a blockchain, the longer the time to finality is.

On Sui, there's a distinction between transaction finality, after which transaction processing is ended, and settlement finality, after which a transaction's effects (events) are final and may be used in subsequent transactions. Unlike other blockchains on Sui, transaction and settlement finality occur before checkpoints are formed. In all cases, a transaction becomes final when a quorum of validators accepts the transaction’s certificate for processing, even before such a certificate is sequenced by Consensus or executed. After this, no conflicting transaction can occur, and the transaction may not be revoked. It is eventually executed and persists across epochs.

This is how Sui compares to other blockchains in TTF (time-to-finality):

Read more about transaction statuses in this article.