The Sui blockchain has emerged as a novel layer-1 (L1) protocol, incorporating advanced technologies to address common layer-1 trade-offs. Cointelegraph Research unpacks the details of this newcomer to the blockchain space.

Sui uses the Move programming language, which was designed with a focus on asset representation and access control. This article examines Sui’s object-centric data storage model, its implications for transaction processing, and its potential advantages over traditional account-based paradigms.

The object-oriented paradigm of SUI

Sui draws significant inspiration from the Diem blockchain, particularly in its use of the Move programming language for smart contracts. Move was designed with a type system specifically tailored to asset management and access control enforcement. Sui Move builds on this foundation with an object-centric data storage model that uses objects rather than accounts as primitives.

Unlike the traditional account model, where transactions change balances, or the UTXO model, where transactions have simple inputs and outputs, Sui’s object model treats assets (as well as smart contracts) as complex objects. Transactions in Sui take objects as inputs and mutate these inputs into output objects. Each object records the hash of the last transaction that produced it. This approach is conceptually similar to the UTXO model but more general and powerful. A comparison of the models can be seen below.

Move’s use of linear logic is connected to the object-oriented model and facilitates the development of secure software. Linear logic, sometimes referred to as resource logic, ensures that resources representing digital assets cannot be duplicated or inadvertently destroyed. When a transaction involving an asset is executed, Sui Move’s semantics ensures that the asset’s state is updated in a way that reflects the transaction’s outcome, consuming the asset in its previous state and producing it in its new state.

Objects in Sui can also have defined access controls and permissions, which enhances security and control over asset use after a transaction. This mitigates vulnerabilities common on account-based chains, which allow reentrancy attacks. In a reentrancy attack, a function makes an external call to another contract before updating its own state, allowing attackers to repeatedly execute actions that should only occur once.

This can lead to unauthorized changes in the contract’s state, such as withdrawing more funds than ought to be allowed. Because transfers of ownership are explicit and atomic in Sui, this type of error cannot happen. Move’s linear type system ensures that once a resource is moved, it cannot be reused unless explicitly reassigned.

The traditional account-based model as used by Solidity, on the other hand, requires that developers implement additional checks to prevent such bugs. For example, reentrancy attacks need to be avoided by following a checks-effects-interactions pattern. All state-changing operations (effects) have to occur after all checks but before any interactions (external calls). This pattern, often referred to as optimistic accounting, ensures that state variables are updated before performing any external interactions.

While the object-centric model itself does not inherently enhance security, it can simplify the development process and make it easier to write secure code. Although smart contracts on Ethereum can be formally verified to achieve high levels of security, this process can be complex and costly.

Solidity is known for its notoriously unintuitive semantics, which makes it difficult for developers to reason about the code’s behavior. This increases the likelihood of introducing subtle bugs and security vulnerabilities.

SUI Move belongs to a family of languages that tries to simplify secure smart contract development by baking sensible financial primitives into the semantics of the language from the very start. Another example is Algorand blockchain’s Transaction Execution Approval Language (TEAL), which uses a stateless execution model to ensure that transactions are atomic and secure.

Sui’s object-centric model is particularly advantageous for managing complex assets such as non-fungible tokens (NFTs). In Ethereum, NFTs are tied to smart contract addresses, and interactions often require complex contract calls and state updates, leading to higher costs and potential security risks​. For instance, transferring an NFT in Ethereum involves invoking a function of the ERC-721 smart contract, which updates the state and emits events.

This process involves multiple steps and gas fees for each operation. In contrast, Sui’s object model allows each NFT to be treated as a distinct object with intrinsic properties and permissions. The behavior of NFTs is closely aligned with the primitives of the Move language, whereas in Ethereum, this behavior needs to be implemented, which increases overhead and creates room for error.

Object orientation and blockchain performance

The object-oriented model makes sharding and parallelization on the SUI blockchain easier. Combined with a recent update of the Sui consensus mechanism, SUI thus achieves a time-to-finality of approximately 390 milliseconds.

This could allow a throughput exceeding 100,000 transactions per second. A comparison of Sui with other prominent layer-1 blockchains can be found below.

Database sharding on account-based chains versus SUI

One of the most pressing concerns for blockchains is the infamous trade-off between scalability, security and decentralization. Sharding, which facilitates partitioning the blockchain database, is considered a solution for this problem.

In account-based architectures, sharding involves partitioning the state by account addresses. Each shard manages a distinct range of addresses, and transactions are processed by the shard that holds the data of the account involved.

However, this faces a number of issues. For instance, Polkadot requires that each account’s balance and state be updated and synchronized across shards (Parachains). Maintaining consistency across multiple shards is challenging as each shard must regularly synchronize with the global state, which introduces latency and complexity.

Transactions involving accounts on different shards require inter-shard messaging and coordination, which adds computational overhead and delays transaction finality. In the past, this has led to downtime on such blockchains, as was the case for Zilliqa.

Sui’s object-centric model avoids many of these issues by treating each object as an independent unit of state. Objects can be processed and managed separately without requiring global state synchronization, and multiple transactions can be processed concurrently without the need for synchronization across shards. This reduces the need for complex cross-shard communication and allows for more straightforward and efficient parallel processing.

Parallelized transaction processing on SUI

Parallelization refers to executing multiple operations simultaneously and improving processing speed by leveraging concurrent execution threads.

There are two main methods of parallelization: state access method (or deterministic execution) and optimistic execution. In the state access method used by Sui and Solana, transactions declare which parts of the state they will access, allowing the system to identify independent transactions that can be executed concurrently.

This approach ensures predictable outcomes and avoids the need for re-executing transactions, enabling dynamic gas fee markets that manage congested state hotspots.

Optimistic execution, on the other hand, as it is used by networks like Monad and Aptos, initially assumes all transactions are independent and re-executes conflicting transactions retrospectively. While simpler for developers, it can lead to computational inefficiencies.

Sui achieves state access parallelization through its object-centric model. Operations on one object do not impact or delay operations on another, naturally allowing them to be processed concurrently. The same structural features simplify partitioning the database of transactions, thus also simplifying parallelized processing on a single node.

Conclusion

In conclusion, the Sui blockchain’s object-centric model, combined with the Move programming language, addresses several key limitations of traditional layer-1 blockchains. The ability to process transactions in parallel significantly enhances scalability and reduces latency.

Using linear logic and capability-based security ensures robust resource management and access control, potentially lowering the risk of errors and security vulnerabilities. Additionally, Sui’s approach to managing complex assets, such as NFTs, simplifies interactions and improves efficiency compared to traditional account-based models. These features position Sui as a noteworthy advancement in blockchain technology.

In our next article, we will examine the consensus mechanism of the Sui blockchain, exploring its evolution and the benefits it provides. Sui employs a consensus protocol designed to work with its object-centric model.

We will analyze the specifics of Sui’s consensus mechanism, including its fault tolerance and throughput optimization methods, to understand how these elements contribute to its infrastructure.

Furthermore, we will compare Sui’s consensus approach with those of other prominent blockchains, such as Ethereum, Polkadot, and Solana, to identify its unique features and areas where it may excel or face challenges.